Skip to content
WSLHow-To Published Updated 8 min readViews unavailable

Nested Virtualization in WSL 2: Exposing CPU Extensions Without Guesswork

Configure WSL 2 nested virtualization, distinguish .wslconfig from Hyper-V host settings, and validate guest capability without assuming workload support.

Nested virtualization exposes processor virtualization extensions to a guest so that another hypervisor or virtualization workload can run inside it. In WSL 2, this capability involves more than one layer: the Windows host, the WSL utility virtual machine, and sometimes an outer Hyper-V virtual machine that contains Windows. A setting in .wslconfig cannot compensate for virtualization extensions that the outer hypervisor does not expose.

Microsoft’s WSL configuration reference documents nestedVirtualization under the [wsl2] section, lists it as enabled by default, and marks it as available only on Windows 11. The documented Intune policy can disable the user’s .wslconfig setting; Microsoft notes that this policy applies to Store-serviced WSL. Check the Windows build, WSL package version, actual file, and applicable policy rather than inferring the state from a tutorial written for another release.

Configure the WSL virtual machine

The setting is global to WSL 2, so it belongs in the Windows user’s %UserProfile%\.wslconfig, not a distribution’s /etc/wsl.conf:

[wsl2]
nestedVirtualization=true

If the file already has a [wsl2] section, add the key there instead of creating a duplicate section. Keep a backup of the prior file and avoid replacing unrelated CPU, memory, networking, kernel, or swap settings. After editing the global configuration, shut down the WSL virtual machine so the next WSL 2 launch reads the updated settings:

wsl.exe --shutdown
wsl.exe --status

wsl --status reports WSL-level information; it does not prove that a nested hypervisor successfully started. Test the specific workload you need from a Linux distribution and inspect its own diagnostics. The Linux-visible CPU flags are useful evidence that hardware virtualization extensions were exposed, but successful nested execution also depends on the guest kernel, drivers, and workload configuration.

Map the capability boundary before changing settings

Nested virtualization is a chain of capability handoffs, not a single switch. On a physical Windows host, firmware and the processor expose hardware virtualization to the Windows hypervisor, which then supplies the WSL 2 virtual machine. If Windows itself is a VM, an outer hypervisor must expose those extensions to the Windows guest before WSL can pass them farther inward. The inner workload may then use the exposed capability to start another VM or hypervisor-backed feature. A setting at one layer cannot enable a feature withheld by an earlier layer.

Boundary What to verify Typical owner
Physical machine CPU capability and firmware virtualization setting Hardware or endpoint administrator
Outer VM host, if present The Windows guest is permitted to use virtualization extensions Hypervisor or cloud administrator
Windows and WSL Virtual Machine Platform, supported Windows/WSL release, policy, and .wslconfig scope Windows or WSL administrator
Linux workload Guest-kernel support, runtime configuration, and a real nested-workload start Distribution or workload owner

Capture evidence at each boundary before changing the next one. On Linux, architecture and processor flags help establish what the guest can see:

uname -m
grep -m1 -E '^(flags|Features)[[:space:]]*:' /proc/cpuinfo

On x86, the relevant flag names commonly include vmx for Intel VT-x or svm for AMD virtualization. Other architectures report different feature names, so do not use an x86-only search as an ARM64 test. A visible flag is necessary evidence for some workloads, not a guarantee that a particular inner hypervisor or emulator is supported, that its kernel module can load, or that it can allocate enough CPU and memory. The workload’s own startup test remains the deciding check.

Keep resource limits in the same map. The WSL 2 VM’s processor and memory settings, the outer Windows VM’s allocation, and any limits applied to the inner workload constrain the same nested execution path. A Linux guest can see virtualization extensions and still fail to start a nested workload because it lacks memory, usable vCPUs, or a compatible kernel/runtime. Record those limits alongside the feature state instead of repeatedly toggling nestedVirtualization when the failure is actually resource exhaustion.

If Windows itself runs inside Hyper-V

When Windows is a Hyper-V guest, the physical Hyper-V host must expose virtualization extensions to that VM. Power off the Windows guest before changing this processor setting; Microsoft’s Hyper-V procedure requires the VM to be off. On the parent Hyper-V host, use:

Set-VMProcessor -VMName "Windows-Guest" -ExposeVirtualizationExtensions $true

