Fix Hyper-V Nested Virtualization 'Unsupported CPU' Error

You're not alone — and it's not your CPU's fault

Getting that 0x80370102 error when trying to start a Hyper-V VM inside another VM is maddening. You checked your BIOS, saw VT-x is on, and still nothing. What's actually happening here is that the outer hypervisor isn't exposing all the CPU features the inner Hyper-V needs. The host CPU has them, but the VM doesn't see them.

The fix: expose CPU virtualization flags to the guest

You need to tell the host hypervisor to pass through the Intel VT-x or AMD-V extensions to the inner VM. Here's how for each common host type.

If your host is VMware Workstation or Fusion

1. Shut down the nested VM completely.
2. Edit the VM's .vmx file (right-click VM > Settings > Options > Advanced > Configuration Parameters).
3. Add or set these lines:

   hypervisor.cpuid.v0 = FALSE
   vhv.enable = TRUE

4. Save the file and start the VM.

The reason hypervisor.cpuid.v0 = FALSE works is that it stops VMware from hiding the fact that the VM is virtualized. By default, VMware masks the hypervisor CPUID bit to avoid confusing some old guest OSes. Nested Hyper-V needs to see that bit to detect it can run nested itself. vhv.enable = TRUE tells VMware to allow hardware virtualization instructions (VMX/SVM) to pass through to the guest.

If your host is VirtualBox

1. Shut down the nested VM.
2. Enable Nested VT-x/AMD-V in the VM's System > Processor settings.
3. Also check Enable VT-x/AMD-V in System > Acceleration.
4. Start the VM.

VirtualBox's nested VT-x option is newer and less polished than VMware's. If it still fails, try increasing the guest's CPU count to at least 2 cores — Hyper-V refuses to launch with a single-core VM under nested virtualization. This is a documented Hyper-V quirk.

If your host is Hyper-V (nested inside Hyper-V)

Run this PowerShell command on the host Hyper-V (the outer one):

Set-VMProcessor -VMName "YourVMName" -ExposeVirtualizationExtensions $true

Hyper-V exposes nested virtualization by default on Windows Server 2016+ and Windows 10 version 1803+. But if someone disabled it, this command re-enables it. You'll need to restart the VM afterward.

Why this error happens at all

Hyper-V is picky. It checks for the VMX (or SVM on AMD) CPU flag in the guest. If it doesn't see it, it throws 0x80370102 and quits. The host hypervisor — VMware, VirtualBox, or Hyper-V — can hide these flags for compatibility reasons or security concerns. The fix exposes them.

One thing most guides skip: even after enabling nested virtualization, the inner Hyper-V can't use certain features like SR-IOV or live migration. That's a hardware limitation of the pass-through, not a bug. If you need those, you're out of luck with nested setups.

Less common variations of the same issue

Old VMware version

VMware Workstation 14 and earlier don't support nested virtualization at all. vhv.enable = TRUE doesn't exist in those versions. You need Workstation 15+ or Fusion 11+. If you see the error with an old VMware, there's no workaround — upgrade.

Windows Sandbox or WSL2 interference

If you're running Windows Sandbox or WSL2 on the host, they can consume the VT-x resource and prevent other VMs from using nested virtualization. The fix: disable them temporarily. Run dism /online /disable-feature /featurename:VirtualMachinePlatform from an admin prompt, reboot, then try your nested VM. Re-enable later if you need them.

BIOS-level VT-x is actually off, but you think it's on

Some motherboards have separate settings for Intel Virtualization Technology and VT-d. You need both on for nested Hyper-V to work reliably. Check your BIOS again — look for both settings. On Dell Optiplex 7080, for example, VT-d is hidden under System Configuration > Virtualization Support, separate from the main VT-x toggle.

Prevention: set up your host right from the start

Before you even create a nested VM, verify the host supports nested virtualization. Run this in PowerShell on the host:

Get-VMHost | Select-Object -Property NestedVirtualizationSupported

If it returns True, you're good. If False, check CPU model — requires Intel Haswell (2013) or newer, or AMD Ryzen or EPYC. No firmware update will help older chips.

After that, always enable the nested flag before starting the VM for the first time. For Hyper-V hosts, run Set-VMProcessor right after VM creation. For VMware, add the .vmx lines before the first boot. Once the inner Hyper-V starts, it writes its own configuration expecting those flags to be present. Adding them later can work, but you might need a full shutdown and restart of the inner VM — not just a reboot.

One more thing: if you're using Windows 10 Home, Hyper-V isn't available inside the VM either — you need Pro or Enterprise. That's a licensing check, not a hardware problem. Don't waste time chasing CPU flags if you're on Home.

That's it. The fix is almost always one of the three methods above. If none work, post the exact host hypervisor version and CPU model — I'll help you trace it.