There are a number of ways to connect virtual machines together, all of them make use of a Linux bridge device (a virtual switch) which is controlled with the brctl command. The bridge can be left isolated so only VMs on the same host can communicate, or joined to a physical LAN and pass traffic at either Layer 2 (the physical subnet is shared) or at Layer 3 (the bridge has a separate subnet). A good overview of how this relates to libvirt can be found here http://wiki.libvirt.org/page/VirtualNetworking.

For this setup i wanted to make use of my existing network hardware and have VMs accessible by other devices on the LAN. Also it should be possible for them to be placed into a VLAN created on the physical switch, for setting up labs, connecting them to a NAS/SAN or other projects.

This tutorial assumes a network is already configured to support VLAN tagging (IEEE 802.1q). "Small Business" class hardware should provide the support needed, i have a pfSense router and a Netgear GS108T switch (v1 hardware from years ago).

Management interface

The management interface is simply the primary IP address for the libvirt host. Usually this is just a normal interface with an IP address configured. But if VMs also need to be connected to this network then it must be configured as a bridge. Bellow is an example netctl config, VLAN11 is set as the default VLAN (or untagged VLAN) in this setup. Switches will come with VLAN1 set as default, but in cheaper hardware it is usually a good idea to avoid using it.

# nano /etc/netctl/virbr11
Description='Management interface and bridge for VLAN11 (untagged)'
Interface=virbr11
Connection=bridge
IP=static
Address=('192.168.11.11/24')
Gateway=('192.168.11.1')
DNS=('192.168.11.1')
BindsToInterfaces=('enp2s0')

As shown above the physical interface enp2s0 is connected to the bridge with the BindsToInterfaces option. A bridge device named virbr11 is created with the Interface option, and given an IP address (192.168.11.11) which becomes the primary address for the host. Of course enp2s0 will be connected to the physical switch.

Enable this profile for start on the next boot, and reboot to check it is working.

# netctl enable virbr11
# reboot

The interface virbr11 is now available in libvirt for a network to be created base on it.

Tagged VLAN interfaces

Traffic for additional VLANs will be using the same physical interface and switch port as the management interface, so this traffic must be tagged for each VLAN. This is done by creating a virtual interface and then connecting this interface to a bridge.

Create a new virtual interface with VLAN tagging enabled, in this case traffic for VLAN 12 is being tagged.

# ip link add link enp2s0 name enp2s0.12 type vlan id 12

Create new bridge and add the virtual interface, then set the devices to up. virbr12 should become available in libvirt without restarting the daemon.

# brctl addbr virbr12
# brctl addif virbr12 enp2s0.12
# ip link set up dev enp2s0.12
# ip link set up virbr12

Now any traffic passing through this bridge to the physical LAN will be tagged for VLAN12. The bridge can be used to create a network in libvirt for VMs to connect to as usual.

Finally a netctl profile for the virtual interface and bridge can be configured to create the devices on boot. To use additional VLANs it is simply a case of repeating these steps with another VLAN ID.

# nano /etc/netctl/enp2s0.12
Description='Interface for VLAN12 (tagged)'
Interface=enp2s0.12
Connection=vlan
VLANID=12
IP=no
BindsToInterfaces=('enp2s0')
# nano /etc/netctl/virbr12
Description='Bridge for VLAN12'
Interface=virbr12
Connection=bridge
IP=no
BindsToInterfaces=('enp2s0.12')
# netctl enable virbr12
# netctl enable enp2s0.12

libvirt does have support for managing interfaces on the host, but this requires netcf (a RedHat project similar to netctl) which is disabled in the Arch libvirt package.

Finished

For a deeper look at bridges and VLANs here is a very nice post on the Rackspace blog, including some insight into using ebtables for solving issues that come up in a more complex infrastructure http://www.rackspace.com/blog/vms-vlans-and-bridges-oh-my-part-1/ http://www.rackspace.com/blog/vms-vlans-and-bridges-oh-my-part-2/


Comments

comments powered by Disqus