Nested VM: Enable Virtualization Inside Guest on Hyper-V

Quick answer

Run Set-VMProcessor -VMName "YourVM" -ExposeVirtualizationExtensions $true as admin on the Hyper-V host, then reboot the guest VM.

What's actually happening here

You installed Hyper-V on Windows Server (or Windows 10/11 Pro). Inside one of your VMs, you try to run Docker Desktop with WSL2, or maybe you're testing a nested ESXi or KVM hypervisor. The guest OS sees no CPU virtualization support. Task Manager shows "Virtualization: Disabled".

The reason: Hyper-V's default security posture hides the hardware VT-x/AMD-V extensions from guest VMs. Microsoft assumes you don't need nested VMs and doesn't expose the VMX flag. Without that flag, the guest can't start its own hypervisor.

This isn't a hardware problem — your CPU supports virtualization just fine. It's a Hyper-V configuration toggle that requires an explicit opt-in.

Prerequisites

Hyper-V host running Windows Server 2016/2019/2022 or Windows 10/11 Pro/Enterprise.
The guest VM must be a Hyper-V Generation 2 VM (Gen 1 also works but with more limitations).
CPU on the host must support VT-x/AMD-V and SLAT (EPT/NPT).
The guest VM must be stopped before changing processor settings.

Step-by-step fix

Open PowerShell as Administrator on the Hyper-V host. Not on the guest — this command runs on the physical host.

List your VMs to confirm the name:

Get-VM | Select-Object Name, State, Generation

Enable nested virtualization — replace YourVM with your actual VM name:
```
Set-VMProcessor -VMName "YourVM" -ExposeVirtualizationExtensions $true
```
That's the only command you need. It exposes the VMX (Intel) or SVM (AMD) CPU flag to the guest.
Start the VM and log in. Open Task Manager → Performance tab. You should see "Virtualization: Enabled".
Inside the guest, if you're using Hyper-V within the guest, run this inside the guest PowerShell (as admin) after a reboot:
```
Set-VMProcessor -VMName "InnerVM" -ExposeVirtualizationExtensions $true
```
Nested nesting — yes, you can go three levels deep. Works on Windows Server 2022.

When the main fix doesn't work

Guest OS is Linux and doesn't see virt extensions

Run cat /proc/cpuinfo | grep vmx or lscpu | grep Virtualization. If you still see nothing, the host Hyper-V might be running in a VM itself (nested nesting scenario). Go back to the host and verify the ExposeVirtualizationExtensions property:

Get-VMProcessor -VMName "YourVM" | fl ExposeVirtualizationExtensions

It should return True.

Docker Desktop still says WSL2 needs virtualization

Docker Desktop with WSL2 needs the Hyper-V role enabled inside the guest too. Inside the guest (Windows 10/11):

dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V /all /quiet

Then reboot the guest twice. Yes, twice — the first reboot enables features, the second gets the Hyper-V hypervisor loaded.

VMware ESXi inside Hyper-V shows "CPU does not support long mode"

That's a different problem: VMware Workstation doesn't like running inside Hyper-V at all. The fix here is to switch the guest to a Type 1 hypervisor (like a nested ESXi) and disable Hyper-V on the host if you're using VMware Workstation. Or use Hyper-V for the inner VM instead of VMware.

Alternative: Enable via Hyper-V Manager GUI

You can skip PowerShell if you prefer clicks:

Open Hyper-V Manager.
Right-click your VM → Settings → Processor.
Under "Compatibility", check the box "Enable nested virtualization".
Click OK.

But honestly, the PowerShell command is faster. The GUI option doesn't exist in all Windows 10 builds (it was added in later updates).

Prevention tip for next time

If you plan to run nested VMs regularly, create a PowerShell profile script that runs on boot and sets this property for specific VMs. Or write a simple one-liner in a scheduled task:

Get-VM | Where-Object {$_.Name -like "*nested*"} | Set-VMProcessor -ExposeVirtualizationExtensions $true

That way any VM with "nested" in its name automatically gets the flag enabled after the host reboots. Saves you the manual step every time.

What not to try

Don't fiddle with BIOS settings on the host — if the host itself shows virtualization enabled in Task Manager, your hardware is fine.
Don't manually edit Hyper-V config XML files — one typo and the VM won't start.
Don't install Hyper-V inside a Hyper-V guest without first enabling nested virtualization at the host level — it will fail silently.

Final note: nested VMs run slower — expect about 80-90% of native performance. For production workloads, use physical hardware. For dev/test environments, it's perfectly fine.