Hypervisor型と位置付けられる仮想化ソフトウェアの中でも、XenとHyper-Vはマイクロカーネル型とされています。これはMicrosoftがHyper-VについてVMware ESXに対する優位性とする項目の1つとして挙げたモノシリック型 vs. マイクロカーネル型に由来する分類といえるのかもしれませんが、要はストレージやネットワークなどのドライバやI/O処理までをHypervisorカーネルに含めるか含めないか、という視点での分類です。MicrosoftのTechNetにあるこちらのページにも下記の図でその違いが示されています。
モノリシックハイパーバイザのアプローチでは、ハイパーバイザ (VMM) がホストされる 1 つの層に、必要なコンポーネントのほとんど (カーネル、デバイスドライバ、I/O スタックなど) が含まれています。これは、VMware ESX や従来のメインフレームシステムなどのソリューションで使用されるアプローチです。
マイクロカーネルのアプローチでは、主要タスクであるパーティションの分離とメモリの管理のみを実行する、非常に軽量な専用のハイパーバイザが使用されます。この層には、I/O スタックやデバイス ドライバは含まれません。これは、Hyper-V で使用されるアプローチです。このアーキテクチャでは、仮想化スタックとハードウェアに固有のデバイスドライバが、親パーティションと呼ばれる専用のパーティションに格納されます。
その違いによるメリット・デメリットについては本エントリーのテーマではないので深掘りはしませんが、要はHyper-Vの場合はWindows OS、Xenの場合はLinux/UNIX OSをディスク・ネットワークに関するI/O処理のために必要とするわけで、それにより汎用性と安定性の面でどちらのアプローチが優れているのか、という論戦が展開されています。
…で、同じマイクロカーネル型に分類されるがゆえにHyper-VとXenが似ている構造となることはまぁ必然とも言えるわけですが、XenSourceがCitirxに買収されたこともあって、Hyper-VとXenServerは仮想ディスクフォーマットVHDを使用することや仮想マシンの相互互換性の向上などにおいて連携を取るようになっています。LVM的な仕組みをOS標準で持っていなかったが故にMicrosoftはLive Migration技術や複数ノードからの共有ストレージ構成などにおいて色々と苦労しているようですが、逆にXenServerはクラスタ技術の面でMarathonの技術に頼るなど、こちらもこちらで色々な取り組みがなされているようです。ポイントはいずれも管理OSからくる制約に起因した課題に対して取り組みがなされている、ということ。逆に言えばHypervisorそのものはハードウェアの仮想化支援機能に依存した仕様という意味でも、結局はHyper-VとXenはかなり同じようなものであるといえるわけで、ソースコードが公開されていないHyper-Vについては、HypervisorとしてはWindows向けにアレンジしたXenなんでないの？と思ってしまったりするわけです。
別にだからどうとかいうこともないのですが、今後両者がそれぞれどのような発展を遂げていくことになるのか、結局はマイクロカーネル型の宿命として、別にHypervisor自体は必要最小限というコンセプトになりますので、管理OSにおける機能次第ということになるんでしょうね。
