ネストされた仮想化のサポートを使用して、ウィンドウルートOS内で別のHyper-Vではないハイパーバイザーを実行する
ハイパーバイザーがどのように機能するかをよりよく理解しようとしています。 CPUからの仮想化サポートを使用できるハイパーバイザーは一度に1つだけです。また、Hyper-Vはタイプ1ハイパーバイザーであるため、有効にすると、Windowsよりも先に「起動」し、ハードウェアへの特権アクセスを使用して特別なVM）としてWindowを実行します。
Hyper-Vは、仮想化拡張機能をゲストに（何らかの方法で）公開することで ネストされたvirtualizzation をサポートしますが、ゲストがHyper-Vを使用している場合にのみ機能します。この制限の理由について疑問に思っていましたが、別のハイパーバイザー（VirtualBoxなど）が公開された仮想化拡張機能を使用できないのはなぜですか？
この質問 は私のものと非常に似ていますが、満足のいく答えはありません。
編集：私がそれを行うことができないと信じる理由（したがって私は理由を尋ねています）は次のとおりです：
これは、Microsoftの公式ページに書かれています。
Hyper-V以外の仮想化アプリケーションは、Hyper-V仮想マシンではサポートされておらず、失敗する可能性があります。これには、ハードウェア仮想化拡張機能を必要とするすべてのソフトウェアが含まれます。
仮想化拡張機能を公開するコマンドでは、Hyper-VVMを指定する必要があります。Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
EDIT2：申し訳ありませんが、理解が不足しているため、この質問を十分に明確に表現することができませんでした。もっと明確にしようと思います。これが私がやりたいことです：
Microsoftページの引用：
Hyper-Vは、ハードウェア仮想化拡張機能を仮想マシンに公開します。ネストを有効にすると、ゲスト仮想マシンは独自のハイパーバイザーをインストールして、独自のゲストVMを実行できます。
これに加えて、Windows Root OS自体が特別なVMであるため、公開できるはずだと信じさせられましたVirtualization Extensions =メインへWindowsルートOSそしてそれらを使用してその内部で別のハイパーバイザーを実行します。
それを行う方法を検索しているときに、私はこのコマンドに出くわしました：
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
VMNameが必要です。
- 私が今理解しているのは、Hyper-Vでは仮想化拡張機能をそのVM）のいずれかに公開できますが、Windowsを選択することはできません。ルートOS（なぜですか？）選択したVM内では、Virt。Ext。を別のHyper-Vインスタンスで公式に使用できますが、他のハイパーバイザーでも機能する可能性があります。
- 私が最初にこの質問をしたとき、WindowsルートOSで開くことができるHyper-V管理ツールが同じレベルのゼロHyper-Vで動作することに気づきませんでした。 Windows Root OS自体を実行します。別のHyper-Vインスタンスで動作すると思いましたが、これに加えてHyper-V VMの名前を必要とするコマンドを使用すると、2つのHyper-Vハイパーバイザーでしか実行できないと思いました。
要約すると、私の質問は実際には2つの部分からなる質問でした。
- Hyper-Vを搭載したVM内にHyper-V以外のハイパーバイザーをネストできますか？そして答えは次のとおりです：明示的にサポートされていませんが、サポートする必要があります。仕事（受け入れられた答えを参照）。
仮想化拡張機能をWindowsルートOSに公開できないのはなぜですか？そして答えは：
[@harrymc]仮想化拡張機能はCPUの一部であり、すべてのハードウェアは常にそのOSにパススルーされ、何も仮想化されないため、ルートOSには常に表示されます。 Set-VMProcessorは、実際にはVMではないため適用されません。または、特別で些細な種類のセミVMであると言えます。
[私]それで、ルートOSはすでにvirt.extを見ることができます。 「直接」（ハードウェアの残りすべてを見ることができるため）が、Hyper-Vですでに使用されているため、VirtualBoxに使用することはできません。 「通常の」Hyper-V VM virt.ext。を有効にして）を作成すると、その内部で別のハイパーバイザーを実行できるはずです。
[@harrymc]そうです、それがその仕組みです。
ネストされた仮想化 インテルVT-xまたはAMD-V CPU拡張機能を通過することを意味するだけなので、同じハイパーバイザーを実行する必要はありません。可能ではありますが、関係する企業によって公式にサポートされていないため、異なるハイパーバイザーのネストが簡単であるとは限りません。
ハイパーバイザーが異なると、ハードウェアサポートの問題が発生します。これは、ハイパーバイザーごとに、サポートされていないか、他のハイパーバイザーまたはターゲットVMにドライバーがある可能性のある異なる仮想デバイスが作成されるためです。
たとえば、Hyper-Vは、Hyper-V仮想ネットワークスイッチに関連付けられた仮想ネットワークアダプターとして、ネットワークアダプターを仮想マシンに公開します。つまり、サーバーに物理的にインストールされているネットワークアダプターの種類に関係なく、ネストされたハイパーバイザーには、VMwareがサポートしていない可能性のあるMicrosoftHyper-VネットワークアダプターまたはMicrosoftレガシーネットワークアダプターのいずれかのドライバーが必要になります。適切なドライバーが存在する場合でも、デバイスエミュレーションを複数のエミュレーションレイヤーに渡して、複数のデバイスが相互にマスカレードしているため、パフォーマンスが向上することはありません。
これらのエミュレーションとパフォーマンスの問題に対する1つの解決策は、ハードウェアのパススルーを意味する個別のデバイス割り当てを使用することです。個別のデバイス割り当てがWindowsServer 2016で導入されたため、たとえば、ネストされた仮想化の場合、PCIeベースのネットワークアダプターを、仮想化ハイパーバイザーを実行しているVMに直接マップできます。これにより、仮想デバイスドライバーが必要であり、デバイスメーカーのデバイスドライバーをゲスト仮想マシン内に通常どおりインストールできるようにします。
個別のデバイス割り当てはいくつかの問題を解決しますが、新しい問題と制限も生み出します。たとえば、Hyper-Vでは、そのようなデバイスが割り当てられている仮想マシンは、保存/復元、ライブマイグレーション、または動的メモリの使用をサポートしていない可能性があり、フェールオーバークラスターに追加することもできません。 （この分野はまだ進化しているため、これらの制限は将来なくなる可能性があります。）
一部のマルチベンダーのネストされたハイパーバイザー環境では、ネストされたハイパーバイザー内で実行されている仮想マシンに対してネストを有効にする必要があるという報告もあります。ネストされたハイパーバイザーは問題なく実行されますが、ハイパーバイザーがVMレベルでインストールされるまで、仮想マシンは起動に失敗します。
上記の考慮事項、および私がリストしていない他の考慮事項のために、競合するハイパーバイザーを連携させることは簡単なプロセスではありません。ネストされたハイパーバイザーをインストールした後でも、仮想マシンを信頼性の高いパフォーマンスの高い方法で実行するには、試行錯誤が必要になる可能性があります。
最後に、異なるハイパーバイザーをネストできるという私の主張を裏付けるために、これを行うための手順が記載された記事をいくつか示します（ただし、これらのハイパーバイザーはテストしていません）。