Fedora 20 virtualization with NetworkManager native bridging

Fedora 20 is the first distribution to bundle NetworkManager with bridging support. It means that the old hacks to make a virtual machine plug into current network are not required anymore.

A network bridge lets VMs use same network addresses as other machines, use same DHCP server, listen to network broadcasts, which also enables IP services as Zeroconf (Avahi) and other. It feels as the VMs are plugged on same network as the host machine.

But we are in initial support stage for these features. Documentation is still poor (this is why I’m writing this) and configuration GUIs are still buggy (specially libvirt’s console, virt-manager). So I’ll tell you here how to workaround these bugs. Do the following on machine’s local console and not remotely because you will experience network outages in the process.

Settings for NetworkManager

1. Run NetoworkManager Connection Editor (nm-connection-editor command) as root.
2. Delete the Ethernet connection that is connected to the network you want to bridge. This is were you get disconnected from the network.
3. Add a Bridge connection as these screenshots. Please remember what you put on Interface name, it will be used later on virt-manager configuration. In my case is “bridge1”:
   
4. On the Bridged connections pane, add a connection as these screenshots. Note how I select the MAC address of the physical interface I just deleted on step 2.
   
5. Save and close. The main NetworkManager Connection Editor window should look like the following, with the bridge connection and with no ethernet connection
   

This is how my interfaces looked like before this configuration:

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.174.4  netmask 255.255.255.0  broadcast 172.16.174.255
        inet6 fe80::e2cb:4eff:fe8c:7a44  prefixlen 64  scopeid 0x20<link>
        ether e0:cb:4e:8c:7a:44  txqueuelen 1000  (Ethernet)
        RX packets 5397512  bytes 1376033231 (1.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6343341  bytes 5990187987 (5.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfe500000-fe520000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 796010  bytes 3692664543 (3.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 796010  bytes 3692664543 (3.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

And this is how they look after. Note how the IP address moved from the physical “em1” interface to the new “bridge1” interface we’ve just created:

bridge1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.174.4  netmask 255.255.255.0  broadcast 172.16.174.255
        inet6 fe80::344c:9fff:fe89:ac91  prefixlen 64  scopeid 0x20<link>
        ether e0:cb:4e:8c:7a:44  txqueuelen 0  (Ethernet)
        RX packets 5565233  bytes 1897586628 (1.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4794315  bytes 8405056987 (7.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e2cb:4eff:fe8c:7a44  prefixlen 64  scopeid 0x20<link>
        ether e0:cb:4e:8c:7a:44  txqueuelen 1000  (Ethernet)
        RX packets 5397512  bytes 1376033231 (1.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6343341  bytes 5990187987 (5.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfe500000-fe520000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 796010  bytes 3692664543 (3.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 796010  bytes 3692664543 (3.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Settings for Virtualization Management

The previous configuration could be done directly on Virtualization Management console but since this is all new features and code, it has a bug (as of 2014-01-07). The workaround was found by Mateusz Marzantowicz on a discussion list about it.

1. Run Virtualization Manager console (virt-manager command) as root and make sure you are connected to the libvirt daemon.
2. From the menu, select Edit ➡ Connection Details ➡ Network Interface and add a new one.
3. Simply paste the same Interface name you created above, “bridge1” in my case, and save it with no further configurations. This causes virt-manager to adhere to what is defined to this interface on NetworkManager:
   
4. Note that with no further configuration the bridge interface appears here with correct slave interface:
   

Settings on Virtual Machines

Now each VM on virt-manager should be configured this way:

Now my KVM VMs are members of my network as any other machine or device.