Understanding the Hyper-V Conundrum on Windows 11
Windows 11, by default, doesn’t have the full Hyper-V features enabled (to run Hyper-V guests), but it does utilize the Hyper-V hypervisor for certain “Virtualization-Based Security” (VBS) features. These include Device Guard, Credential Guard, and core (memory) isolation. Essentially, with VBS, the entire host operating system runs as a Hyper-V guest on top of the Hyper-V platform.
This virtualization layer can have a detrimental performance impact, mostly unnoticeable in normal use but potentially more significant for tasks like gaming. However, the trade-off is that with the OS running as a “guest,” all hardware access must cross the virtualization boundary, enabling additional security features to mitigate modern attack vectors. Microsoft deems these protections to outweigh the performance hit, so as of Windows 11 version 22H1 or 22H2, memory integrity protection, Device Guard, and Credential Guard are enabled by default on new OS installs, provided the system’s UEFI settings have CPU virtualization capabilities (VT-d, etc.) enabled.
The Virtualization Dilemma
This presents a dilemma for users running Type 2 (hosted) hypervisors like VMware Workstation/Player or VirtualBox. If the Hyper-V hypervisor is active on the system, these virtualization platforms will use the Hyper-V APIs to create the virtualized environment for their guest VMs. In essence, Hyper-V is running the virtual “hardware” for the Type 2 hypervisor, while the Type 2 hypervisor provides value-added features like USB capture and 3D-accelerated graphics.
The trade-off is that this “referred” virtualization is slower than the Type 2 hypervisor’s own implementation would be if it could run in full-privilege mode, access VT-d directly, and operate its own virtualization stack. This is where the user/admin must make a decision: prioritize the enhanced security features provided by VBS and maintain Hyper-V interoperability (allowing the Type 2 hypervisor to coexist alongside Hyper-V features), or ditch the Hyper-V platform altogether to get the best possible performance from the Type 2 hypervisor.
Checking the Virtualization Status
To determine whether your VMware Workstation/Player or VirtualBox is running its own virtualization stack or using the Hyper-V APIs, follow these steps:
- Open the System Information app (search for it in the Start menu).
- Look for the “Virtualization-based Security” entry near the bottom of the System Summary page.
- If this entry does not say “Not enabled,” the Hyper-V hypervisor is in control, and the host OS is essentially a well-disguised guest OS.
Additionally, you can check the VMware.log file for any running VMs. Look for the “Monitor Mode:” entry and see the value after the colon. If the value is “CPL0,” the VMware engine is running. If the value is “UML,” the slower Hyper-V API is in use.
Removing the Hyper-V Hypervisor
If you’ve decided to prioritize performance over the added security features and want to let the host OS run without Hyper-V virtualization, follow these steps:
Phase 1: Initial Attempts
Some users have reported success with the following steps:
- Check the System Information app again. If the “Virtualization-based Security” entry now says “Not enabled,” you’re good to go.
- If not, proceed to Phase 2.
Phase 2: Additional Troubleshooting
If Phase 1 didn’t work, try the following:
- Open the Control Panel and go to “Programs” > “Turn Windows features on or off.”
- Locate and uncheck the “Hyper-V” option, then click “OK” to apply the changes.
- Reboot your system.
- Check the System Information app again. The “Virtualization-based Security” entry should now say “Not enabled.”
Phase 3: The Microsoft Script Solution
If the above steps still didn’t work, there’s a Microsoft-provided script that can help:
- Download the “Device Guard and Credential Guard Hardware Readiness Tool” from the Microsoft website: Download Link
- Extract the ZIP file and navigate to the extracted folder.
- Open an administrative PowerShell prompt and run the following command:
.\DG_Readiness_Tool_v3.6.ps1 -Disable - Follow the on-screen instructions, including rebooting your system and pressing F3 to disable both Device Guard and Credential Guard.
After running this script, check the System Information app again, and the “Virtualization-based Security” entry should now say “Not enabled.” This should allow your VMware or VirtualBox virtualization to run at the optimal “CPL0” privilege level.
Addressing Windows Sandbox and Containers Challenges
Windows Sandbox Configuration
If you’re experiencing issues with Windows Sandbox, try the following:
- Ensure that you have the necessary optional features enabled for Windows Sandbox, but avoid enabling any Hyper-V-related features.
- Keep in mind that Windows Sandbox is designed to run in a single instance, and spawning a box within a box may not be possible.
Containers and Rancher Desktop
Some users have reported problems with Rancher Desktop’s integration with the Windows Subsystem for Linux (WSL). If you encounter issues, try the following:
- Uninstall any existing WSL installations and then reinstall Rancher Desktop. This should prompt the installation of the required WSL components.
- If you still encounter errors, try running the following command in an elevated PowerShell prompt:
wsl --update
This will ensure that your WSL installation is up-to-date.
Remember, the Windows 11 virtualization landscape has become more complex, with the introduction of VBS and the interplay between Hyper-V, Type 2 hypervisors, and container technologies. By following the steps outlined in this article, you should be able to navigate these challenges and optimize your Windows 11 system for your specific needs, whether that’s maximizing performance or maintaining essential security features.
For more IT-related tips and insights, be sure to visit the IT Fix blog regularly.
