Hyper-V 與 VMware ESXi 的不同之處

ifsapp

Hyper-V 與 VMware ESXi 對於 IT 人來說並不陌生，而要數不同之處有很多，其中最直接簡單，就連不懂 IT 的都知，就是 Hyper-V 要比 VMware 便宜(在大部份情況下)；而較為深入一點的則可以說 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 設計有一些細微的分別，那就是設備驅動位置以及其控制功能。

Hyper-V 與 VMware ESXi 的不同之處

在 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 核心的一部分，所以只能夠在被 VMware 支援的硬件上安裝 ESXi。而微軟 Hyper-V 架構不存在這種限制，能夠在任何硬件上運行 hypervisor 代碼。這降低了維護設備驅動方面的支出。使用 microkernelized 設計的另一個優勢在於不需要在每台虛擬機上安裝單一設備驅動。毫無疑問 ESXi 也部署了直接與硬件溝通的虛擬化組件，但你無法增加其他角色或服務。儘管不建議在 hypervisor 上安裝任何其他角色及功能，但運行 Hyper-V 的主機還可以被配置為具有其他角色，例如常見的 DNS 以及故障轉移集群等，這就是常說的 IT 靈活性；至於是否於 hypervisor 上安裝種種不同的東西，那則要視乎管理人員的技術及能力，並非官方或坊間不建議而不做，而是評估能力及形勢後，再想想是否可行；想清楚、對艱難的事下決定，IT 人價值高低，由此區分。