As we’ve stated before on SDNCentral — the vSwitch is the new Battleground. In our customer engagements, vSwitches, how they operate in specific environments like OpenStack and VMware, and which vSwitch to choose is a long discussion.
Increasingly, the topic is turning to which vSwitch or which variant of OpenvSwitch (OVS) they should use and how to ensure that the vSwitch does not become the bottleneck. Options vary by virtualization environment:
- VMware: today there are limited vSwitch choices that can be integrated with the hypervisor, such as vSwitches from vendors like VMware, Cisco, HP and IBM. Other soft-switches – like Arista or OVS can run in VMware as a virtual machine (outside of the hypervisor) and is lack tight integration and orchestration. Which vSwitch works best for each VMware deployment is dependent on a number of customer specific requirements and the answer varies.
- OpenStack: Today the default vSwitch is OVS (which is open source controlled by VMware). Anyone is free to swap in another vSwitch though most open-source vSwitches are typically a variant of OVS and have pretty similar performance characteristics.
Regardless of virtualization environment in use, when we speak with customers the conversation quickly turned a discussion on vSwitch performance and how to accelerate the vSwitch and how to coordinate the vSwitch the the TOR switches.
While working on an OpenStack project, we learned that 6WIND as working to optimize OVS and decided to review their approach to solving OVS scalability and asked them to share their view on SDNCentral. As a result, 6WIND authored a blog post for SDNCentral, to examine and explain SDN performance from 6WIND’s point of view while describing some benefits specific to 6WIND.
For more information about 6WIND click here.