VMware Workstation Does Not Support Nested Virtualization on This Host
If VMware ends with Module 'HV' power on failed, do not disable Hyper-V, VBS, Memory Integrity, or Credential Guard first. Start by deciding whether the guest actually needs nested virtualization. If it does, trace the full capability chain: host CPU → firmware exposure → Windows hypervisor/VBS state → VMware Workstation execution path/version → VM nested-exposure setting → inner workload. An active Microsoft hypervisor is evidence about the host path, not proof by itself that it caused this failure.
Module 'HV' power on failed.You may also see Virtualized Intel VT-x/EPT is not supported on this platform or the AMD-V/RVI equivalent.Power off the VM. In VMware processor settings, clear the option that exposes hardware-assisted virtualization to the guest. Do this only when software inside the guest does not need to run its own hypervisor.
Verify: Power on the VM. If it boots normally and the workload does not require nested virtualization, stop here—there is no reason to disable host security features.
If nested virtualization is required, diagnose the host first
Confirm the CPU capability and Intel VT-x/AMD-V (plus the nested workload's required second-level translation capability where applicable), then verify firmware has not disabled the feature.
Record the Workstation version and Windows hypervisor/VBS state. An active Microsoft hypervisor can change VMware's execution path; whether nesting works depends on the supported product/version/host combination, not on the status message alone.
If yes, preserve the option and investigate the host path. If no, use the quick fix.
Verify: You can state the required inner workload, host CPU/firmware capability, Workstation version, Windows hypervisor/VBS state, and whether the VM's nested-virtualization exposure is enabled before changing security settings.
Fix #2 — prove whether the current Workstation/Windows execution path supports the required nesting
Open msinfo32 or run systeminfo. If Windows reports A hypervisor has been detected, record that the Microsoft hypervisor is active—but do not stop there. Current Workstation can run through Windows' hypervisor interfaces for supported workloads, while nested virtualization support has additional product/version/host constraints. Correlate the exact Workstation version, Windows build, VBS state and VMware error/log evidence before attributing the failure to Hyper-V/VBS.
systeminfoIf you intentionally removed Hyper-V but the hypervisor remains active, continue with Hypervisor Still Detected After Disabling Hyper-V.
Verify: Re-test the exact VM after changing only the proven unsupported/blocking condition. The outer VM must power on with nested exposure still enabled, and the inner hypervisor/workload must actually detect and use the required virtualization capability. If the error changes, stop diagnosing Module HV and follow the new failure class.
Fix #3 — change host security only when the workload requires it
If vendor-supported evidence for the exact Workstation/Windows combination shows the required nested workload cannot run through the current Windows hypervisor/VBS execution path, decide whether changing that host state is acceptable. Record the original state and dependencies first. On managed devices, do not override organization-enforced VBS/Credential Guard/Device Guard policy locally; use the approved administrative path.
Verify: After the required reboot, confirm the intended host hypervisor state and test the nested workload—not just the outer VM power-on screen.
What not to do
A hypervisor has been detected as an error by itself.Do not split Intel VT-x/EPT and AMD-V/RVI variants into unrelated fixes.Do not copy registry, BCD or Device Guard changes from old forum posts without confirming current applicability.Do not judge success only by the outer VM booting if the nested workload still cannot use hardware virtualization.Do not treat an active Microsoft hypervisor as proof that it is the blocker; correlate the exact Workstation/Windows support path and VMware evidence.Do not assume firmware VT-x/AMD-V enabled means the entire nested capability chain is usable; CPU capability, execution path and guest exposure still matter.Do not override organization-managed VBS, Credential Guard or Device Guard policy merely to make nesting work.Do not keep applying Module HV fixes if the failure changes to a different concrete VMware or inner-hypervisor error.Still getting Module 'HV' power on failed?
systeminfo reports an active hypervisorVBS / Memory Integrity / Credential Guard statewhich nested workload requires virtualizationwhether non-nested VMs power on normallyrelevant vmware.log lineshost CPU model and required VT-x/EPT or AMD-V/RVI capability for the inner workloadthe exact Workstation execution/support context for the Windows build and hypervisor/VBS statewhether nested exposure remains enabled when reproducing the exact failurethe first different error if Module HV is cleared but the nested workload still failsReferences
Virtualization failure map
Use the exact failure stage to avoid applying a Hyper-V or VMware fix to the wrong problem.
Still stuck? Ask the community
Share the exact error, versions, whether nesting is required, and host hypervisor/VBS state.
Loading community discussion…