Understanding the Network Topology
The core of this configuration relies on the Linux bridge-utils or built-in kernel bridge functionality. Unlike typical home routers that use Network Address Translation (NAT) to share a single public IP among multiple devices, a KVM host acting as a server gateway typically assigns distinct public IPs to each VM. This requires the physical network switch and upstream router to be configured to route these specific IP ranges to your server’s physical port.
You need to decide how VLANs will be handled. You can either tag traffic at the physical interface level using 802.1Q sub-interfaces (e.g., eth0.100) or let the VMs handle tagging if they are connected to a trunk port. For most standard setups where the host manages the bridging, creating a bridge for each VLAN ID is the cleanest approach. If you are dealing with complex tagging issues, reviewing Solving VLAN Interface and Linux Bridge Connection Issues can provide deeper insight into common pitfalls.
Configuring the Host Network Interfaces
Before configuring the VMs, the host server itself must be set up to pass traffic correctly. Modern Linux distributions use NetworkManager or netplan for configuration. The goal is to create a bridge device that replaces the direct connection to the physical NIC for the VMs, while keeping the host’s own management IP on that bridge.
- Identify the Physical Interface: Use
ip link showto find your primary network interface (e.g.,ens192). - Create the Bridge: Create a bridge interface named
br0. In Netplan, this involves defining a YAML structure where the physical interface is enslaved to the bridge. - Assign the Management IP: The host’s static IP address should be assigned to the bridge
br0, not the physical interface directly. This ensures that when the physical interface goes down, the bridge remains available for management once it recovers. - Disable IP Forwarding (Optional but Recommended): Since you are not doing NAT, ensure
net.ipv4.ip_forwardis set to 0 in/etc/sysctl.confunless you intend to route between different subnets on the same host.
Example Netplan Configuration
network:
version: 2
ethernets:
ens192:
dhcp4: no
dhcp6: no
bridges:
br0:
interfaces: [ens192]
addresses: [203.0.113.10/24]
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
Apply the configuration with sudo netplan apply. Verify connectivity by pinging an external IP from the host. If the host loses connection during application, ensure your console access (IPMI/iDRAC) is available to recover.
Attaching VMs to the Bridge
Once the host bridge is active, you can connect your KVM guests. There are two primary methods: using virt-manager (GUI) or editing the XML definition directly (CLI). The CLI method is more robust for scripting and automation.
In the GUI, go to the VM settings, select the Network Source, choose "Bridge device," and select br0. Ensure the model type is virtio for best performance. For CLI users, edit the domain XML using virsh edit <vm-name>.
<interface type='bridge'>
<mac address='52:54:00:xx:xx:xx'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
This configuration tells QEMU/KVM to attach the guest’s vNIC directly to the host’s br0 bridge. No additional iptables rules are needed for basic connectivity because the bridge operates at Layer 2.
Configuring the Guest Operating System
The guest VM must be configured with its own static public IP address, subnet mask, and gateway. These values are provided by your ISP or hosting provider. Inside the guest OS, configure the network interface similarly to how you did on the host, but point the gateway to the upstream router’s IP on that VLAN, not the host’s IP.
If you encounter communication issues between the host and guest after this setup, check the MAC address filtering on the bridge or consult Troubleshooting KVM Host and Guest Communication Issues for diagnostic steps.
Security and Best Practices
- Firewall Rules: Configure firewalls inside the guest VMs, not just on the host. Since the host bridge does not filter Layer 2 traffic, a compromised guest could potentially scan other guests on the same bridge if they are in the same broadcast domain.
- VLAN Segmentation: For production environments, avoid putting all VMs on a single bridge. Create separate bridges (e.g.,
br-web,br-db) for different services to isolate traffic. - MAC Address Spoofing: Ensure the bridge allows MAC address spoofing if your guest OS needs to change its MAC address dynamically, though this is rarely required for standard configurations.
Frequently Asked Questions
Why can't my VM ping the internet?
This is usually caused by an incorrect gateway configuration inside the guest OS. The guest’s default gateway must be the upstream router’s IP address on that specific VLAN, not the host’s bridge IP. Verify the routing table inside the guest using ip route.
Do I need to enable IP forwarding on the host?
No, you do not need to enable IP forwarding (net.ipv4.ip_forward=1) if you are simply bridging VMs to a public network. IP forwarding is only required if you want the host to act as a router between different internal subnets or perform NAT.
How do I add a second VLAN for another set of VMs?
Create a new Linux bridge (e.g., br1) and attach it to a VLAN sub-interface of the physical NIC (e.g., ens192.200). Then, configure new VMs to use br1 as their network source. This isolates the traffic logically from the first VLAN.
Can I use DHCP for public IP assignment?
While technically possible, it is not recommended for public-facing servers. Static IPs ensure consistent DNS records and firewall rules. If you must use DHCP, ensure your DHCP server reserves specific IPs for your VMs based on their MAC addresses.
What happens if the host restarts?
If you use persistent network configuration tools like Netplan or systemd-networkd, the bridge and its attached interfaces will come back up automatically after a reboot. Always test your configuration changes in a non-production environment first to avoid lockout.