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

原文摘自TechTarget虛擬化：

http://www.searchvirtual.com.cn/showcontent_85858.htm?info=virtualweekly20141114&asrc=EM_DWP_36400693&uid=14922731&utm_medium=EM&utm_source=DWP&utm_campaign=20141113_Hyper-V%E6%9E%B6%E6%9E%84%E4%B8%8EVMware+ESXi%E7%9A%84%E5%B7%AE%E5%BC%82_

轉載於:https://blog.51cto.com/ericxuting/1582123