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

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

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E2, M-V
- Verified: 2026-10-29

## 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

```powershell
# 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

```powershell
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 |

> **Caution: VBS and third-party hypervisors**
>
> Memory integrity (HVCI) and Credential Guard run on the Hyper-V hypervisor. With them on, some older third-party hypervisors and anti-cheat drivers behave differently. That is a compatibility trade-off, not a bug in your CPU.

## Verify a fix end to end

```powershell
# 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.

## Related

- [P/E cores and the scheduler](https://windows.homes/en/hardware/cpu/hybrid-cores/)
- [Windows VM on Proxmox](https://windows.homes/en/windows/dev/pve-windows-vm/)
- [Memory integrity measured](https://windows.homes/en/windows/gaming/memory-integrity/)

## 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.

## Sources

- [Microsoft Learn — Hyper-V host hardware requirements](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/host-hardware-requirements)
- [Microsoft Learn — Windows processor requirements](https://learn.microsoft.com/en-us/windows-hardware/design/minimum/windows-processor-requirements)
- [Microsoft Learn — WSL2 overview](https://learn.microsoft.com/en-us/windows/wsl/about)

---

Source: https://windows.homes/en/hardware/cpu/virtualization-flags/