In the context of OpenStack networking, I was trying to explore Open vSwitch. I felt it’s better to go one step back, and try with a pure libvirt guest before I try it with OpenStack networking.
On why Open vSwitch compared to regular Linux bridge?
- In short (as Thomas Graf, Kernel networking subsystem developer, put it) — Software Defined Networking(SDN)
- Open vSwitch’s upstream documentation provides a more detailed explanation.
Here’s a simple scenario, where the machine in test has a single physical NIC, obtaining its IP address from DHCP. And, running KVM guests managed via libvirt.
Install Open vSwitch
Install the Open vSwitch package (this is on Fedora 19):
$ yum install openvswitch -y
Enable the openvswitch systemd unit file, and start the daemon:
$ systemctl enable openvswitch.service $ systemctl start openvswitch.service
Check the status Open vSwitch service, to ensure it’s ‘Active’:
$ systemctl status openvswitch.service
Configure Open vSwitch (OVS) bridge
Before you proceed, ensure to have physical access or access via serial console to the machine, because, associating a physical interface with an Open vSwitch bridge will result in lost connectivity.
Reasoning is here under the ‘Configuration problems’ section.
Add an OVS bridge device:
$ ovs-vsctl add-br ovsbr0
Associate the OVS bridge device to eth0 (or em1). (At this point, network connectivity will be lost.)
$ ovs-vsctl add-port ovsbr0 eth0
I was obtaining IP address to my host from DHCP, so I first cleared it from the physical interface, and associated it with the Open vSwitch bridge device (ovsbr0).
$ ifconfig eth0 0.0.0.0 $ ifconfig ovsbr0 10.xx.yyy.zzz
I killed the existing dhclient
instance on ‘eth0’, and initiated it on ovsbr0:
$ dhclient ovsbr0 &
List the OVS database contents
$ ovs-vsctl show 3dc7f3e3-5872-47c0-ba6f-1cb12065f4d0 Bridge "ovsbr0" Port "eth0" Interface "eth0" Port "ovsbr0" Interface "ovsbr0" type: internal ovs_version: "1.10.0"
Update libvirt guest’s bridge source
I have an existing KVM guest, managed by libvirt, with its default network source associated with libvirt’s ‘virbr0). Let’s modify its network to Open vSwitch bridge.
Edit the libvirt’s guest XML
$ virsh edit f18vm
The attribute should look as below (take note of the highlighted attributes):
[...] <interface type='bridge'> <mac address='52:54:00:fb:00:01'/> <source bridge='ovsbr0'/> <virtualport type='openvswitch'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> [...]
Once the guest XML is edited and saved, dump its contents to stdout, you’ll notice an additional attribute interfaceid
added automatically:
$ virsh dumpxml f18vm | grep bridge -A8 <interface type='bridge'> <mac address='52:54:00:fb:00:01'/> <source bridge='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='74b6858e-8012-4caa-85c7-b64902a19605'/> </virtualport> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/>
Start the guest, and check if it’s IP address matches the host subnet:
$ virsh start fed18vm --console $ ifconfig eth0
Well done and indeed very helpful to do it without the complete OpenStack complexity, thanks! You might want to add how to configure eth0 to be static (i.e. no dhclient being fired up) and ovsbr0 to do dhcp at boot time, though. While there’s a lot of examples for that available in the internet already, it would make the article truly complete.
True — I should’ve noted the static configuration of eth0, maybe I missed that part, as I mostly have a DHCP setup around.
could you please explain where the “” line comes from? Specifically, is this something that is specific to libvirt or is it in openvswitch? Also, is this a number that is specific to the host computer, or is this an ID that is sent from the VM to the host computer? The reason that I ask is that I am looking to use open vswitch on a cluster. I can’t have any IDs that are specific to a host.
What do you refer to, when you say: where the “” line comes from?
Are you referring to the
ovs-vsctl
output?Or are you referring to the
interfaceid
value from the virsh dumpxml output? ? If so, from what I see, this UIID is auto-generated by libvirt to track the interfaces.Hm, I’m not quite sure about the UUID’s effect in the context of a cluster. Maybe you can do a quick proof-of-concept test?
Hello, it seems tag is not recognized and when I open the xml file again this edit is not registered at all (while the source/bridge yes).
This prevents me to start the virtual machine as I get a not recognized error…any ideas?
This was an awesome post! Thank you! I made use of your work in my own work and wrote a blog post about using KVM with OpenvSwitch here:
https://sites.google.com/site/nandydandyoracle/home/kvm-openvswitch-1
Thanks!!
To conclude the process, could you show us an ‘ovs-vsctl show’ at the end of this? It would help summarize and show us what things are supposed to look like when the kvm ovs integration is working. Thanks!