Windowsで入れ子の仮想化を有効にできないときは、コマンドの打ち方よりも、前提条件のどこかが外れているケースがほとんどです。先に結論を言うと、物理ホストが Hyper-V を使える Windows エディションか、CPU/UEFI 要件を満たしているか、外側の VM が Generation 2 かつ必要な構成バージョンか、VM を OFF 状態で設定しているかを順番に確認すると、かなりの確率で原因を絞れます。特に Intel では VM 構成バージョン 8.0 以上、AMD では Windows 11 / Windows Server 2022 以降かつ 9.3 以上が条件になるため、ここが外れていると設定を触っても通りません。
この記事では、Windowsで入れ子の仮想化を有効にできないときに、どこから確認すればよいかを実務向けに整理します。Hyper-V を外側の VM の中で使いたいケースはもちろん、実は VMware や VirtualBox を動かしたかっただけで構成がかみ合っていないケース、設定を元へ戻す手順までまとめます。
ここでは、物理ホスト上で動かす Hyper-V VM を「外側のVM」、その中でさらに作る VM を「内側のVM」と呼びます。
最初に切り分けるべき5項目
- Windows エディション：物理ホストが Windows 10 / 11 Home なら、Hyper-V ロール自体を入れられません。Hyper-V ホストにできるのは、クライアント Windows では Pro または Enterprise です。
- 物理 CPU と UEFI：SLAT、VM Monitor Mode Extension、最低 4GB のメモリ、BIOS/UEFI で有効な Intel VT / AMD-V と DEP が必要です。
systeminfo.exeの Hyper-V 要件欄で、まず土台を判定できます。 - 外側の VM の条件：入れ子の仮想化は Generation 2 の VM が前提です。Intel 系なら VM 構成バージョン 8.0 以上、AMD 系なら Windows 11 / Windows Server 2022 以降かつ VM 構成バージョン 9.3 以上が必要です。
- 設定の入れ方：外側の VM は OFF 状態で
Set-VMProcessor -ExposeVirtualizationExtensions $trueを実行します。切り分け段階では 2 vCPU 以上、4GB 以上を割り当てておくと判断しやすくなります。 - 本当に動かしたいもの：Hyper-V や WSL2 を外側の VM の中で使うのはサポート範囲ですが、Hyper-V VM の中で VMware や VirtualBox など非 Microsoft の仮想化アプリを動かす構成は Microsoft のサポート外です。また物理 Windows で Hyper-V ハイパーバイザーが動作中だと、VMware / VirtualBox 側で VT-x / AMD-V を使えず、起動失敗や低速化につながることがあります。
起きやすい原因と対処
物理ホストの要件を満たしていない
いちばん多いのは、外側の VM ではなく、その土台になる物理 Windows 側が条件を満たしていないケースです。特に見落としやすいのが、Windows Home のまま進めていること、BIOS/UEFI で Intel VT / AMD-V が無効なこと、SLAT や DEP 条件を満たしていないことです。systeminfo.exe で Hyper-V 要件欄を見て、1項目でも No があるなら、先に物理ホスト側を直してください。
systeminfo.exe物理ホストで VMware や VirtualBox を使うつもりなら、msinfo32 でハイパーバイザー検出の表示が出ていないかも確認したいところです。表示があるなら、Hyper-V やそれに依存するセキュリティ機能が先に仮想化拡張を握っている可能性があります。実務では「どの設定を入れるか」より、「いま VT-x / AMD-V を誰が使っているか」を見るほうが早いです。
外側のVMの世代や構成バージョンが合っていない
入れ子の仮想化は Generation 2 の VM が前提です。さらに、古いホストから移行した VM やインポートした VM は、ホスト OS を新しくしても VM 構成バージョンが古いまま残ることがあります。この状態だと新しい Hyper-V 機能が使えず、設定自体は正しくても有効化で詰まりやすくなります。Generation 1 の VM なら条件を満たしていないので、設定を触り続けるより Generation 2 で作り直したほうが早い場面もあります。
外側の VM の構成バージョンは、次のコマンドで確認できます。
Get-VM * | Format-Table Name, Version
Get-VMHostSupportedVersion構成バージョンが足りないなら、互換性への影響を理解したうえで更新します。VM 構成バージョンを更新すると新機能が使えるようになりますが、あとからダウングレードはできません。古いホストへ戻す可能性があるなら、更新前にエクスポートやバックアップを取ってから進めるのが安全です。
Update-VMVersion <VMName>外側の VM の中で Hyper-V を動かす OS も、対応しているものを選ぶ必要があります。Microsoft のトラブルシューティング ガイドでは、Windows Server 2016 以降、Windows 10 / 11 以降、または Hyper-V をサポートする一部 Linux を前提にしています。古いイメージを流用している場合は、OS 世代も疑ってください。
設定する場所・タイミング・権限が違う
入れ子の仮想化は、外側の VM を OFF 状態 にしてから、物理 Hyper-V ホスト上で設定します。起動したまま設定したり、ゲスト OS の中から設定しようとすると、うまくいきません。PowerShell も管理者権限で実行する必要があります。
Set-VMProcessor -VMName "<VMName>" -ExposeVirtualizationExtensions $trueそのあと外側の VM を起動し、ゲスト OS 側で Hyper-V を有効にします。Windows クライアントなら、管理者権限の PowerShell で次のコマンドを使うのが早いです。切り分け中は外側の VM に 2 vCPU 以上、4GB 以上を割り当てておくと、単なるリソース不足と設定ミスを分けやすくなります。
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -Allそれでも通らない場合は、ホストとゲストの更新不足も疑います。Microsoft は、ホストとゲストを最新状態にし、ドライバーや Integration Services を更新すること、さらに Credential Guard や Device Guard、競合するグループポリシー、セキュリティ製品の影響も確認することを案内しています。
そもそも構成がサポート外のことがある
ここは見落としやすいポイントです。Hyper-V VM の中で Hyper-V を動かす構成はサポート対象で、WSL2 を Hyper-V VM の中で使う構成もサポートされています。一方で、Hyper-V VM の中で VMware や VirtualBox などの非 Microsoft 仮想化アプリを動かす構成は Microsoft のサポート外です。逆に、非 Microsoft 仮想化基盤の上で Hyper-V を入れ子にする構成もサポート外です。設定をいくら見直しても安定しないときは、設定不備ではなく構成選定が原因のことがあります。
最短で直す確認手順
- 物理ホストが Windows 10 / 11 Pro または Enterprise、または対応する Windows Server であることを確認し、
systeminfo.exeで Hyper-V 要件を確認します。Home なら、まずここで方向転換が必要です。 - Hyper-V マネージャーで外側の VM が Generation 2 か確認し、PowerShell で構成バージョンを確認します。古いホストから持ってきた VM なら、構成バージョン不足を最優先で疑います。
- 外側の VM を停止し、物理ホストで
Set-VMProcessor -ExposeVirtualizationExtensions $trueを実行します。外側の VM は 2 vCPU 以上、4GB 以上で切り分けるのが無難です。 - 外側の VM を起動し、管理者権限で Hyper-V を有効にします。ホストとゲストは Windows Update を反映した状態で試します。
- まだ失敗するなら、Credential Guard / Device Guard、グループポリシー、セキュリティソフト、あるいは「そもそも VMware / VirtualBox を Hyper-V VM 内で使おうとしていないか」を確認します。
有効化後にハマりやすいポイント
内側のVMのネットワークがつながらない
入れ子の仮想化では、ネットワークで止まることもよくあります。Microsoft は、外側の VM のネットワーク アダプターで MAC アドレス スプーフィングを有効にする方法と、NAT を使う方法の2つを案内しています。オンプレミスなら MAC アドレス スプーフィングが手早く、クラウドのように制約が強い環境では NAT が現実的です。
Get-VMNetworkAdapter -VMName "<VMName>" | Set-VMNetworkAdapter -MacAddressSpoofing Onメモリ変更がうまく反映されない
外側の VM の中で Hyper-V を動かし始めた後は、外側の VM のメモリ変更を停止状態で行う必要があります。動的メモリを有効にしていても、通常どおりに増減しない点は見落としやすいところです。設定後に不安定になったら、起動中に調整するのではなく、いったん停止してから見直したほうが安全です。
元に戻す手順と回避策
入れ子の仮想化をいったん外したい場合は、外側の VM を停止してから ExposeVirtualizationExtensions を無効にします。設定だけ切り戻したいなら、これが最短です。
Set-VMProcessor -VMName "<VMName>" -ExposeVirtualizationExtensions $false物理ホストで VMware や VirtualBox を使いたいなら、Hyper-V ハイパーバイザーを無効にする判断も必要です。Microsoft は、Windows の機能から Hyper-V Hypervisor を外す方法や、PowerShell で無効化する方法を案内しています。競合が続く場合は、Device Guard / Credential Guard の影響も疑ってください。
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor注意したいのは、VM 構成バージョンを更新したあとはダウングレードできないことです。古い Hyper-V ホストへ戻す必要があるなら、更新後に悩むより、更新前のバックアップやエクスポートから戻すほうが確実です。
迷ったらこの順番で進める
Windowsで入れ子の仮想化を有効にできないときは、systeminfo.exe で物理ホストを確認する → 外側の VM が Generation 2 かつ必要な構成バージョンか確認する → VM を OFF にして Set-VMProcessor を実行する → ゲスト OS 側で Hyper-V を有効にする → それでもだめならサポート対象の構成か見直す、この順番が最短です。無駄に設定を触り回すより、まずは物理ホスト、次に VM 構成、最後にサポート範囲の順で切り分けてください。
コメント