Hyper-V and VMware vSphere Architectures: Pros and Cons

Tuesday Apr 30th 2013 by Nirmal Sharma
Share:

With Microsoft Hyper-V and VMware vSphere tackling virtualization in their own distinct ways, it's important to know the key advantages and disadvantages of each design architecture employed by the two.

Both VMware and Microsoft have been in the server virtualization scene for a number of years — VMware for more than a decade now, while Microsoft entered into it relatively recently.

It is imperative for IT workers or organizations to understand the differences between the Microsoft Hyper-V and VMware vSphere architectures as well as the advantages and disadvantages each technology offers before they propose the virtualization solutions to their customers or employees — or before using it in a production environment.

There are a number of important components to consider when choosing either VMware vSphere or Microsoft Hyper-V, but from an architecture standpoint of view, the following components play an important role when it comes to choosing the right server virtualization product:

  • Device Driver Location in the architecture
  • Controlling Layer components
  • Hypervisor Layer components

In general, there are three types of virtualization architectures virtualization vendors refer to. They are:

  • Type 2 VMM
  • Type 1 VMM
  • Hybrid VMM

Server Tutorials While explaining all three types of virtualization architecture is out of the scope of this article, the one that we'll primarily focus on in this article is the Type 1 VMM. Type 1 VMM is what Microsoft Hyper-V and VMware are using to implement their server virtualization technologies.

Type 1 VMM can be further divided into two subcategories: Monolithic Hypervisor Design and Microkernelized Hypervisor Design. Both designs have three layers in which different components of virtualization product operate.

The lowest layer is called the "Hardware Layer" and is virtualized by the "Hypervisor layer" running directly on top of the "Hardware Layer." The top layer is called "Controlling Layer." The overall objective of the "Controlling Layer" is to control the components running in this layer as well as provide the necessary components for virtual machines to communicate with the "Hypervisor Layer."

Note: The "Hypervisor layer" is sometimes referred as "VMM Layer" or "VM Kernel Layer."

Microkernelized Hypervisor Design

The Microkernelized Hypervisor Design is used by Microsoft Hyper-V. This design does not require the device drivers to be part of the Hypervisor layer — the device drivers operate independently and run in the "Controlling Layer" as shown in the image below:

Microsoft Hyper-V Microkernelized Hypervisor Design

The Microkernelized Hypervisor Design provides the following advantages:

  • Device drivers are not needed for each device to be incorporated in the "Hypervisor Layer" or VMM Kernel
  • Since Microsoft does not provide Application Programming Interfaces (APIs) to access the "Hypervisor Layer," the attack surface is minimized. No one can inject foreign code in the "Hypervisor Layer."
  • Device Drivers do not need to be hypervisor-aware. So a wide-range of devices can be used with the Microkernelized Hypervisor Design.
  • There is no need to shut down "Hypervisor Layer" to include the device drivers. The Device Drivers can be installed in the Operating System running in the "Controlling Layer" (Windows Server 2008, R2, and Windows Server 2012) and used by the Virtual Machines to access the hardware in the "Hardware Layer."
  • "Hypervisor Layer" has less overhead for maintaining and managing the Device Drivers.
  • The Microkernelized Hypervisor Design allows you to install any other server roles in the "Controlling Layer" apart from Server Virtualization role (Hyper-V).
  • There is less initialization time required. The Microsoft Hypervisor code is only 600 KB or so in size.  As a result, the "Hypervisor Layer" does not require more time to initialize its components.

At the same time, there are a few disadvantages associated with the Microkernelized Hypervisor Design that are important to highlight:

  • The Microkernelized Hypervisor Design requires an operating system to be installed in the "Controlling Layer" before the "Hypervisor Layer" can operate. This is the biggest disadvantage.
  • If the operating system running in "Controlling Layer" crashes for any reason, then all other virtual machines will also crash.
  • More overhead is required for the operating system running in the "Controlling Layer" to manage the communications between the virtual machines and the "Hypervisor Layer."
  • Every organization maintains the security of Windows operating systems by means of applying security updates released by Microsoft. So the operating system running in the "Controlling Layer" must also be applied with the latest security updates.

    As part of the security updates, the Operating System will be rebooted, which in turn requires you to take all virtual machines offline — or move to another node in the cluster without any downtime with the help of Hyper-V Live Migration feature.

Monolithic Hypervisor Design

As you can see in below figure, VMware's vSphere uses the Monolithic Hypervisor Design, which requires the hypervisor-aware device drivers to be hosted in and managed by the "Hypervisor Layer." This is what we see in the "Hypervisor Layer" in the below diagram; the device drivers are part of it:

Hypervisor device drivers must be developed and included in the "Hypervisor Layer" before you can start using the vSphere virtualization product. You cannot run VMware vSphere on hardware that is unsupported.

VMware vSphere operates its components in the "Hypervisor Layer" as shown in the above figure. Product components that it operates are Resource Scheduling, Distributed File System, etc. The Network Stack component, which is responsible for implementing the VMware networking, also operates in the "Hypervisor Layer." The Storage Stack component allows "Controlling Layer" components to access storage devices.

VMware vSphere Monolithic Hypervisor Design

The Monolithic Hypervisor Design provides the following advantages:

  • No operating system is required for controlling all the components of the virtualization product. This is the biggest advantage over the Microkernelized Hypervisor Design used by the Microsoft Hyper-V as discussed above.
  • No security patches are needed for components running in the "Controlling Layer."

Disadvantages of Monolithic Hypervisor Design:

  • VMware's vSphere does not work on hardware that is not supported. However, VMware has developed a list of compatible hardware on which VMware vSphere is able to run successfully. The list can be found at http://www.vmware.com/resources/compatibility/search.php.
  • More initialization time is required. In this design, the initialization time required for the VM Kernel depends on the size of device drivers included in it.
  • Since device drivers are initialized as part of the "Hypervisor Layer" initialization, any corrupted foreign code injected in the "Hypervisor Layer" can delay the booting/initialization or cause the server to hang in some cases.

Conclusion

In the article we discussed how Microsoft Hyper-V and VMware vSphere operate differently from each other. We explored how each of the virtualization products uses a different virtualization architecture: Microkernelized Hypervisor Design for Microsoft Hyper-V and Monolithic Hypervisor Design for VMware vSphere.

We also covered some of the primary advantages and disadvantages each virtualization product offers, which IT workers or organizations should find valuable when determining the best virtualization product for implementation in their production environment.


Nirmal Sharma
is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He has specialized in Microsoft Technologies since 1994 and has followed the progression of Microsoft Operating System and software. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Solution IDs for www.Dynamic-SpotAction.com.Nirmal can be reached at nirmal_sharma@mvps.org.

Follow ServerWatch on Twitter and on Facebook

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved