微软的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以及故障转移集群。
联系客服