If you read the libvirt development mailing list, you will have noticed that libvirt released 2 versions this week, the latest of which is version 0.10.1. This version includes a bunch of bug fixes, but between this and the previous 0.10.0, there are some changes in how you work with Open vSwitch virtualport types. I thought I’d explain some of them here, as they are advantageous and will make deploying libvirt with Open vSwitch easier.
My previous blog postshowed you how to setup Open vSwitch (including LACP port-channels) on your Fedora 17 host. Once you have this working, creating virtual machines and adding them to one of your Open vSwitch bridges is the next logical step. For this setup, we will make use of libvirtto manage our virtual machines. We’ll utilize virt-manager (a GUI) and virsh (a CLI) to manage the VMs on the host. But the VMs themselves, once running on Fedora with libvirt and KVM, can easily be migrated into an oVirt setup, for instance.
I’ve recently decided to move some of the virtual infrastructure in my lab onto Fedora 17. I’ll be running my VMs on KVM utilizing libvirtto manage the VMs. The great thing about this setup is that in theory, by utilizing libvirt, I can easily move my infrastructure to something like oVirtor OpenStackin the future. But for now, I plan to simply make use of a combination of virsh and virt-manager. Getting Fedora 17 onto my host was quite easy, I won’t cover that here.
Recently, as I was talking to a friend about OpenStack, oVirt, and other Open Source Cloud and Virtualization technologies, he stopped me and had me back up. This friend has a strong background in VMware technologies, but not so much with their Open Source counterparts. It occurred to me there are others who may be coming from the same VMware background, thus I decided to create a handy cheat sheet for folks new to Open Source Cloud and Virtualization technologies who have a VMware background.