UPDATE: October 29, 2012
This article doesn’t work on Ubuntu 12.10, to use Ubuntu 12.10 please refer to my new article here.
Openvswitch is a better way of managing your virtual networking stacks for KVM and Xen. This can be used instead of the bridge-utils package, and has the ability to use VLANs, LACP, QoS, sFlow, and others. In this article we will be using Ubuntu 12.04 (beta1) to configure Openvswitch to hand out networking interfaces to KVM guests.
Please keep in mind that at the time of this writing Ubuntu 12.04 is beta, which means it is not fully baked for production. Though it is looking very stable.
Install Updates and Prerequisite Software
Check for updates, and install some commonly used hypervisor utilities along with the openvswitch and kvm stacks.
# apt-get update && apt-get dist-upgrade<br /> # apt-get install aptitude apt-show-versions ntp ntpdate vim kvm libvirt-bin vlan virtinst virt-manager virt-viewer openssh-server iperf pv openvswitch-controller openvswitch-brcompat openvswitch-switch openvswitch-datapath-source
Destroy the Default Libvirt Bridge (virbr0)
We want to delete the default libvirt interface which is created by default to be used for guests (I think it is NAT – I never use it).
# virsh net-destroy default<br /> # virsh net-autostart --disable default
Stop Libvirt and Qemu
This will prevent libvirt from bringing up the legacy bridge.
# service libvirt-bin stop<br /> # service qemu-kvm stop
Enable Openvswitch for Brcompat
# vi /etc/default/openvswitch-switch<br /> BRCOMPAT=yes
Purge Ebtables from System
Ebtables was needed when we were using VLANs on bridge-utils, we no longer need this for openvswitch.
# aptitude purge ebtables
Fix DKMS Module Build
When we originally installed openvswitch, you might have noticed an error talking about the module not available for your kernel, if you didn’t notice it you can see the same error by trying to start the openvswitch-switch service.
# service openvswitch-switch start
If you receive the module error, then we will need to build the openvswitch-datapath module.
# module-assistant auto-install openvswitch-datapath
Note that after installing new kernels you will most likely need to repeat this step, to rebuild the module.
Restart the Openvswitch Services
# service openvswitch-switch restart<br /> # service openvswitch-controller restart
Based on your reboot one of two things happened… Your modules came back up loaded and ready for business, though more likely they didn’t come up.
Here is an example of a working configuration. If you get this then move on to configuration of the switch itself.
# lsmod | grep brcom<br /> brcompat_mod 13512 0<br /> openvswitch_mod 83993 2 brcompat_mod<br /> # service openvswitch-switch status<br /> ovsdb-server is running with pid 1885<br /> ovs-vswitchd is running with pid 1908<br /> ovs-brcompatd is running with pid 2096
# lsmod | grep brcom<br /> # service openvswitch-switch status<br /> ovsdb-server is running with pid 1885<br /> ovs-vswitchd is running with pid 1908<br /> ovs-brcompatd is running with pid 2096
Ensuring the Modules Load at Boot
The easy way to fix this is to restart the openvswitch-switch service whenever you reboot your hypervisor.
# service openvswitch-switch restart<br /> * Killing ovs-brcompatd (2096)<br /> * Killing ovs-vswitchd (1908)<br /> * Killing ovsdb-server (1885)<br /> * Starting ovsdb-server<br /> * Configuring Open vSwitch system IDs<br /> * Starting ovs-vswitchd<br /> * Starting ovs-brcompatd<br /> * iptables already has a rule for gre, not explicitly enabling
But that might not be ideal for your situation. As an alternative we can try and address the timing issue which is causing the whole issue in the first place. Basically what is happening is that upstart is starting openvswitch too late, and it is failing. If we adjust the waits in /etc/init/failsafe.conf
We want to change this…
$PLYMOUTH message --text="Waiting for network configuration..." || :<br /> sleep 40<br /> $PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :<br /> sleep 59<br /> $PLYMOUTH message --text="Booting system without full network configuration..." || :
$PLYMOUTH message --text="Waiting for network configuration..." || :<br /> sleep 1<br /> $PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :<br /> sleep 1<br /> $PLYMOUTH message --text="Booting system without full network configuration..." || :
Now after a reboot you shouldn’t have this problem with the modules not loading.
# lsmod | grep brcom<br /> brcompat_mod 13512 0<br /> openvswitch_mod 83993 1 brcompat_mod
Design our Network Layout
In our example we will use 2 physical interfaces, one of which (eth0) we will consider our management interface, it will have a static IP address and will be “the hypervisor” the other one (eth1) will be the uplink for our Openvswitch. Now eth1 will have an untagged fake bridge (br0) which will be the parent for our other fake bridge (br10) which will be tagged 10. If we had more to add they would still use br0 as the parent and then be tagged on the subordinate fake bridge. Another important thing to keep in mind is that your uplinked switch port must support and be configured to allow your devices to tag for these other VLANs.
Configure Openvswitch Fake Bridges
# ovs-vsctl add-br br0<br /> # ovs-vsctl add-port br0 eth1<br /> # ovs-vsctl add-br br10 br0 10<br /> # ovs-vsctl list-br<br /> br0<br /> br10
Create Dummy Interface Entries
We need to edit /etc/network/interfaces to add some entries
# cat /etc/network/interfaces<br /> auto eth0<br /> iface eth0 inet static<br /> address 10.0.0.141<br /> netmask 255.255.255.0<br /> gateway 10.0.0.1</p> <p>auto eth1<br /> iface eth1 inet manual<br /> up ifconfig $IFACE 0.0.0.0 up<br /> down ifconfig $IFACE down</p> <p>auto br0<br /> iface br0 inet manual<br /> up ifconfig $IFACE 0.0.0.0 up<br /> down ifconfig $IFACE down</p> <p>auto br10<br /> iface br10 inet manual<br /> up ifconfig $IFACE 0.0.0.0 up<br /> down ifconfig $IFACE down
These bring up the interfaces with No IP address, now if you run ifconfig -a they should be visible.
Once you have a guest up on br0 or br10 you will see a “vnet0” interface.