There has been a flurry of press around Cisco’s release of OpFlex. If you want the nitty gritty details, please read the IETF draft available here. What exactly is OpFlex? The IETF draft sums it up nicely:
It’s clear that Cisco intends to make OpFlex an open standard together with it’s partners in the vendor, provider and Open Source communities. We’re working hard to make that a reality. On the Open Source front, I’m leading a team of people who are working hard on the code around this new OpFlex Policy Agent.
As we get closer to the OpenStack Summit next week in Portland, I wanted to reflect back on the last 6 months of my community involvement with OpenStack. It was almost 6 months ago when I created the Minnesota OpenStack Meetup in an attempt to drive some discussions, education, collaboration, and community around OpenStack in the Twin Cities. Since that time, the Minnesota OpenStack Meetup group has grown to over 120 members (at 127 at the time of this writing).
Increasingly, I’ve been spending more and more time playing around with and utilizing OpenStack. If you’re looking for a highly configurable and quickly maturing cloud operating system, you can’t go wrong with OpenStack. One of the more interesting parts of OpenStack to a networking guy like me is Quantum. Quantum allows you to create rich topologies of virtual networks, encompassing as much or as little as you want by utilizing different plugins.
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 post showed 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 libvirt to manage our virtual machines. We’ll utilize virt-manager (a GUI) and virsh (a CLI) to manage the VMs on the host.
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 libvirt to 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 oVirt or OpenStack in the future. But for now, I plan to simply make use of a combination of virsh and virt-manager.
So, previously on the other site I blog for, I mentioned VXLAN in OpenStack Quantum. The reasons for this are dictated in that post. While we can start working on the segment ID and multicast address management in Quantum, getting VXLAN support into Open vSwitch can be done in parallel. That process has seen renewed interest recently (see the thread here), and I am happy to report I have setup a git repository with the patches from last fall merged into the latest master branch versions of Open vSwitch.
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.
Just a note that over the weekend, after a few weeks of reviews, the Open vSwitch Kernel Code has moved upstream. Dave Miller pulled the code this weekend. Getting this upstream will be really helpful for OpenStack Quantum, as the default plugin for that code uses OVS. This is also great for distributions who want to include OVS, but have been hesitant because of it’s lack of existence in the upstream kernel.
With all of the talk regarding Software Defined Networks (SDN), it’s easy to get lost trying to understand where the value will be. The general consensus here is that value will be built on top of SDN. SDN is, in essence, a building block.
One interesting project providing value by using SDN as a building block is the RouteFlow project. The goal of the project, taken straight form the front page, is: