无论采用什么内核，驱动程序和文件系统总是必要的，虚拟机需要使用服务器的硬件就需要驱动程序，虚拟机的文档需要保存在适当的文件系统上。在单内核的VMware ESX Server上，驱动程序包含在单内核内部，虚拟机映像文件则保存在VMFS（一种类似EXT的文件系统）上，那么微内核架构的Hyper-V呢？

　　这就要谈到Hyper-V的VSP/VSC架构了，VSP是Virtualization Service Provider（虚拟化服务提供者），VSC则是Virtualization Services Consumer（虚拟化服务消费者），还有一个VMBus部件将放在“宿主操作系统”的VSP和虚拟机操作系统的VSC连接起来。实际上“宿主操作系统”也是一个虚拟机——就是你最初安装的、带有Hyper-V的Windows Server 2008，微软将其称为Parent Partition操作系统，而每一个虚拟机则称为Child Partition，虚拟机操作系统则称为Child Partition操作系统。

VSP与VPC，注意VSP并不是Virtual Storage Provider的缩写。Virtual Storage Provider属于VSP的一种

　　上图很好地解释了Hyper-V使用VSP/VSC架构解决驱动程序/文件系统的方式，通过加入VSP和VSC以及它们互相沟通的VMBus总线，Hyper-V将虚拟机的操作映射入Parent Partition的对应驱动程序/文件系统中，简化起来就如下图：

Hyper-V的VSPs/VSCs、VMBus架构

　　这种方式具有不少好处，例如，最明显地，Hyper-V可以兼容大量的驱动程序，而不必为虚拟机开发专用的驱动程序（ESX Server就是这样干的）。我们知道对于服务器而言，很重要的一个组成部分就是I/O，一个IO设备没有驱动程序是无法工作的。现在，只要设备能在Windows Server 2008下工作，那么Hyper-V虚拟机就能使用这些设备资源，再加上Windows驱动天生就比其他操作系统（如Linux）的驱动丰富，因此在硬件支持上Hyper-V具有着无可比拟的优势。VMware ESX Server甚至不能直接应用Linux驱动程序，需要另外进行额外的操作才能使用，因此VMware ESX Server容易遇到设备兼容性方面的问题，当然用户可以使用具备VMware认证的全套硬件以避免这个问题。

　　有利就有弊，VSP/VSC架构需要支持Hyper-V技术的客户端的支持，这样就大为限制了虚拟机操作系统的选择，不支持Hyper-V的客户操作系统只能使用设备模拟的方式，性能和以前的Virtual Server 2005 R2没有太大的分别，要享受到Hyper-V性能的提升，需要虚拟机使用Windows Server 2008，或者内含Xen的Linux/Unix。Hyper-V的客户机操作系统的选择确实只注明了Windows和少数几种Linux，虽然笔者猜测或多或少有着商业策略上的因素，不过从技术上来看，确实也有一些限制。

　　Hyper-V设备驱动的这个优点正好就和微内核驱动程序架构的优点一样，模块化，架构灵活，不需要更改就可以提供新硬件的支持。敏锐地用户可能会觉察到进程间通信带来的开销——确实有这样的问题，笔者曾询问微软的工程师，他们表示性能会有一点点地折扣。从笔者来看，通过内存地址转换的方式，开销有可能降到非常低。

　　顺便提一下，设备虚拟硬件辅助VT-d技术在Hyper-V下的实现很轻松，只需要开发Windows Server 2008下的驱动程序，不需要对Hyper-V进行改动。