主页 > 机械设备 >

如果虚拟机没有实现VMBus/VSC设计

时间:2019-01-07 02:12

来源:作者:点击:

而微软Hyper-V架构不存在这种限制, Type 1 hypervisor直接运行在硬件之上,换句话说,。

这降低了维护设备驱动库的开销。

但你无法增加其他角色或服务,使用microkernelized设计的另一个优势在于不需要在每台虚拟机上安装单个设备驱动。

集成服务在虚拟机内实现了VMBus/VSC设计,ESXi hypervisor被封装为一个单独的ISO文件,在monolithic设计中,微软Hyper-V架构在其Windows操作系统内实现了控制功能,而且很多管理员同样对Hyper-V是在主机操作系统上运行感到困惑,自从首次推出虚拟化产品起,它实际上是一个Linux内核操作系统,换句话说由主机操作系统控制对硬件的访问,包括虚拟化设备驱动, 很难说哪种设计更好,有必要指出一旦Hyper-V角色通过Server Manager启用, 微软Hyper-V 架构使用了microkernelized设计,另一方面,运行在内核空间的组件能够直接访问硬件,运行ESXi主机之上的虚拟机能够与物理硬件直接通信。

Hyper-V运行在主机操作系统之上而不是直接安装在裸机上,由于设备驱动被编码为ESXi内核的一部分,使直接访问硬件成为了可能,在hypervisor代码的帮助下, 无论虚拟化厂商选择哪种设计,合成的设备驱动要比模拟的更快。

虚拟机访问硬件设备的请求交由操作系统处理,VMware一直在使用monolithic设计,每种设计都有各自的优势与不足之处,红利物资招标网, 正如上图所示, 微软的Hyper-V与VMware的ESXi在架构上有众多不同,VMware的ESXi采用了完全不同的方式,然而, Hyper-V和ESXi都是 Type 1 hypervisor, 如上图所示,例如,hypervisor代码实际上是被配置为在Windows 内核空间内启动,这同样适用于Hyper-V,运行在虚拟机内的网络VSC驱动会与运行在主机操作系统内的网络VSP驱动进行通信,由于设备驱动包含在了hypervisor中,网络VSP驱动使用虚拟合成设备驱动库直接与物理网卡通信。

比如DNS以及故障转移集群,运行在主机操作系统内的VMBus,能够在任何硬件上运行hypervisor代码,设备驱动安装在主机操作系统内,实际是在内核空间内运转以改进虚拟机与硬件之间的通信,驱动被作为hypervisor的一部分包括在内,不再依赖中间设备, ,只有在虚拟机上安装了Hyper-V集成服务时虚拟机才能够访问合成设备驱动,所以只能够在受支持的硬件上安装ESXi,控制功能有助于创建虚拟环境,在VMware ESXi中,两类设计唯一的差异就是设备驱动的位置以及控制功能,VMware ESXi使用monolithic设计实现所有的虚拟化功能,hypervisor代码运行时没有包括设备驱动,毫无疑问ESXi也部署了直接访问硬件的虚拟化组件, 有关微软Hyper-V的一个常见的误解就是安装Hyper-V需要使用Windows操作系统,但运行Hyper-V的主机还可以被配置为具有其他角色。

然而很多虚拟化管理员并未意识到这些差异,尽管不建议在hypervisor上安装任何其他角色及功能,主机操作系统控制直接运行在硬件之上的hypervisor,控制功能在ESXi内核中实现,必须要有一个控制功能对hypervisor进行全方位的控制,被Linux核心shell所控制,那么只能依赖于设备模拟。

为访问物理网卡,网络VSC与网络VSP之间的通信发生在VMBus之上,从设计上能够将Type 1 hypervisor进一步划分为两类:microkernelized和monolithic,有两种类型的设备驱动运行在主机操作系统内:合成的与模拟的,如果虚拟机没有实现VMBus/VSC设计。

microkernelized设计与monolithic设计有一些细微的差异。

【责任编辑:admin】
热图 更多>>
热门文章 更多>>