VMware Hands Oversight of Open vSwitch to The Linux Foundation
To the growing list of open source functions that are critical to the delivery of services at large scale, add Open vSwitch, the open source virtual network switch created by VMware for connecting virtual machines.
Tuesday, The Linux Foundation announced that Open vSwitch (OVS) is being added to its growing bastion of infrastructural projects, as VMware cedes oversight of the project. OVS joins the Open Container Initiative (OCI) container format, Node.js, the orchestration interests of contributors to Kubernetes, and many other projects now critical to the functioning of the world’s data centers.
“We’ve really tried to be, and I think we have been, fair in administering the project, and not trying to show favorites with anybody,” said Justin Pettit, VMware’s director of switch technology, in a discussion with The New Stack. “But there are still those perceptions. And I think this move to the Linux Foundation helps clarify that for a lot of people.”
At the same time, VMware wants to project a picture of stability and consistency, especially for major data centers and cloud service providers that have already invested considerably in the virtual appliance.
“I don’t think this becoming a Linux Foundation [project] changes the relationship between VMware and Open vSwitch,” stated Ben Pfaff, VMware principal engineer. “The way that VMware interacts with it would still be the same.”
Pfaff explained that, while VMware engineers continue to be responsible for as much as 70 percent of the active commits to OVS, these contributions are considered personal, as opposed to official distributions from VMware, Inc. His hope is that this changing of the guard, such as it is, will compel outside contributions to swell to almost half the total by the end of this year.
A Virtual Switch for a Virtual Machine
As data center network operators know quite well, the vSwitch is the key to the virtual network. VMware revolutionized the staging of virtual components (arguably a market it created in the first place) through the introduction of virtual networks that linked virtual machines to physical networks. This way, physical servers weren’t just one-to-one hosts for VM platforms; they could define the means with which VMs communicated with one another. There’s an argument to be made that the cloud, as we know it today, would not be feasible without the vSwitch.
In February 2012, a company called Nicira demonstrated that it could build an open source network virtualization platform running on VMware’s ESXi hypervisor. Nicira’s true breakthrough was that this platform was operable entirely through public APIs, instead of the proprietary network interface drivers required by Cisco, Juniper and others. That innovation prompted Stanford University researchers to ask [PDF], “Is Nicira biting off more than it can chew with this sweeping new technology? Or do they have the ability to completely disrupt the entire internet services market?”
The following June, VMware acquired Nicira outright, effectively rendering Stanford’s question moot. The acquisition deal was later valued at around $1 billion, in a move that Business Insider discovered was part of a then-unreported bidding war against Cisco for the technology.
VMware’s CTO at that time, Steve Herrod, stated that his company was committed to keeping Open vSwitch open and vendor-agnostic, including with respect to third-party hypervisor support. Other parties, including Cisco, were quick to point out VMware’s restrictions on support options for OVS outside of vSphere. Without question, the Nicira deal has made VMware an equal contender against networking companies for the richest space in the data center, even without producing a physical switch of its own.
Now that the advance of physical network appliance is being kept at bay, VMware evidently believes it’s safe now to eliminate the last vestiges of the appearance of physical control over the project.
“I know there are external perceptions,” said VMware’s Pettit, “but we can’t say this enough: There are mechanisms that prevent this from being VMware-driven, as opposed to being VMware-led.
“I think we’ve always been fair about what the contributions are,” he continued, “and how we take in contributions. Really, what it comes down to is, everything is on the mailing list. People send patches, we apply them, and occasionally there is feedback about how a feature is implemented. But I don’t think there are instances that can be pointed to where we’ve made a decision not to take in patches that were just because they were not the quality that we wanted; or that there was a patch that solved one particular person’s problem, but that would destroy the performance in the common case.”
With container orchestration platforms now being introduced into production — perhaps gradually, yet still eventually — data centers are realizing the feasibility of implementing hyperscale, highly automated cloud deployments using such tools as network overlays. More importantly for VMware, those tools have not necessarily included virtual switches.
But data centers need to stage VM-based workloads and container-based workloads simultaneously, and it’s here where VMware began sensing an opening last year. With Mesosphere leading the charge for package-agnostic orchestration, it announced in April 2015 that it would be cooperating with VMware’s Project Photon, as well as integrating certain VMware services, such as authentication, with Mesosphere’s DC/OS (Data Center Operating System).
That means these two companies are, at least officially, continuing to work together on the Open Virtual Network project. For progress on that project to proceed, VMware cannot afford to be perceived as having any goals whatsoever that bear even a faint whiff of exclusivity. In three weeks’ time, we may see the latest culmination of these joint efforts at the next VMworld conference in Las Vegas, to be held later this month.
Cisco and Mesosphere are sponsors of The New Stack.
Title image of an old train switch bank by darkday, licensed via CC BY 2.0.