In 2011 Marc Andreessen made his now famous statement, “Software is Eating the World”; a wild claim at the time, but one that proved to be highly prescient. This declaration has become the underpinning of how VMware delivers solutions that enable our customers to be more agile, efficient and innovative with their IT operations – through software.
When we launched our vision for a Software-Defined Data Center (SDDC) in May of 2012, we said it would enable IT transformation through security, automation, management control, and services choice in a way that translated to greater simplicity, programmability, and consistency across various customer IT environments. We executed on that vision in partnership with the technology and open source ecosystem so that customers would have the best of breed approach when transitioning to a modern software infrastructure.
The explosion of cloud and container services has driven a significant need for scalable, automated and policy-driven networking across heterogeneous environments in a way that can only be realized through software abstraction. Foundational to network virtualization, the virtual switch has become a strategic component for delivering fast, agile infrastructure.
In line with how we’ve executed and delivered on our SDDC vision, we are now seeing our customers converge on a networking standard. They are telling us that their preferred model of the virtual switch is to use the natively available virtual switch in the hypervisor and program it using APIs as required. The adoption of native virtual switch as part of comprehensive network virtualization deployments is accelerating, and the primary reasons are for operational simplicity, security, and pace of new feature advancements. In fact, we’ve found that VMware’s native virtual switch implementation has become the de facto standard for greater than 99% of vSphere customers today.
Moving forward, VMware will have a single virtual switch strategy that focuses on two sets of native virtual switch offerings – VMware vSphere® Standard Switch and vSphere Distributed Switch™ for VMware vSphere, and the Open virtual switch (OVS). This strategy is about investing in the priorities of our customers and simplifying the platform to create the best, most secure experience possible.
By using the native virtual switch on the platform, customers simplify their IT landscape by reducing their upgrade times, streamline their support, deploy new features more quickly, and prepare themselves for the next wave of change agents.
This strategy is particularly significant as enterprises continue to move towards new agile models driven by developers building next-generation applications and running cloud services. These customers are going from on-premises private clouds, to public clouds, to cross-cloud architectures. Standardizing on software across all of these – beginning with the native virtual switch – helps our customers make the transition to their digital future.
There have been a few comments relating to a request for more details regarding VMware’s plans to deprecate 3rd party vSwitch APIs. You can find more details from VMware in this Knowledge Base article here
Some customers received more specific memo starting with “VMware is announcing the discontinuation of its third party virtual switch (vSwitch) program.”, while others like us can’t find anything on the matter. VMware should publish this to ALL customers ASAP along with specific end of support (some customers heard 6.5 current is the last version with API and that API will be pulled completely after 6.5 U1. Copy of memo here:
Nice vendor lock in!
“their preferred model of the virtual switch is to use the natively available virtual switch”
Thats so not true, and you are just trying to sell you NSX solution.. No idea why any customer would like to there network inside a box, inside a box , inside a box…
Does this mean that you are removing access to the API’s at the hypervisor level? It’s normal that you don’t support the AVS from Cisco; Cisco supports it. But if you are not allowing 3rd parties to build vib’s for network services are you not creating a major lock-in?
Stifling innovation and customer choice by deprecating an API set to further your own company’s interests and to put them above your customer’s isn’t the best approach in the market. Luckily, many other hypervisors and container based platforms still offer great customer choice!
Let’s not forget those who implemented Nexus 1000v, what happen to those?
I guess they will be forced to give it up!
Those of us who have made large investments based on current offerings would like to fully understand this new direction. Pleases answer yes or no:
1. Will VMWare continue to support Cisco ACI VMM integration via DVS and VSphere?
2. Will VMWare continue to support integration with Cisco AVS?
Thank Dennis for your questions. We support all solutions that use our public northbound API’s.
VMware has never supported AVS and will not in the future.
Milin – perhaps you can comment on why you are removing the APIs from vSphere 6.5 Update 2 and beyond. No one is asking VMware to support other vendor’s products – the vendors Cisco, HP, and IBM do a great job supporting their own products. But to remove the APIs so that only your internal switch will function has nothing to do with remaining open and supporting innovation.
I think this statement will need to be deepened to clear out what that does mean technically speaking.
Throwing such announcements without announcing a roadmap is confusing at best, specially for those customers that are not using native vswitches.
Please give us a more specific view on what changes as the way I am interpreting it sounds good and bad at the same time.
So, i can use OVS from http://www.openvswitch.org as a replacement for VMware’s vswitches?
We are using the native switch in each platform. As a result vSphere will support VSS/VDS as the construct. If you need any further clarification let us know and we can hop on a call.
VMware did support OVS on vSphere in the past as part of NSX-mh (now Transformers). Does that support still exist? If not, why was that support pulled?
Thanks for question. The NSX-T platform is a new platform for that expands support for multi-hypervisor environments and new application frameworks and architectures, not merely a new version of VMware NSX-MH. Regarding OVS on vSphere, OVS was not supported on vSphere via the 3rd party vSwitch APIs. Consistent with our vSwitch strategy, the NSX-T architecture supports the native vSwitches on hypervisors.
Your blog says you support OVS. Where is documentation of how can one install OVS to ESXi? And what API does OVS to present itself as a VDS? I hope it’s not the same used by N1KV and others … which is being deprecated 🙂
That’s an interesting move since standard vSwitch and distributed vSwitch doesn’t support MAC address learning. This means that the VMware engineers, in order to simplify implementation, realized a vSwitch that doesn’t act as a real switch. This is a huge problem not only for nested virtualization scenarios but also for companies that uses VMware for networking: VM that do BGP-VPLS (MPLS) for example need promiscuous mode that cause high CPU load on the hypervisor (because the vSwitch acts like a hub). The fling realized by William Lam and Christian Dickmann is great to overcome this limit, but unfortunately is still limited because it lacks of a MAC address aging algorithm. I think that VMware have to work on standard vSwitch ad dvSwitch implementation before to drop support for products like Cisco Nexus 1000v. Unfortunately only some company could invest on VMware NSX because of high price (thousand of dollars/CPU). I hope that MAC address learning will be implemented on vSphere. The current implementation isn’t acceptable for a hypervisor on which a company have to invest many thousand dollars.
Thanks for the feedback and we understand the need of mac learning for very specific customer use cases in virtual networking environment. We intend to support MAC learning in VDS. OVS already has mac learning.