One of the areas where VMware vSphere has had a large advantage over Microsoft Hyper-V has been in the architecture and capabilities of the VMware vSphere Virtual Switch. The most important of these capabilities has been the ability to designate one or more ports on the switch as promiscuous or mirror ports. These ports make a read only copy of all of the data flowing through the switch available to whatever virtual machine is sitting on that port. This is an essential capability for many security products and also performance management solutions like those from ExtraHop Networks that rely upon deep packet inspection to work.

The Windows Server 8 Hyper-V 3 Extensible Switch

With the new switch in Hyper-V 3, Microsoft has added the missing mirror features that have long been present in vSphere, and then gone beyond just catching up and added several new very significant capabilities. These capabilities are based upon the architecture of the Hyper-V Extensible Switch which leverages both the NDIS 6.0 driver architecture and the Windows Filtering platform. The important thing here is not only has the mirror port been added, but the switch can be extended by third parties. The architecture of the new switch is shown below.

 

VMware has ruled the domain of who gets to put kernel level code into their hypervisor with an iron fist. This has, of course, contributed significantly to the stability and scaleability of the vSphere platform. Microsoft has long allowed Windows to be extended both with applications, but more importantly with Kernel level enhancements like network and file system filter drivers. Now it appears that Microsoft is going to take its approach towards open and extensible architectures into the Hyper-V realm.

Leveraging these open API’s and more importantly allowing third parties to extend the functionality of the switch plays to one of Microsoft’s core strengths and one of VMware’s core weaknesses. VMware has made vSphere into a success by not allowing third parties to contribute code at the kernel layer (with rare exceptions in the security space). Now that Microsoft has caught up in one of these important areas, and provided an architecture extensible by third parties, VMware is not only up against the development team at Microsoft, they are up against Microsoft and the entire Windows enhancement ecosystem. This is exactly how Microsoft wants it to be.

The Infrastructure Performance Management and Applications Performance Management Challenges

It is well known that VMware has successfully virtualized a bit less than half of the servers in the installed base of its own customers. It is also well understood that the servers that remain to be virtualized are running very different applications than the ones that already have been virtualized. The people that own those applications on those remaining physical servers always ask two questions when approached on the subject of virtualizing those applications:

  1. Can you measure and guarantee the performance of your infrastructure on behalf of my application?
  2. Can you measure and guarantee the performance of my application on your virtualized and shared infrastructure?

Today, the answer to the first question is no. The reason that it is no, is that unlike in the physical realm, one cannot infer the actual performance of a virtual infrastructure by looking a resource utilization statistics. In order to understand the performance of a virtual infrastructure you have to first define infrastructure performance as end-to-end latency on behalf of each workload and then measure this on a real-time, deterministic and comprehensive basis. This is not possible today with the data that most monitoring vendors rely upon from VMware (the vSphere API data), which is 20 second resource utilization data rolled up (averaged) at the five minute level. Today we are in the situation where a vendor like Virtual Instruments can see the SAN in real time, and Xangati can see the network in real time, but no one can see the entire infrastructure in real time.

The Microsoft Hyper-V 3 Extensible Switch has the potential to dramatically improve this situation for Hyper-V 3 by allowing Infrastructure Performance Management vendors to combine code running at the driver level (to, for example, filter packets) with code running to a virtual appliance (to analyse packets). This has the long term potential of making Hyper-V into a superior platform for virtualization of business critical applications to vSphere due to performance management functionality.

The second question involves the need for the people who support virtual infrastructures to be able to assure applications owners that their applications are “fine” from a response time perspective. This is driving the creation of a new organizational unit in my IT shops responsible for the performance of all applications – which is often called “Application Operations”. The key requirements for an Applications Operation team is that the monitoring product work for every application in the environment, that it be extremely easy to deploy, that it automatically discover applications, and that it self-configure the monitoring for these applications. The new Hyper-V 3 Extensible Switch also offers APM vendors the opportunity to dramatically enhance their functionality in the Hyper-V realm with respect to what is possible on vSphere.

Conclusion

With the Windows Server 8 Hyper-V 3 Extensible Switch, Microsoft will close a gap (the ability to configure a mirror port on the vSwitch), and open a new front in the war with VMware. That new front will come from enabling third party vendors to extend the functionality of the Microsoft vSwitch at the kernel (device driver) level – something that is not generally possible with the VMware vSwitch. This is significant both because it creates new capabilities for management, and because it allows Microsoft to exploit a long standing advantage (third party ecosystem support for Windows) in Hyper-V to the detriment of VMware.

Share this Article:

Share Button
Bernd Harzog (332 Posts)

Bernd Harzog is the Analyst at The Virtualization Practice for Performance and Capacity Management and IT as a Service (Private Cloud).

Bernd is also the CEO and founder of APM Experts a company that provides strategic marketing services to vendors in the virtualization performance management, and application performance management markets.

Prior to these two companies, Bernd was the CEO of RTO Software, the VP Products at Netuitive, a General Manager at Xcellenet, and Research Director for Systems Software at Gartner Group. Bernd has an MBA in Marketing from the University of Chicago.

Connect with Bernd Harzog:


Related Posts:

2 comments for “The Windows Server 8 Hyper-V 3 Extensible Switch

  1. BP
    April 6, 2012 at 2:31 PM

    Hi,

    as Hyper-V in version 3 is still using the Parent VM where all the slow response can be expected again. Also VMware has it’s code open to Cisco with it’s Nexus family and interoperability is great, even better than with native switching technologies so i don’t know why are you talking about VMware’s weaknesses in terms of networking. What about long lasting native failover and load balancing option that VMware has and MS is trying to announce…What about VMware VXLAN extension of L2 switch you should really take a look at VMware’s networking activities before even considering comparing it with MS. Or is this just another blog bought by MS with regards to activity…we don’t care about hypervisor as they are all the same. They are not, and Hyper-V even in V3 is far behind vSphere 4.1 w/t mentioning vSphere 5.

  2. Bharzog
    April 10, 2012 at 7:26 AM

    My point about openeness was simply that Microsoft has an open device driver architecture (NDIS) and an open packet filtering API, that makes it easy for ISV’s to add functionality to the upcoming release of Hyper-V. The good thing about this is that it encourages innovation in the community of vendors that support these technologies. VMware has drawn the line in a different place – choosing not to open up its device driver layers, resulting in less innovation but probably more stability and performance. There is no panacea here, you cannot have a device driver layer that is open to rapid innovation and that has the stability and performance of vSphere. Both are choices that come with benefits and tradeoffs.

Leave a Reply

Your email address will not be published. Required fields are marked *


9 + five =