したがって、既に知っているように、Hyper-VはVirtual Serverに代わるMicrosoftのサーバー仮想化プラットフォームです。 後者とは異なり、Hyper-Vはスタンドアロン製品ではなく、Windows Server 2008のコンポーネントにすぎません。Hyper-Vの役割をインストールした後、Windows Server 2008に何が起こるかを見てみましょう。
ご覧のとおり、Hyper-Vの役割をインストールした後、システムアーキテクチャは大きく変わります。それ以前にOSがメモリ、プロセッサ、ハードウェアと直接連携していた場合、インストール後にハイパーバイザがメモリとプロセッサ時間の配分を制御します。 いくつかの新しいコンポーネントも表示されますが、これについては後で説明します。 Hyper-Vのインストール後、システムは、ゲストOS（いわゆるパーティション）が起動する分離環境を作成します。 ハードドライブのパーティションと混同しないでください。 ホストOS自体は、Hyper-Vのインストール以降、親パーティションと呼ばれる分離されたパーティションでまったく同じように機能します。 ゲストOSが起動されるパーティションは、子パーティションと呼ばれます。 親パーティションと子パーティションの違いは、親パーティションのみがサーバーハードウェアに直接アクセスできることです。 他のすべてのパーティションは、相互およびサーバー自体のハードウェアから完全に分離されています。 ハードウェアとのすべてのやり取りは、ホストOS内で動作するドライバー、つまり親パーティションを介して行われます。 各仮想マシンには、いわゆる仮想デバイスバス（VMBus）を介して親パーティションと対話する仮想デバイス（ネットワークアダプター、ビデオアダプター、ディスクコントローラーなど）のセットがあります。 そして、すでに親パーティションにある、仮想デバイスへのすべての呼び出しは、ハードウェアドライバーに転送されます。 これは、Hyper-VとVMware ESXの根本的な違いです。ESXでは、デバイスドライバーはハイパーバイザー自体に「マウント」されます。 良くも悪くも、確実に言うことは不可能です。 一方で、それは確かに優れています。ESXハイパーバイザーは、ホストOSを必要とせずに独立して動作できるため、必要なメモリとディスクスペースがはるかに少なくなります。 一方、サポートされるハードウェアのリストは非常に限られており、ESXに新しいドライバーをインストールすることはできません。 そのため、たとえば、特殊なハードウェア機能をサポートする新しいドライバーが表示されるときにVMware ESXを使用する場合、ハイパーバイザーの新しいバージョンを待つ必要がある状況が発生する場合があります。 反対の状況も考えられます。鉄を新しいものに交換する場合、新しいハイパーバイザーに切り替える必要がある場合があります。 Hyper-Vでは、ホストOSに適切なドライバーをインストールするのは非常に簡単です。
次に、ホストOSに加えて、さらに3つの仮想マシンが実行されているHyper-V環境を考えます。 それらの1つには、Windowsがインストールされ、統合コンポーネントがインストールされ（Windows 7およびWindows Server 2008 R2には統合コンポーネントが含まれます）、もう1つには、統合コンポーネントをサポートしない（または単にインストールされない）OSがインストールされ、3番目がインストールされます統合コンポーネントが存在するLinux（現在、SLESとRHELのみがサポートされています）。
そのため、親パーティションのユーザースペースには、次のものがあります。
- WMIプロバイダー -ローカルとリモートの両方で仮想マシンを管理できます。
- 仮想マシン管理サービス（VMMS） -実際には、仮想マシンを管理します。
- 仮想マシンワークフロー（VMWP） -仮想マシンのすべてのアクションが実行されるプロセス-仮想プロセッサ、デバイスなどへのアクセス
親パーティションのカーネル空間で実行されます：
- 仮想インフラストラクチャドライバー（VID） -パーティション、プロセッサ、および仮想マシンのメモリを管理します。
- 仮想化サービスプロバイダー（VSP） -VMBusおよびゲストOS側の統合コンポーネントを使用して、仮想デバイス（いわゆる「合成デバイス」 ）の特定の機能を提供します。
- 仮想デバイスバス（VMBus） -子パーティションと親パーティション内の仮想デバイス間で情報を交換します。
- デバイスドライバー -上記のように、親パーティションのみがハードウェアデバイスに直接アクセスできるため、すべてのドライバーが機能するのはその中にあります。
- Windowsカーネルは、ホストOS自体の中核です。
ここで、仮想マシン自体を検討します。 既に述べたように、各仮想マシンは、パーティションと呼ばれる独自の隔離された環境で実行されます。 各仮想マシン内には、仮想化サービスクライアント（VSC）があります。これは、ゲストOSに仮想デバイスのインターフェースを提供し、VMBusを介して親パーティションと対話します。 統合コンポーネントがゲストOS（XPおよびServer 2003以降のすべてのバージョンのWindows、および一部のLinuxバージョン-SLESおよびRHEL）内にインストールされている場合、いわゆる合成デバイス、つまりHyperに固有の特定の仮想デバイスを使用できます-V機能。 たとえば、VMQ仮想ネットワークアダプターまたは仮想SCSIコントローラーのサポート。 これらの特定の機能はすべて、親パーティションで実行されている仮想化サービスプロバイダー（VSP）によって提供されます。 また、VMBusを通過する仮想マシンからの要求を変換し、物理デバイスドライバーに転送します。 統合コンポーネントがゲストOSでサポートされていない場合、またはインストールされていない場合は、エミュレートされたデバイス（レガシーネットワークアダプター、仮想IDEコントローラーなど）が使用されます。 この場合、VMBusは使用されず、ゲストOSはエミュレートされたデバイスのドライバーをハイパーバイザーで直接使用します。 ハイパーバイザーは、カーネル空間ではなくユーザー空間で実行される仮想マシンワークフロー（VMWP）を介して、これらの要求を親パーティションのデバイスドライバーに転送します。 これはパフォーマンスに大きく影響するため、エミュレートされたデバイスを使用しないことを強くお勧めします。 ゲストOSが統合コンポーネントのインストールをサポートしていない場合にのみ使用できます。 そのようなOS（* BSD、Linuxのサポートされていないバージョンなど）が組織で積極的に使用されている場合、同じVMware ESXなど、他の仮想化プラットフォームについて検討する必要があります。
仮想マシンがホストOSまたはハードウェアと相互にやり取りする他の方法はありません。 これはセキュリティの目的で行われました。仮想マシンはホストOSと相互に通信でき、ネットワークインターフェイスを介してのみ相互に通信できます。USBまたはPCIの「デバイス転送」はありません。 これもまた両刃の剣です。一方ではセキュリティが向上しますが、一方ではゲストOSがHASPキーやモデムなどの特定のデバイスを使用することを許可しません。 したがって、ゲストOSでそのようなデバイスを使用する必要がある場合（たとえば、1Cのソフトウェアがそこにインストールされており、実行するにはハードウェアHASPキーが必要です）、TCP / IPネットワークを介したUSB転送などのトリックを使用する必要があります。 これは通常、サードパーティのソフトウェアを使用して行われます。
ハイパーバイザー自体がメモリとプロセッサ時間の割り当てを処理します。 VMware ESXとは異なり、Hyper-Vハイパーバイザーには、サードパーティの開発者が作成したデバイスドライバーとコンポーネントは含まれていません。 これにより、ハイパーバイザー自体のサイズを縮小し、その信頼性とセキュリティを高めることができます。 既に述べたように、ゲストOSは物理プロセッサまたは割り込みに直接アクセスできません。 スケジューラーの役割を果たし、設定に従って各パーティション（親を含む）のプロセッサー時間を割り当てるハイパーバイザー、パーティションから割り込み要求を受信して物理プロセッサーに変換するハイパーバイザー、仮想マシンにメモリー領域を割り当て、受信したアドレスを変換するハイパーバイザーですパーティションから物理アドレスまで。 パーティション管理は、いわゆるハイパーコールインターフェイスを介してホストOSによって実行されます。 ハイパーバイザーを管理するためのユーザーインターフェイスは、仮想インフラストラクチャドライバー（VID）を介してWMIプロバイダーによって提供されます。
これで、おそらく、最初の部分は終了します。 次の記事では、Hyper-Vがストレージデバイス（ハードドライブ、外部ストレージなど）でどのように機能するかについて説明します。