Running on a Virtual Machine — WSL2 Nested Virtualization

Quick Reference by Platform

Platform	Nested Virt Support	Key Setting	Requires Full Stop/Start
Proxmox / KVM	✓ Supported	qm set -args with Hyper-V flags + +vmx	Yes
QEMU (manual)	✓ Supported	-cpu host or +vmx/+svm	Yes
VMware ESXi	✓ Supported	Expose VMX to guest	Yes
VMware Workstation	✓ Supported	Virtualize Intel VT-x/EPT	Yes
Hyper-V	✓ Supported	ExposeVirtualizationExtensions	Yes
VirtualBox	⚠ Partial	Enable Nested VT-x/AMD-V	Yes
AWS EC2	✓ Supported	Use .metal instance	N/A
Azure	✓ Supported	Use Dv3/Ev3+ instance	N/A

---

1. QEMU / Proxmox (KVM)

This is the most common cause of WSL2 failures in industrial and server environments. The problem is three-layered — all three conditions must be met simultaneously:

1. The physical Proxmox host must expose CPU virtualization extensions (VMX/SVM) to the Windows VM.
2. The Windows VM must have a full set of Hyper-V enlightenment flags — without them, newer WSL versions fail to start the nested VM.
3. The WSL version inside Windows must be compatible — some newer versions have a nested-virt regression.

Step A — Enable Nested Virtualization on the Physical Host

Run on the physical Proxmox host (SSH or console, not inside the Windows VM):

Intel CPU:

cat /sys/module/kvm_intel/parameters/nested
# Must return Y. If it returns N:
echo 'options kvm-intel nested=1' >> /etc/modprobe.d/kvm-intel.conf
modprobe -r kvm_intel && modprobe kvm_intel

AMD CPU:

cat /sys/module/kvm_amd/parameters/nested
# Must return Y. If it returns N:
echo 'options kvm-amd nested=1' >> /etc/modprobe.d/kvm-amd.conf
modprobe -r kvm_amd && modprobe kvm_amd

If modprobe -r fails because a running VM holds the module, a full reboot of the physical host is required.

Step B — Set VM CPU Flags (critical step)

This is the most important step. Configure the VM so that Windows receives both VMX and the full set of Hyper-V enlightenment flags. Run on the Proxmox host (replace <VMID> with your VM number):

qm set <VMID> -args "-cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_synic,hv_stimer,hv_stimer_direct,hv_frequencies,hv_reenlightenment,hv_vpindex,+vmx"

The flags hv_stimer_direct, hv_frequencies, and hv_reenlightenment go beyond the Proxmox defaults. Together with +vmx, these are what allow nested WSL2 to start even on newer WSL versions.

Alternatively (simpler syntax, but only works reliably with older WSL versions):

qm set <VMID> --cpu host,flags=+nested-virt

After applying the flags, perform a full stop/start of the VM — not a reboot from inside Windows:

qm stop <VMID>
qm start <VMID>

A reboot from Windows (qm reboot or Start → Restart) does not recreate the QEMU process. The CPU flags only take effect when QEMU fully restarts via qm stop + qm start.

Step C — Verify Inside the Windows VM

After the VM starts, open PowerShell and verify that nested Hyper-V is available:

systeminfo | findstr /i "hyper-v"
bcdedit /enum | findstr -i hypervisor

hypervisorlaunchtype must be Auto. If it is missing or shows Off:

bcdedit /set hypervisorlaunchtype auto
# Then restart Windows

Test that WSL2 itself can start a nested VM:

wsl --install Ubuntu

If this completes without a timeout, you are done. If it still fails with 0x800705b4, proceed to Step D.

The message “A hypervisor has been detected. Features required for Hyper-V will not be displayed.” is normal in a nested environment and is not an error.

Step D — Roll WSL Back to a Working Version (if still failing)

WSL version 2.7.8 has a confirmed nested-virtualization regression. Version 2.7.3 works. If Step C still fails, roll back WSL inside Windows (run everything as Administrator in PowerShell):

1. Remove the current WSL Appx registration:

