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