VMware is closing down the APIs that third parties use to access the virtual network within the VMware ecosystem. This means that if you are using one of the third party virtual network switch (i.e. Cisco Nexus 1000v or VM-FEX, HP 5900v or IBM DVS 5000v), you’ll need to consider migrating to the VMware support in-kernel switch stacks. These are either the vSwitch or vDS infrastructure, or the OpenSwitch stack (for those running OpenStack architectures).
Openness is all in the remit of the platform provider, so unless your on a truely open-source hypervisior with open-source orchestrators, the provider (in this case VMware) have the power to make changes that affect your destiny. So if you’re considering SDN, then you’ll need to carefully understand the implications of this announcement.
The timeframes for this come from the VMware Knowledge Base entry Discontinuation of 3rd party vSwitch program (2149722), and start with the release of VMware ESXi 6.5 Update 1. The reason they give is that more than 99% of their customers are using the inbuilt virtual switch and APIs, which makes sense, as most of the other options require additional licenses to operate, and you’ll not want to spend additional dollars on infrastructure (virtual or physical) that is already being delivered in a different fashion elsewhere.
However, to get the best deployment, you’ll want to use the vDS implementation, and possibly use VMware’s NSX as the orchestration platform too. But this only delivers part of a virtualised network solution, and you’ll also want to make sure that the infrastructure that provides the physical connections to the physical hosts is in place and robust enough to support the logical virtual connections that vDS or NSX drives.
Packet Pushers in their article VMware kills off third-party vSwitches provide some evidence that the third-party vSwitch model has never truly worked well. Perhaps this is because VMware may not have been as fully open as it could have been, only publishing some interfaces to other providers whilst using other more flexible lower level APIs themselves.
But it does mean that the transition phase of moving a switch into the virtualised environment for the network team to manage is now soon to be dead.
Instead, you’re going to need an orchestrator such as Cisco ACI or Juniper Contrail, or Nuage to drive the configurations of both the underlying network and the VMware environment if you want ‘almost-seamless’ joins.. Either that or fully virtualise, and live within the NSX environment and the VXLAN tunnels that will spawn over your infrastructure.
Fun times ahead!
