Since the announcement of VXLAN last summer, there has been interest in the Open Source community for an open implementation of this. With the increasing number of Open Source cloud and virtualization technologies out there, where does VXLAN fit into this picture? I think one logical place for it to exist is inside OpenStack Quantum. As a service providing network connectivity between interface devices, this is a logical place for it to exist, especially as it pertains to disparite plugins.
But before I explain how VXLAN could plug into Quantum, some background may be good. Omar Sultan posted a great 3 part blog series on VXLAN (Part 1, Part 2, and Part 3). Reading this will give you a good, relevant background on VXLAN.
An Open Source implementation of VXLAN would require 2 pieces: A data path piece, to implement the protocol and framing format. And a control path piece, to handle orchestration of segment IDs and multicast addresses. For the data path piece, patches were posted to the Open vSwitch mailing list in October 2011, but so far have not been merged into either the Open vSwitch project’s git tree, nor the upstream Open vSwitch kernel code in the Linux tree. Once these patches make it into a public git repository, the data path portion of the equation is complete.
But what about the control path piece? One logical landing spot would be in OpenStack Quantum. Looking at version 1.0 of the Quantum API guide, we can begin to see how to add VXLAN support into Quantum. Quantum networks are created agnostic of their underlying segmentation technology. Currently, VLANs are used. Adding in VXLAN support would be as simple as adding in a type to “Create Network” call. Specifying VXLAN would allow Quantum to provision a Segment ID, and allocate a block of multicast addresses to use. Multiple hosts could still be added to multiple networks with a type of VXLAN. Quantum would work great for handling these types of tasks.
The place where this really begins to shine, however, is in the plugin architecture of Quantum. With Quantum handling the tasks of segment ID allocation, the plugins will have to handle the VXLAN protocol implementation for a network with type VXLAN. Vendors can now implement VXLAN in their plugins, and this buys end users the ability to have a heterogenous VXLAN environment out of the box.
I have previously written about oVirt on this blog, but today, the official press release went out. You can read it in full here, but I’d like to quote a bit from the release:
The oVirt project today announced that Canonical, Cisco, IBM, Intel, NetApp, Red Hat and SUSE have joined together to help create a new open source community for the development of open virtualization platforms, including virtual management tools to manage the Kernel-based Virtual Machine (KVM) hypervisor. With the oVirt project, the industry gains an open source, openly governed virtualization stack.
The key piece to note above is the community aspect. oVirt as a community will develop and create an ecosystem in which customers, developers, and vendors can all thrive. Since the workshop, the community has been working towards the first release of oVirt for public consumption. Cisco, being on the oVirt board, is proud to be a part of the oVirt community as this community drives towards the initial release of oVirt.
Tags: community, open source, oVirt
Let me tell you a reason why open source and open communities are great: information sharing.
Let me explain…
I am Cisco’s representative to the Open MPI project, a middleware implementation of the Message Passing Interface (MPI) standard that facilitates big number crunching and parallel programming. It’s a fairly large, complex code base: Ohloh says that there are 0ver 674,000 lines of code. Open MPI is portable to a wide variety of platforms and network types.
However, supporting all the things that MPI is suppose to support and providing the same experience on every platform and network can be quite challenging. For example, a user posted a problem to our mailing list the other day about a specific feature not working properly on OS X.
Read More »
Tags: HPC, mpi, MPICH2, Open MPI, open source
As we approach Thanksgiving here in the US, we are reminded of things we are thankful for. I thought it poignant to reflect on Open Source projects I am thankful for. These are in no particular order, but represent everything from infrastructure projects to compilers to source control tools. These are some of the most popular and used software in the world today, and taking a moment to say thanks to all the developers, testers, and users is time well spent:
There are certainly plenty of additional Open Source projects out there turning great code into extraordinary solutions. What Open Source projects are you most thankful for? Feel free to share them in the comments so others can explore them and understand why they are so special!
In my previous post, I talked about how networking was a large part of the discussion at the oVirt Kickoff Workshop. Increasingly, the network is elevating itself to be a first-class citizen in large open source infrastructure and cloud projects, including open source projects like OpenStack and now oVirt. In OpenStack, the Quantum project is the result of these discussions. Newborn community projects such as oVirt are starting to look at elevating the network to provide advanced functionality as well. It was no surprise a large portion of the last day of the workshop was spent on networking, with an early focus on Quantum.
The last day of the workshop started out the morning with an overview of SDNs and Quantum by Lew Tucker, CTO of Cloud at Cisco. Lew drew a nice overview of cloud networking on the white board, presenting an app-centric view of cloud and virtual networking. In the cloud network model, apps care only about connectivity to the network, not how that connectivity happens, thus the focus on apps as the center of this world.
Lew Tucker Diagraming Quantum Networking
After Lew was done, Dan Wendlandt, project lead for Quantum, presented his Quantum slides. This was helpful to level-set everyone at oVirt with regards to Quantum and OpenStack. One of the main pain points with looking at how Quantum can be shared from OpenStack into oVirt has been the difference in the networking models. OpenStack presents a very cloud-centric view of networking, whereas oVirt wants a more datacenter-centric model. Quantum was designed to generally be agnostic to the deployment model, so using it in oVirt should be a matter of fitting it into the architecture.
Ram Durairaj from Cisco, Chris Wright from Red Hat, and Dan Wendlandt from Nicira
After Dan was done giving a broad Quantum overview, Ram Durairaj from the Cisco OpenStack team presented on Quantum L3 Services. Currently, Quantum is designed to address the L2 abstraction of the network. Quantum L3 Services are meant to expose L3 concepts such as subnets and gateways into Quantum and the plugins. It would also allow for routing between tenant domains.
Ram Durairaj talking L3 Services
Now that the oVirt Kickoff Workshop is over, watching how the networking story with oVirt evolves will be interesting. The success of oVirt will be the result of the community around it, and the ecosystem for third party vendors it creates. With regards to networking in oVirt, the interactions between the Quantum community and the oVirt community have only just begun, and the future looks like a very collaborative affair between the two projects.
Tags: open source, oVirt, quantum, SDN