admin 管理员组文章数量: 887021
2024年3月12日发(作者：微信小程序游戏制作平台)
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以及故障转移集群。
版权声明：本文标题：Hyper-V架构与VMware ESXi的差异 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/free/1710229927h565011.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论