Get-AppxPackage -AllUsers | Where-Object { $_.PackageFamilyName.contains("MicrosoftCorporationII.WindowsSubsystemForLinux") } | Remove-AppxPackage -AllUsers

2. Download WSL 2.7.3 MSI (curl.exe is more reliable than Invoke-WebRequest):

mkdir C:\Temp
curl.exe -L -o C:\Temp\wsl273.msi https://github.com/microsoft/WSL/releases/download/2.7.3/wsl.2.7.3.0.x64.msi

Verify the downloaded file is approximately 255 MB. A smaller file indicates an incomplete download.

3. Install the MSI:

msiexec /i C:\Temp\wsl273.msi /L*VX C:\Temp\wsllog.txt

4. Restart the Windows VM and run wsl --install Ubuntu again.

Prevent Automatic WSL Update to a Broken Version

PRO Manager calls wsl --update on every start. If you depend on WSL 2.7.3, this automatic update can silently overwrite the working version with the broken one.

Options to block the update:

• Group Policy / Registry: Disable automatic WSL updates via HKLM\SOFTWARE\Policies\Microsoft\Windows\WSL.
• Monitor manually: Run wsl --version periodically. If it reverts to 2.7.8, repeat Step D.

This is a temporary workaround until Microsoft resolves the nested-virt regression. The preferred long-term solution is Step B (full Hyper-V flag set), which allows running even on newer WSL versions.

---

2. VMware ESXi / vSphere

Enable via vSphere UI

In vSphere Client, go to the VM → Edit Settings → Virtual Hardware → CPU and enable:

• Expose hardware-assisted virtualization to the guest OS
• Expose IOMMU to guest (optional, recommended for WSL2)

Enable via CLI (ESXi host)

vim-cmd vmsvc/getallvms        # find VM ID
vim-cmd vmsvc/power.off <vmid>

Edit the VMX file and add:

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

VMware Workstation / Fusion

In VM Settings → Processors, check:

• Virtualize Intel VT-x/EPT or AMD-V/RVI
• Virtualize CPU performance counters (optional)

VMware Workstation requires Windows Hypervisor Platform (WHP) enabled on the host if both VMware and WSL2 are used simultaneously.

---

3. Microsoft Hyper-V

When Windows runs inside Hyper-V (Azure, Windows Server Hyper-V role), enable nested virtualization on the Hyper-V host.

Enable on Hyper-V Host

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

VM must be shut down (not saved or paused) before running this command.

Verify Inside the VM

Get-WmiObject Win32_Processor | Select-Object VirtualizationFirmwareEnabled
# Should return: True

Azure VM Sizes

Only specific VM families support nested virtualization. Supported families include Dv3 / Dsv3, Ev3 / Esv3, D_v4 / E_v4 and newer, and any .metal bare-metal instance.

B-series (burstable) VMs do NOT support nested virtualization. Avoid B-series if WSL2 is required.

---

4. Oracle VirtualBox

VirtualBox nested virtualization support is limited and may be unstable with WSL2.

Enable via GUI

VM Settings → System → Processor → check Enable Nested VT-x/AMD-V.

This option may be greyed out if the VM is running, or if Hyper-V is active on the Windows host (incompatible with VirtualBox hardware acceleration).

Enable via CLI

VBoxManage modifyvm "<VMName>" --nested-hw-virt on

VirtualBox + WSL2 nested virtualization is not officially supported and may cause instability. For production deployments, prefer Proxmox/KVM or VMware.

---

5. Windows Guest Configuration Checklist

After enabling nested virtualization on the hypervisor, verify all of these inside the Windows VM:

Check	Command	Expected result
Hyper-V in BCD	bcdedit /enum | findstr -i hypervisor	hypervisorlaunchtype Auto
WSL feature	dism /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux	State: Enabled
VM Platform	dism /online /get-featureinfo /featurename:VirtualMachinePlatform	State: Enabled
Hypervisor Platform	powershell -command "Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform"	State: Enabled
WSL version	wsl --version	WSL version: 2.x.x
WSL debug shell	wsl --debug-shell	Opens a shell (no error)
Nested VM test	wsl --install Ubuntu	Completes without timeout

Note: HypervisorPlatform is a separate Windows feature from VirtualMachinePlatform — both must be enabled.

