VMware与微软这两家巨头都已经在服务器虚拟化领域拥有多年打拼经验。不过，相对于微软，VMware的资历要老很多，他要比微软早十多年前就开始主攻这一市场。
IT员工或组织对于两者是在没办法选择，只能积极掌握微软Hyper-V与VMware vSphere架构之间的差别，并主动了解两种技术各自的优势与缺点。只有这样，他们才能为企业员工或客户提供理想的虚拟化解决方案或者将其部署到生产环境当中。
在面对VMware vSphere与微软Hyper-V的两难选择时，我们需要慎重考量二者各自所包含的很多重要组件;不过单从架构的角度来看，以下组件在选择理想服务器虚拟化产品中发挥着最为关键的作用：
· 架构中的设备驱动程序定位;
· 控制层组件;
· 管理程序层组件;
在一般情况下，虚拟化供应商通常会提供以下三种虚拟化架构类型，它们分别是：
· Type 2 VMM
· Type 1 VMM
· Hybrid VMM
由于本文并不会详细解释三种虚拟化架构类型的具体含义，内容主要集中在Typer 1 VMM。微软Hyper-V与VMware都采用了Type 1 VMM架构，并以此为基础实现各自的服务器虚拟化技术。
Type 1 VMM可以被进一步分成两大类别，即Monolithic Hypervisor Design(即单片式管理程序设计)与 Microkernelized Hypervisor Design(即微内核式管理程序设计)。两种设计都在虚拟化产品的不同组件中采用三层结构。
最底层被称为“硬件层”，而虚拟化功能则依靠直接运行在“硬件层”上的“管理程序层”来实现。最上层被称为“控制层”，“控制层”的总体目标是控制运行在该层中的组件对象，并为虚拟机提供与“管理程序层”进行通信的必要组件。
备注：“管理程序层”有时候也会被称为“VMM层”或者“VM内核层”。
微内核式管理程序设计
微软Hyper-V采用微内核式管理程序设计，这项设计并不强制要求设备驱动程序作为管理程序层中的组成部分——设备驱动程序以独立方式运作并以“控制层”为活动空间，如下图所示：
微内核式管理程序设计具备以下优势：
· 设备驱动程序无需介入“管理程序层”或者VMM内核。
· 由于微软公司并不提供用于访问“管理程序层”的应用程序编程接口(简称API)，因此系统的攻击面得以显著缩小。恶意人士不可能将外部代码注入“管理程度层”当中。
· 设备驱动程序不需要由管理程序来识别，因此微内核管理程序设计架构在设备支持方面的广泛性得到大幅扩展。
· 无需关闭“管理程度层”来加载设备驱动程序。设备驱动程序可以被安装在运行于“控制层”的操作系统当中(例如Windows Server 2008, R2以及Windows Server 2012)，虚拟机将利用其对“硬件层”中的硬件进行访问。
· 由于无需考虑设备驱动程序的维护与管理，“管理程序层”变得更容易打理。
· 微内核管理程序设计允许用户在“控制层”中安装除服务器虚拟化角色(Hyper-V本身)以外的任何服务器角色。
· 初始化时间更短。微软的管理程序代码只有约600KB，因此“管理程序层”不需要在初始化组件方面耗费太长时间。
说了这么多优势，微内核式管理程序架构也存在着一些缺点，其中最值得注意的部分有以下几点：
· 微内核式管理程序架构强制要求用户在“控制层”中安装操作系统，否则“管理程序层”将无法执行。这也是该架构最致命的一项缺点。
· 如果运行在“控制层”中的操作系统由于某种原因而发生崩溃，则所有其它虚拟机也将同时崩溃。
· 虽然“管理程序层”易于打理，但承载着操作系统的“控制层”却变得很难维护，我们需要在虚拟机与“管理程序层”之间的通信上投入大量精力。
· 为了保证Windows操作系统的安全性，技术部门需要认真进行维护工作，即及时安装由微软公司发布的安全更新补丁。因此运行在“控制层”中的操作系统也必须始终经过最终安全升级。作为安全更新工作的一部分，操作系统会被频繁重启，这将直接导致所有虚拟机处于离线状态——要想避免停机状况，我们只能借助Hyper-V实时迁移功能的力量将所有虚拟机移动到集群中的其它节点。