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:
- Can you measure and guarantee the performance of your infrastructure on behalf of my application?
- 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.
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.