Feature request: nested virtualization for Windows 11 guests (Hyper-V, WSL2, VBS) #102

Description

Please add nested virtualization for Windows 11 guests on Apple silicon M3 and later, the same way VMPal already offers it for Ubuntu and Fedora guests.

Today a Windows 11 VM gets no virtualization extensions (nestedVirtualization: false in the VM's limits, and Windows reports HypervisorPresent = False). So everything in Windows that sits on top of its own hypervisor is unavailable.

Ideally the setting would be a per-VM toggle, like the Linux one, so people who don't need it keep the current behavior and performance.

Why this feature/change is important?

A lot of everyday Windows development and testing depends on the Windows hypervisor. Without it, a Windows VM on a Mac can't be used to build or test any of it:

• Hyper-V: testing Hyper-V VMs, Hyper-V PowerShell modules, VM provisioning scripts and lab setups (Windows Server/AD labs, Packer/Vagrant Hyper-V builders).
• WSL2: WSL2 distros, and everything built on them (Docker Desktop's WSL2 backend, Linux toolchains, dev containers, VS Code Remote-WSL). WSL1 is the only option today.
• Windows containers and Docker: process/Hyper-V isolated containers, Windows Sandbox, and the Containers feature in general.
• Virtualization-based security: Memory Integrity (HVCI), Credential Guard, VBS enclaves and Windows Hello ESS. These are on by default on new Windows 11 hardware, so a VM without them doesn't behave like real Windows 11 machines, and security tooling can't be validated against them.
• Windows Hypervisor Platform: apps that use WHP (Android emulator, QEMU/WHPX, some virtualization-aware tooling).

There's also a practical side effect today: if the Windows Containers optional feature is enabled in the guest, cumulative updates fail in a loop. The update reboots, reaches about 40%, rolls back and stays pending, with 0x800F0922. CBS.log shows Container Installer containerai.dll 800706d9, because the Container Manager Service can't start ("No hypervisor is present on this system", event 7023). The workaround is to disable the Containers features, which isn't obvious to most users.

Environment where this was seen:

• Mac: Apple M5 Max, macOS 27.2
• VMPal 0.108
• Guest: Windows 11 Pro Insider Preview (Beta), build 26220, arm64

Related: #70 (using VMPal's containers from a Windows guest). That covers the Docker use case from the Mac side; nested virtualization would cover Hyper-V, WSL2 and VBS inside the guest itself.

Thanks for VMPal!