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