This command runs on the Hyper-V host with the required administrative permissions. It is not a command to run inside WSL, and setting it changes the VM’s hardware exposure. Coordinate the change with the VM owner and follow the environment’s change-control process. Other hypervisors have their own nested-virtualization controls; a Hyper-V command does not configure them.

Some cloud VM configurations impose additional restrictions. Microsoft notes, for example, that WSL 2 nested virtualization is not supported in Azure virtual machines with Trusted Launch. Check the current platform-specific support matrix before treating a missing virtualization feature as a WSL defect.

Do not generalize a result from one host to every VM family, processor generation, or hypervisor. The parent platform may expose extensions only for specific hardware and VM sizes, and its own security or lifecycle policy may prevent changing that exposure. In a managed or hosted environment, ask the platform owner to confirm the supported nested-virtualization configuration before changing a guest setting. A Windows guest cannot override a host policy, and an administrator inside WSL cannot grant itself processor features that the virtual machine does not present.

Diagnose the layer that is blocking the feature

Use a layered test rather than repeating the same WSL command:

  1. On the physical host, verify CPU virtualization support and firmware settings.
  2. If Windows is virtualized, verify the parent hypervisor exposes virtualization extensions to the Windows guest.
  3. In Windows, verify the Virtual Machine Platform feature and the installed WSL package/runtime are available.
  4. In %UserProfile%\.wslconfig, confirm the [wsl2] value and check for policy that disables user configuration.
  5. Restart the WSL virtual machine and test the actual Linux workload, recording its error and kernel diagnostics.

Interpret each observation narrowly. If WSL itself cannot start and Windows reports that a required virtualization feature is unavailable, investigate the Windows feature and host exposure first. If WSL launches normally but the inner workload reports that virtualization extensions or its accelerator are unavailable, compare the guest-visible CPU features with the workload’s documented prerequisites. If those features are present but the workload still fails, inspect its own kernel modules, runtime version, resource limits, and logs. If only networking fails after an inner VM starts, diagnose its virtual switch, NAT, or forwarding path separately; changing CPU-extension exposure will not repair a network route.

Use wsl --status and /proc/cpuinfo as inventory, not as pass/fail acceptance tests. Save the exact inner-workload command and its unedited error output, plus the Windows build, WSL version, distro kernel, outer VM type, and effective configuration. For managed Windows, check whether an Intune or Group Policy setting prevents a user override. The effective result may differ from the text in .wslconfig when policy or a different WSL servicing path is involved.

Keep WSL’s global configuration distinct from distribution-specific wsl.conf. The global file configures the WSL 2 utility VM; the distribution file configures per-distro behavior such as automounting, interop, or systemd integration. Placing nestedVirtualization in the wrong file can make an otherwise valid setting appear ineffective.

Acceptance criteria and rollback

Define success in terms of the intended operation: for example, a particular nested VM starts and completes a small test workload without virtualization-extension errors. A present vmx or svm flag alone is not a pass. Capture WSL, Windows, kernel, and outer-hypervisor versions and retain the exact configuration used.

Make the test repeatable and low impact. Use a disposable nested guest or the smallest representative workload, avoid changing multiple hypervisor and WSL settings in one trial, and record whether the test is cold-started or resumed. Verify both launch and one useful operation inside the nested environment; a VM window appearing does not prove that storage, networking, or the target application works. Measure only the resource or latency characteristic relevant to the decision, and compare it with the same test before the configuration change.

Also test the failure and rollback path. Confirm that the ordinary WSL distro still starts after the setting is changed, that the previous .wslconfig can be restored, and that any outer VM setting can be reverted by its owner. Changing processor exposure for a Windows VM is a host-level action with an outage requirement, not a harmless Linux tuning command. Schedule it with the VM owner, power the guest off as the Hyper-V procedure requires, and verify the original state if the nested workload is not needed.

If the workload fails, disable the WSL setting only as a controlled comparison, shut down WSL, and rerun the same test. Restore the previous .wslconfig if the change caused regressions. Do not enable unrelated privileged features or change distribution kernel settings until the failure has been localized to that layer.

Nested virtualization in WSL 2 is a capability exposed across several virtualization boundaries. The reliable fix is to verify each boundary independently and test the target workload, not to assume a single configuration flag guarantees support everywhere.

Related:

Sources:

Comments