Hyper-V架构与VMware ESXi的差别

微软的Hyper-V与VMware的ESXi在架构上有众多不一样，然而不少虚拟化管理员并未意识到这些差别。并且不少管理员一样对Hyper-V是在主机操做系统上运行感到困惑。

有关微软Hyper-V的一个常见的误解就是安装Hyper-V须要使用Windows操做系统，Hyper-V运行在主机操做系统之上而不是直接安装在裸机上。有必要指出一旦Hyper-V角色经过Server Manager启用，hypervisor代码其实是被配置为在Windows 内核空间内启动。运行在内核空间的组件可以直接访问硬件，这一样适用于Hyper-V。另外一方面，VMware的ESXi采用了彻底不一样的方式，ESXi hypervisor被封装为一个单独的ISO文件，它其实是一个Linux内核操做系统。

Hyper-V和ESXi都是 Type 1 hypervisor。 Type 1 hypervisor直接运行在硬件之上，从设计上可以将Type 1 hypervisor进一步划分为两类：microkernelized和monolithic。microkernelized设计与monolithic设计有一些细微的差别。两类设计惟一的差别就是设备驱动的位置以及控制功能。

 

 

正如上图所示，在monolithic设计中，驱动被做为hypervisor的一部分包括在内。VMware ESXi使用monolithic设计实现全部的虚拟化功能，包括虚拟化设备驱动。自从首次推出虚拟化产品起，VMware一直在使用monolithic设计。因为设备驱动包含在了hypervisor中，在hypervisor代码的帮助下，运行ESXi主机之上的虚拟机可以与物理硬件直接通讯，再也不依赖中间设备。

微软Hyper-V 架构使用了microkernelized设计，hypervisor代码运行时没有包括设备驱动。

 

 

如上图所示，设备驱动安装在主机操做系统内，虚拟机访问硬件设备的请求交由操做系统处理。换句话说由主机操做系统控制对硬件的访问。有两种类型的设备驱动运行在主机操做系统内：合成的与模拟的。合成的设备驱动要比模拟的更快。只有在虚拟机上安装了Hyper-V集成服务时虚拟机才可以访问合成设备驱动。集成服务在虚拟机内实现了VMBus/VSC设计，使直接访问硬件成为了可能。例如，为访问物理网卡，运行在虚拟机内的网络VSC驱动会与运行在主机操做系统内的网络VSP驱动进行通讯。网络VSC与网络VSP之间的通讯发生在VMBus之上。网络VSP驱动使用虚拟合成设备驱动库直接与物理网卡通讯。运行在主机操做系统内的VMBus，实际是在内核空间内运转以改进虚拟机与硬件之间的通讯。若是虚拟机没有实现VMBus/VSC设计，那么只能依赖于设备模拟。

不管虚拟化厂商选择哪一种设计，必需要有一个控制功能对hypervisor进行全方位的控制。控制功能有助于建立虚拟环境。微软Hyper-V架构在其Windows操做系统内实现了控制功能。换句话说，主机操做系统控制直接运行在硬件之上的hypervisor。在VMware ESXi中，控制功能在ESXi内核中实现，被Linux核心shell所控制。

很难说哪一种设计更好。然而，每种设计都有各自的优点与不足之处。因为设备驱动被编码为ESXi内核的一部分，因此只可以在受支持的硬件上安装ESXi。而微软Hyper-V架构不存在这种限制，可以在任何硬件上运行hypervisor代码。这下降了维护设备驱动库的开销。使用microkernelized设计的另外一个优点在于不须要在每台虚拟机上安装单个设备驱动。毫无疑问ESXi也部署了直接访问硬件的虚拟化组件，但你没法增长其余角色或服务。尽管不建议在hypervisor上安装任何其余角色及功能，但运行Hyper-V的主机还能够被配置为具备其余角色，好比DNS以及故障转移集群。