Virtualisation flags: checking VT-x, IOMMU, SLAT and nested support

Verified 2026-10-292 min read

Verify what your firmware and CPU actually expose for Hyper-V, WSL2, VBS and nested virtualisation — with the checks that fail silently.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: E1 + one lab observation
Evidence: E2Reproduced in the lab, measured in a passthrough VM
Verified: 2026-10-29
Page type: Task

The short answer

Four different things get called “virtualisation”, and each fails differently:

Feature	Needed by	Where it is enabled
VT-x / AMD-V (CPU)	Hyper-V, WSL2, VBS, VMware	Firmware setup
SLAT (EPT/NPT)	Hyper-V	Hardware; not a switch
IOMMU (VT-d/AMD-Vi)	device passthrough, DMA protection	Firmware setup
Nested	VM inside a VM	Hypervisor, plus CPU exposure

Enabling the Windows feature without the firmware switch gives you an error that does not say “firmware”.

Check what the OS sees

# firmware-level virtualisation exposed?
Get-CimInstance Win32_Processor | Select-Object Name,VirtualizationFirmwareEnabled,VMMonitorModeExtensions

# Hyper-V capability report (needs elevation)
systeminfo | Select-String 'Hyper-V'

# VM monitor extension mode + SLAT via a full check
Get-ComputerInfo -Property HyperVRequirement* | Format-List

VirtualizationFirmwareEnabled : False on a CPU that supports it means the firmware switch is off — the single most common cause of “Hyper-V won’t start”.

Check the Windows features

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All |
  Select-Object FeatureName,State
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform |
  Select-Object FeatureName,State
Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform |
  Select-Object FeatureName,State

VirtualMachinePlatform is what WSL2 needs.
HypervisorPlatform is what third-party hypervisors use.
Hyper-V and third-party hypervisors compete for the same CPU features; running both can force the slower API path.

What the guest sees depends on the host

For nested virtualisation, the guest only gets what the host chooses to expose. In Proxmox, the CPU model matters:

qemu64 (the generic default) does not expose the VMX/SVM feature.
--cpu host passes the host CPU features through, including the nested virtualisation flag.

Lab observation (E2, M-V): in this site’s PVE lab (VM 361, Windows 11 26H2), enabling WSL2 with the default qemu64 CPU model failed with HCS_E_HYPERV_NOT_INSTALLED. Switching the VM to --cpu host and rebooting made WSL2 start normally. The related lab record also notes that running wsl as SYSTEM fails with WSL_E_LOCAL_SYSTEM_NOT_SUPPORTED — run it as an interactive user.

That is one observation on one host, not a general rule about all hypervisors; it does show the failure mode you will meet.

IOMMU and passthrough

Device passthrough needs the IOMMU enabled in firmware and in the hypervisor, and the device to be in its own IOMMU group.

On consumer boards the setting is often called VT-d, AMD-Vi or IOMMU.
Enabling it can change device enumeration; re-check NIC names after.
Passthrough of a GPU to a Windows guest has its own requirements (IOMMU group, vBIOS, driver support) and is covered separately in the graphics section.

Failure modes that look like something else

Symptom	Real cause
`HCS_E_HYPERV_NOT_INSTALLED`	firmware virtualisation off, or nested not exposed
WSL2 starts but is very slow	competing hypervisor, or VBS enabled
Hyper-V installs but VMs won’t start	SLAT missing (very old CPU) or firmware setting
VM inside VM crashes at boot	CPU model without nested flag
Device passthrough fails	IOMMU off, or device shares an IOMMU group

Verify a fix end to end

# after changing firmware and rebooting
Get-CimInstance Win32_Processor | Select-Object VirtualizationFirmwareEnabled
Get-ComputerInfo -Property HyperVRequirementVirtualizationFirmwareEnabled,HyperVRequirementSecondLevelAddressTranslation
wsl --status

Do not stop at “the feature installed”. Start the actual workload (a WSL distro, a Hyper-V VM) and confirm it runs — installation success is not the same as a working hypervisor.

Lab boundary

E2 for the nested-virtualisation observation above (single PVE host, VM 361); E1 for the feature and requirement semantics. No bare-metal firmware matrix was tested.