VMware Doesn’t Make Many Mistakes, but It Is with Respect to Physical Networking

Mike Fratto
Mike Fratto

Summary Bullets:

  • VMware dismisses physical networking as a mere forwarding plane, ignoring the benefits of integration.
  • If that observation is inaccurate, then VMware needs to address its messaging on the importance of physical networking.

Fresh off VMworld 2014, I came away with the very distinct impression that the company – not any specific individuals – is quite dismissive of physical networking, to the point where it is detrimental to its own success. While I continue to be impressed at how well the company develops new products, maintains a practical engineering focus, and seems to handle partner co-opetition with aplomb, it is also making a rather big mistake with ignoring the importance of integration with the physical network.

There were many factors attributable to both the success of hypervisors in the data center as well as VMware as a company. Part of that success relied on the introduction and continued improvements of virtualization support in x86 CPU from Intel and AMD. In addition, VMware (and other hypervisor makers) exposed more information from the server hardware to improve performance, increase stability, and provide visualizations to administrators. I am not saying that without these extensions we’d have no virtualization. I am saying that without them, server virtualization growth might have been slowed or been relegated to niche use cases. The integration of server hardware with virtualization software was mutually beneficial.

At one point during a presentation, a VMware representative dismissed networking as “a forwarding plane,” as if a network is like a server. It’s not. A server is a self-contained, discrete unit that contains dedicated processors and data busses. A network is an aggregation of cooperative products that interconnects many devices and supports a number of competing demands. A network is far more complex and far less controlled than a server. By dismissing the network as a mere forwarding plane, VMware is in essence tossing traffic to the network, saying “Here, deal with this,” and moving on.

Tossing data over the fence is all well and good, provided the underlying network is operating optimally, but that’s often not the case. NSX has some limited ways to signal to the physical network how to treat types of traffic, but it’s not particularly granular. We are seeing tangible improvement of traffic by having an application such as Microsoft Lync signal network equipment from companies such as Aruba or HP about connections between two nodes and allowing the network both to improve performance and to enable real-time quality monitoring. Similar benefits can be had if the virtual network could signal the physical network via integration of an application’s particular requirements. There is also the problem of having the information available for troubleshooting and monitoring. VMware and network administrators each need their own tools, already used in their work flows to monitor and troubleshoot issues; and to be efficient, they need to operate on the same data. VMware appears to want none of that, preferring everything to be managed at the virtual layer and above.

To give VMware the benefit of the doubt, it may not intend to send that message, but it is and I am not alone in hearing it. I talked with quite a few people who made similar observations or at least acknowledged the possibility when we spoke. If my observations are wrong, then VMware needs to address its messaging on how it sees the role and relative importance of the physical network in supporting a software-defined data center. I’d start by making nice with Cisco.

One thought on “VMware Doesn’t Make Many Mistakes, but It Is with Respect to Physical Networking

  1. I couldn’t agree with you more, Mike. Many folks have the mistaken belief that SDN will “commoditize the switch.” However, the interconnect infrastructure will only be as robust, reliable and flexible as the data forwarding plane — the network. Therefore, switches require a robust, field proven operating system, must be architected to deliver performance with acceptable latency, must include reasonably powered CPUs to deliver a variety of networking protocols and services. And finally to simply work in the “as promised” agile and scalable SDN paradigm, must have large forwarding tables. This is hardly a marginalized commodity “box.”

Leave a Reply to Derek (@DerekG100) Cancel reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.