If HypervisorPlatform is disabled, enable it and restart:

DISM /Online /Enable-Feature /All /FeatureName:HypervisorPlatform

---

6. Detailed Diagnostics

Use this when you are not sure which layer the problem is in. Work top-down.

6.1 Confirm Windows is running as a VM

Get-WmiObject Win32_ComputerSystem | Select-Object Manufacturer, Model

If Manufacturer is QEMU, VMware, or Virtual, this is a nested scenario and nested virt must be enabled on the host. If it is real hardware (Dell / HP / Lenovo), the problem is elsewhere.

6.2 Verify VMX flag is passed through

On the Proxmox host, check the running QEMU process:

ps aux | grep "kvm.*<VMID>" | grep -o "\-cpu [^-]*"

The -cpu line must contain +vmx. If it is missing, the CPU config did not take effect — verify the qm set -args was applied and perform a full qm stop / qm start.

6.3 Check the Hyper-V Event Log

Immediately after a failed WSL start attempt, run inside Windows:

Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-Worker-Admin' -MaxEvents 20 | Format-List

If you see “started successfully” followed about 60 seconds later by “was turned off” for the same VM ID, the nested VM was created but did not start in time. This is a typical sign of missing Hyper-V enlightenment flags (Step B) or an incompatible WSL version (Step D).

6.4 Separate a platform problem from the runtime package

If you are unsure whether the PRO Manager .tar package is faulty or WSL2 is broken on that VM:

wsl --install Ubuntu

If clean Ubuntu also fails with 0x800705b4, the issue is the platform (nested virt + WSL), not the PRO Manager package. If Ubuntu works but PRO Manager does not, check the import path and the service account under which the distro is registered.

---

7. Troubleshooting Common Errors

Error code	Meaning	Fix
0x800705b4 CreateVm	Nested VM creation timeout — nested virt not enabled, missing CPU flags, or incompatible WSL version	Steps A → B → C → D above
0x8000000d Install in progress	Stuck/leftover WSL distro registration	wsl —unregister <distro>, then wsl —shutdown; or delete the Lxss registry key
ERROR_FILE_EXISTS	Import target path already contains an old VHDX	Delete …\Runtime&lt;distro>\wslDiskStorage, then re-import
WSL_E_DISTRO_NOT_FOUND	Distribution registered under a different Windows user account	Re-import the distro under the myscada9 service account
ERROR_FILE_NOT_FOUND debug-shell	Missing or corrupt WSL kernel package	Reinstall the WSL MSI (Step D above)
0x80070005 Access denied	Insufficient permissions for WSL operations	Run as the service account that owns the WSL distros (myscada9)

---

8. WSL2 Memory Configuration

By default, WSL2 may claim up to 80% of available host RAM. On a VM with limited memory, this can cause the WSL VM to fail to start. Always configure a .wslconfig file for the service account running WSL.

File location: C:\Users\myscada9\.wslconfig

[wsl2]
memory=8GB
processors=2
swap=2GB

After editing .wslconfig, run wsl --shutdown to apply the new limits.

Recommended memory allocation:

VM Total RAM	WSL2 memory= setting
8 GB	memory=4GB
16 GB	memory=8GB
32 GB	memory=12GB

Leave at least 4–6 GB for Windows itself and the PRO Manager application running alongside WSL2.

---

9. Quick Checklist — New Proxmox VM Deployment

Before deploying PRO Manager on a new Windows VM on Proxmox:

• Nested virt enabled on the physical host (cat /sys/module/kvm_intel/parameters/nested returns Y)
• VM has the full set of CPU flags including +vmx and Hyper-V enlightenment flags (qm set -args "...")
• qm stop + qm start performed after the CPU change (not just a Windows reboot)
• Windows: hypervisorlaunchtype is Auto; features WSL, VirtualMachinePlatform, and HypervisorPlatform all Enabled
• WSL on a working version (wsl --version — if needed, downgrade to 2.7.3 via MSI)
• Test: wsl --install Ubuntu completes without 0x800705b4
• WSL auto-update handled (so a broken version does not come back)
• .wslconfig memory limit set for the myscada9 service account