Hyper-V架構與VMware ESXi的差別

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