ハイパーバイザー内にハイパーバイザーをデプロイできるのはなぜですか？
物理ハードウェア上にある必要があるとされるハイパーバイザーをVM内にデプロイできるのはなぜですか？
たとえば、XenServer（実際のハイパーバイザー）をESX VMに展開できますか？
なぜこれが可能なのですか（多くの理由で良い考えではありませんが、それでも機能します）。
また、ハイパーバイザーには物理ハードウェアが必要であると人々が言うのはなぜですか（明らかなパフォーマンス上の理由ではなく、アーキテクチャの観点から）。
ありがとう
ベアメタル ハイパーバイザー （ESX、Hyper-Vなど）は、ハードウェアへのアクセスを制御および監視するために設計されたオペレーティングシステムです。したがって、当然のことながら、仮想マシン内のハイパーバイザーは、アクセスできるハードウェアへのアクセスを制御および監視します。これは、仮想ハードウェアが実際のハードウェアとまったく同じように見えるために機能します。
Paravirtualization （たとえば、Xen）は、ハードウェアアーキテクチャを仮想ゲストに渡さず、リソースを使用するためのAPIを提供します。したがって、従来のオペレーティングシステム（およびハイパーバイザー）は、準仮想化システムでは実行できません。
仮想マシンでHyper-Vを実行することはできません。ハードウェア上で直接実行する必要があります。一部の仮想化システムではHyper-Vの役割をインストールできますが、VMを実行することはできません。ただし、Hyper-Vマネージャープログラムを実行できる場合があります。
ハイパーバイザーの種類によって異なります。他のハイパーバイザー内にデプロイできるハイパーバイザーがあります。落とし穴はたくさんあり、64ビットでのハードウェアサポートは良くありません。テスト以外にこれを行うことは決してないことを強調する必要があります。それでも、特定の機能（vMotionやVMware側のHAなど）のテストにのみ役立ちます。これは、ソフトウェアが実稼働環境でどれだけうまく機能するかを示すものではありません。
まず、x86特権レベル（リング）を理解する必要があります： http://en.wikipedia.org/wiki/Ring_（computer_security）
通常、オペレーティングシステム（ハードウェアへの特権アクセスを含む）はリング0で実行され、そのユーザーレベルのプログラム（OSを介してハードウェアの相互作用をプロキシする必要があります）はリング3で実行されます。プログラムがシステム呼び出しを行うと、リング0スペースで特定の関数を実行し、その結果をリング3プログラムに返すように求めるメッセージをオペレーティングシステムに渡します。
（Intel VT-xやAMD-Vなどのハードウェア支援なしで）ソフトウェアに仮想化を完全に実装する場合、基本的に行うことは、実行中のVM内のコードの特権レベルを検査することです。 VMwareでは、この手法はバイナリ変換と呼ばれます。リング3で実行されているコードは、変更されずにリング3で引き続き実行されます。リング0で実行されるものはすべて、代わりにリング1で実行され、ハイパーバイザーの仮想ハードウェアを介してリング0ハードウェアアクセスがプロキシされます。仮想ハードウェアは、ホストOSにリング0スペースで何かを実行するように指示するソフトウェアのセットです。
特定のハードウェアは、バイナリ変換を実現するために必要なリングレベルをサポートしていないため、バイナリ変換をサポートしていません。特に、リング1と2は、ほとんどの最新のx86プロセッサの64ビットモードには存在しません（一部のAMD CPUはサポートしていますが、Intelはサポートしていません）。したがって、バイナリ変換は通常、32ビットのゲストOSに制限されています。
バイナリ変換を使用するハイパーバイザーを使用している場合は、すでにリング1を使用しているため、別のハイパーバイザー内でBTハイパーバイザーを実行することはできません。 （さて、仮に誰かがリング2自体が仮想化されているときに、リング2を使用するハイパーバイザーを作成する可能性があります。これはEdgeのケースであり、誰もそれを行っていないと思います。）
Xenのような準仮想化ハイパーバイザーは、同様の前提の下で機能します。準仮想化ハイパーバイザーは、リング0で実行する代わりに、物理ハードウェアで実行されていないことを認識し、ハイパーバイザーと通信するための特別なメソッドを使用するようにコーディングされた、特別に変更されたゲストカーネルを使用します。準仮想化は、オペレーティングシステムですでに使用されているリングレベル内で完全に機能するため、ハイパーバイザー自体が直接ハードウェアアクセスを必要としない限り、任意にネストされたレベルの準仮想化ハイパーバイザーを実行できるはずです。深く進むには明らかに実際的な制限があり、前述のように、パフォーマンスは良くありません。
一方、ハードウェア拡張機能は、バイナリ変換とは逆の方法で機能します。つまり、超特権ハイパーバイザーレベル、つまりリング1（リング0の1レベル下にある）を提供し、すべてのリング0コードを変更せずに実行します。これらの命令セットが使用されている場合、リング-1は、実行中のコードを分析せずに、仮想マシンのリング0操作がハイパーバイザーによってキャッチおよび処理される環境を提供します。
ハードウェア拡張機能を使用して2つのハイパーバイザーを同時に実行しようとしている場合でも、それらを同時に実行することはできません。たとえば、ハードウェア仮想化サポートを使用して仮想マシンを実行するためにVirtualBoxを既に使用している場合、Windows7でWindows XPモードを実行することはできません。
これにより、ハードウェア仮想化を使用してハイパーバイザー内でバイナリ変換ハイパーバイザーを実行できますが、その逆はできません。さらに、ハイパーバイザーインハイパーバイザーは通常32ビットゲストしか実行できませんが、パフォーマンスへの影響は他のポスターが示唆しているほど大きくないことがよくあります。 （データベースサーバーなど、大量のメモリアクセスを必要とするアプリケーションは、2セットの仮想ページテーブルを経由する必要があるため、引き続き問題が発生します。）ほとんどのハイパーバイザーは、別のハイパーバイザー内で実行されていることを検出し、実行を拒否します。一部のハイパーバイザーは、テスト機能では問題なく機能します。たとえば、VMwareWorkstationで複数のVMwareESXiインスタンスを実行できます（ただし、BTモードはVMware WorkstationでホストされているESXi仮想マシンでのみ使用できます）。
Xenはバイナリ変換を実行しません。ハードウェア支援仮想化を使用するか、準仮想化を実行します。別のハイパーバイザーの下で準仮想化されたXenを実行することは可能ですが、この方法で完全なハードウェア仮想化を使用してXen-under-ESX仮想マシンを実行することはできません。
お役に立てれば。