Networking in KVM

Network types in KVM (NAT, isolated and bridged)

In KVM, network virtualization is mainly managed through libvirt, which lets us create and administer various kinds of virtual networks to which our virtual machines connect. Understanding the available network types is key to properly configuring guest connectivity and the host interaction. There are two broad categories of networks in KVM: Private virtual networks: Internal networks isolated from the outside, managed via virtual bridges created by libvirt. Bridged networks: Networks that connect virtual machines directly to the host’s physical network. Private virtual networks These networks are created on the host and provide a controlled environment for virtual machines. They fall into three main types:

Saturday, October 18, 2025 | 3 minutes Read

How to create and configure private virtual networks

In this step-by-step guide you’ll create three types of virtual networks managed by libvirt and learn simple ways to verify them: NAT (Network Address Translation) Isolated Very isolated (L2 only) We’ll use virsh and XML definitions (you can do the same with virt-manager, but we’ll focus on the CLI). After each creation, there’s a quick check to confirm everything looks good. Before you start: quick requirements Packages: libvirt-daemon and libvirt-daemon-system (or your distro equivalents). Optional: virt-manager. Run commands as root or with sudo. Service: systemctl status libvirtd should be active. See current networks: virsh net-list --all Persistent config paths: /etc/libvirt/qemu/networks/ Tip: avoid subnet conflicts; choose ranges that don’t collide with your physical LAN or other libvirt networks.

Saturday, October 18, 2025 | 4 minutes Read

How to create a bridge interface on the KVM host

A bridge on the host allows your virtual machines to connect directly to the physical network as if they were another machine on the LAN. It’s the basis for “bridged networks” covered in the network types section. Important: if you perform these changes over remote SSH you may lose connectivity. Whenever possible use local/console access or have a recovery plan (KVM/IPMI, a second interface, maintenance window, etc.). 0. Preparation: identify your physical interface and back up configs Identify the physical interface connected to your LAN/Internet (for example: enp1s0, enp3s0, eth0): ip -br link ip -br addr Back up your network configuration files before changing anything — use the command appropriate to your setup: sudo cp -a /etc/netplan /etc/netplan.bak.$(date +%F) 2>/dev/null sudo cp -a /etc/network/interfaces /etc/network/interfaces.bak.$(date +%F) 2>/dev/null Important note: the IP must live on the bridge (br0), not on the physical interface. The physical interface will be left without an IP and become a slave of the bridge. Option A: Netplan (modern Ubuntu/Debian) Applies to systems using Netplan (Ubuntu Server ≥ 18.04, Debian when migrated). The most common renderer is networkd, but NetworkManager can also be used. Here we configure br0 and enslave the physical interface to the bridge.

Saturday, October 18, 2025 | 5 minutes Read