Hyper-V VS VMware vsphere, who wins

VMware and Microsoft, the two giants have been in the field of server virtualization has many years of experience in the fight. However, compared to Microsoft, VMware's seniority is much older, he is more than 10 years earlier than Microsoft began to focus on the market.

IT staff or organizations have no choice but to actively grasp the differences between the Microsoft Hyper-V and VMware vsphere architectures and proactively understand the strengths and weaknesses of both technologies. Only in this way can they provide an ideal virtualization solution for employees or customers, or deploy it to a production environment.

In the face of the dilemma between VMware vsphere and Microsoft Hyper-V, we need to take a careful look at the many important components they contain, but from a schema perspective, the following components play the most critical role in choosing the ideal server virtualization product:

· Device driver positioning in the architecture;

· Control layer components;

· Manage program layer components;

In general, virtualization vendors typically provide the following three types of virtualization schemas, respectively:

· Type 2 VMM

· Type 1 VMM

· Hybrid VMM

Since this article does not elaborate on the specific meaning of three types of virtualization architectures, the content is focused on the Typer 1 VMM. Microsoft Hyper-V and VMware use the Type 1 VMM architecture to implement their own server virtualization technologies.

Type 1 VMM can be further divided into two broad categories, namely monolithic Hypervisor design (SCM) and microkernelized Hypervisor design (micro-kernel management program). Both designs use a three-tier structure in different components of a virtualized product.

The lowest level is called the "hardware Layer", and the virtualization feature relies on the hypervisor layer, which runs directly on the hardware layer. The top level is called the "control Layer", and the overall goal of the control layer is to control the component objects running in that layer and provide the virtual machines with the necessary components to communicate with the management program layer.

Note: The hypervisor layer is sometimes referred to as the "VMM layer" or "VM kernel layer".

Design of micro-kernel management program

Microsoft Hyper-V uses a micro-kernel management program that does not force the device driver to function as part of the hypervisor layer--device drivers operate independently in a "control layer", as shown in the following illustration:

Micro-Kernel Management program design has the following advantages:

· Device drivers do not need to intervene in the "Management program layer" or the VMM kernel.

· Because Microsoft does not provide an application programming interface (API) for accessing the management program layer, the attack surface of the system is significantly reduced. It is not possible for a malicious person to inject external code into the "Management level".

· Device drivers do not need to be identified by a management program, so the breadth of the Microkernel Management Program design Architecture in device support is greatly expanded.

· You do not need to close the management level to load device drivers. Device drivers can be installed in the operating system running on the control layer (such as Windows Server 2008, R2, and Windows Server 2012), and the virtual machines will use them to access hardware in the hardware layer.

· Because the maintenance and management of device drivers are not considered, the management layer becomes easier to manage.

· The Microkernel management program design allows users to install any server role other than the Server virtualization role (Hyper-V itself) in the control layer.

· Initialization time is shorter. Microsoft's management program code is only about 600KB, so the "management layer" does not need to take too long to initialize the component.

Having said so many advantages, there are some drawbacks to the Microkernel Management program architecture, the most noteworthy of which are the following:

· The micro-Kernel manager schema enforces that the user installs the operating system in the control layer, otherwise the management layer will not execute. This is also one of the most fatal drawbacks of the architecture.

· If the operating system running in the control layer crashes for some reason, all other virtual machines will also crash.

· While the management layer is manageable, the "control layer" hosting the operating system becomes difficult to maintain, and we need to devote a lot of effort to the communication between the virtual machine and the management program layer.

• To ensure the security of the Windows operating system, the technical department needs to do a serious job of maintaining a timely installation of security update patches released by Microsoft. Therefore, the operating system running in the control layer must always undergo a final security upgrade. As part of the security update effort, the operating system will be restarted frequently, which will directly cause all virtual machines to be offline-to avoid downtime, we can only use the power of Hyper-V real-time migration to move all virtual machines to other nodes in the cluster.