Virtualization Applications Are Not Working: What Do You Do?
When you install a virtualization application on a Windows machine on which Hyper-V or related services are installed, errors can often occur. Errors that happen when you run VMs on non-Hyper-V virtualization applications cause significant problems. This blog post explains what causes these errors, how to fix them, and how to run other virtualization applications on a computer with Hyper-V.
Background and Working Principle
After you install VMware Workstation, VMware Player, or Oracle VirtualBox on a Windows machine, you might get errors when starting a VM in these virtualization applications. The errors occur even if Hyper-V VMs are not running at that time. You can install VMware Workstation and VirtualBox, and run VMware VMs and VirtualBox VMs on the same computer, but not simultaneously. What causes this problem with Hyper-V? Let’s take a closer look.
VMware Workstation, VMware Player, and VirtualBox are type 2 hypervisors, while Hyper-V is a type 1 hypervisor. A type 2 hypervisor is installed on the operating system that is running on hardware. A type 1 hypervisor is installed on top of hardware. All hypervisors require processor virtualization extensions, which are instruction sets for hardware virtualization – Intel VT-x or AMD-V. Hyper-V takes control of virtualization extensions when Windows boots. These virtualization extensions are not available for VMware Workstation and VirtualBox when Windows loads. Only one software component can use Intel VT-x or AMD-V at a time.
This incompatibility is caused by Hyper-V because virtualization extensions are not exposed to type 2 hypervisors installed on a Windows machine where the Hyper-V role is enabled.
VMware Workstation errors:
VMware Workstation and Hyper-V are not compatible. Remove the Hyper-V role from the system before running VMware Workstation.
VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential guard.
VirtualBox errors:
BSOD, such as BSOD with SYSTEM_SERVICE_EXCEPTION
VT-x is not available (VER_VMX_NO_VMX). E_FAIL (0x80004005).
A VirtualBox VM works too slowly and uses the paravirtualisation (emulation) mode.
The most interesting situation is when a user doesn’t install Hyper-V and still encounters one of the errors mentioned earlier when using VMware Workstation or VirtualBox. The error occurs when automatic Windows updates are enabled. With the updates (Windows 10 v1607 and the appropriate Windows Server versions starting from Windows Server 2016), some new Hyper-V-related features are installed and enabled automatically without Windows user consent. These features are Device Guard and Credential Guard. Windows updates known vulnerabilities but can add issues and destroy a working configuration. That’s why many users don’t like automatic updates.
Device Guard is a group of security features in Windows. The idea of implementing this feature is to harden the execution of malicious code. Device Guard is available in Windows 10, Windows Server 2019, and Windows Server 2019. The main requirements are: UEFI running in native mode and Secure Boot enabled.
Credential Guard is a feature to minimize the impact of attacks if malicious code is already running by isolating system and user secrets to make more difficult to compromising.
Virtual Secure Mode (VSM) is a feature to leverage processor virtualization extensions that secures data in an isolated region of memory. HVCI is Hypervisor-protected code integrity. LSA is Local Security Authority.
Virtualization Based Security (VBS) is a class of technologies that uses virtualization extensions, including VSM, to provide security in Windows. The Hyper-V role is required to make these features work (Hyper-V management tools are not needed).
The hypervisor (Hyper-V) loads first, and then the operating system (Windows) loads. Hyper-V provides an abstraction layer between hardware and the operating system. A VSM allows the tagging of specific critical processes and memory used by them as they belong to a separate independent operating system controlled by Hyper-V. The principle is similar to the isolation of two VMs running on a Hyper-V host when each VM can use only the hardware resources provisioned to it.
Note: If you need a type 1 hypervisor from VMware, use VMware ESXi and VMware vSphere environment. Learn more in these blog posts: Hyper-V vs VMware, VMware Workstation vs VMware Player, and How to install ESXi on Hyper-V.
Let’s explore how to resolve the incompatibility issue of Hyper-V and other virtualization applications in detail.
Method 1: Uninstall Hyper-V in the GUI
Check system information about Windows configuration by running the following command in CMD:
msinfo32.exe
A System Information window opens. On the following screenshot, you see that Hyper-V is enabled (a hypervisor has been detected), and Device Guard Virtualization-based security is running. Now you can remove these features.
You should be aware that the following Hyper-V related features will not be available after you remove Hyper-V:
- Hyper-V
- Credential Guard and Device Guard
- Virtual Machine Platform
- Windows Sandbox
- WSL2.
Remove the Hyper-V feature in the graphical user interface (GUI) by using Control Panel, Add Roles, and Features wizard.
In Windows 10, open Control Panel, click Programs and Features, then click Turn Windows features on or off.
The Windows Features window opens.
Deselect the Hyper-V checkbox, and hit OK.
To finish removing Hyper-V, restart the computer.
The steps for removing Hyper-V on Windows 10 and Windows Server 2016 are similar.
In Windows Server 2016, open Server Manager and click Manage > Remove Roles and Features. In the Remove Roles and Features Wizard, go to the Server Roles step, and deselect Hyper-V. Hit Next at each step to continue. Restart is required to finish removing the Hyper-V role.
Method 2: Use PowerShell to Disable the Hyper-V Feature
You can do a similar action by using the command-line interface rather than the GUI.
Log in to PowerShell as Administrator, and run the command to disable the Hyper-V feature:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
Restart your host machine:
shutdown -r -t 0
Method 3: Disable Hyper-V by Using BCDedit
The idea behind this method is to edit boot configuration data and disable booting of Hyper-V without uninstalling the Hyper-V role.
Log in to PowerShell as Administrator, or run the command from an elevated command prompt to disable Hyper-V:
bcdedit /set hypervisorlaunchtype off
If you need to re-enable Hyper-V and set the default value back, run this command:
bcdedit /set hypervisorlaunchtype auto
For more control and convenience, disable fast boot in Windows 10. Open Windows Registry Editor, and go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Set the HiberbootEnabled parameter to 0
If you need to use Hyper-V VMs sometimes, create two entries for a Windows boot loader: one to boot Windows with Hyper-V and another to boot Windows without Hyper-V. Then, select the needed option before you boot Windows. This approach prevents you from running commands in PowerShell manually each time when you need to enable or disable Hyper-V.
bcdedit /copy "{current}" /d "No Hyper-V"
“The entry was successfully copied to {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.”
Copy and paste your value instead of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
bcdedit /set "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" hypervisorlaunchtype off
Restart the computer.
Once your computer has restarted, you should see two options in Windows Boot Manager.
If you want to remove the No Hyper-V boot entry, use the /delete option for bcdedit.
Get a list of the current boot entries:
bcdedit /v
A list of all entries with their identifiers is displayed in the output. Copy the ID of the entry which you want to remove, and run the following command:
bcdedit /delete "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
Method 4: Uninstall the Hyper-V Role in PowerShell with dism.exe
The idea behind this method is to use the Deployment Image Servicing and Management tool in the command-line interface to uninstall Hyper-V.
Log in to CMD or PowerShell as Administrator. Run the following command to uninstall Hyper-V:
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
If you want to install Hyper-V again, use this command:
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Method 5: Turn off virtualization Based Security in Windows
This method is used to disable Device Guard and Credential Guard, which are Hyper-V-related features.
Open the Group Policy Editor for a local machine. The group Policy Editor is available in Windows 10 Pro, Enterprise, and Education. In the command prompt, run gpedit.msc
Go to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard
Double-click Turn On Virtualization Based Security. By default, the status of this setting is Not configured.
In the window that opens, select Disabled and hit OK to save settings, and close the window.
Edit Registry as an alternative
In Windows 10 Home, where the Group Policy Editor is not present, you can disable Virtualization Based Security in Windows Registry.
Create a backup of the Windows registry before changing registry settings to avoid errors and issues.
Open Registry Editor. Run regedit in the command line that should be opened as Administrator.
Go to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard
Create the EnableVirtualizationBasedSecurity entry if this entry is missing. To create a new entry, right-click an empty place in the DeviceGuard directory, and in the context menu, click New > DWORD (32-bit) Value. Enter the EnableVirtualizationBasedSecurity name for this registry entry. By default, data set for this entry should be 0 (see the following screenshot). You can double-click the EnableVirtualizationBasedSecurity and set 0 manually.
Go to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Lsa
Create a new registry entry in the Lsa directory. Right-click an empty space in the right pane of the Registry Editor window. In the context menu, click New > DWORD (32-bit) Value.
Enter the LsaCfgFlags name for this value. This value must be set to 0.
Close the Registry Editor, and restart your computer.
You can run the following commands in PowerShell (as Administrator) to disable Device Guard and Credential Guard on the next Windows boot.
Mont a UEFI system partition to the drive X: (select an unused volume):
mountvol X: /s
Copy the C:\Windows\System32\SecConfig.efi to X:\EFI\Microsoft\Boot\SecConfig.efi with an option to overwrite the file if the file exists. This file is a boot image for Windows security configuration tool.
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
Create a new option in the boot menu with the ID {0cb3b571-2f2e-4343-a879-d86a476d7215} and the DebugTool name:
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
Set the boot option you created to boot at the previous step to \EFI\Microsoft\Boot\SecConfig.efi:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
Set Windows Boot Manager to make the new entry the default one for the next reboot. After that, reboot your Windows should go back to normal boot.
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
Set the bootloader to pass the options DISABLE-LSA-ISO,DISABLE-VBS to the SecConfig.efi file when the bootloader launches the file.
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
Set the partition for the booted drive to the X: drive:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
Unmount the X: drive from the system:
mountvol X: /d
Method 6: Update VMware Workstation
If you have Windows 10 version 2004 (20H1) build 19041 or newer on your physical computer, you can upgrade VMware Workstation to VMware Workstation 15.5.6 or newer and run VMware VMs on your Windows machine without disabling/uninstalling Hyper-V and Virtualization Based Security (VBS) features, including Device Guard and Credential Guard.
Due to many complaints from customers, Microsoft and VMware decided to develop a joint project that adopts Microsoft Windows Hypervisor Platform (WHP) APIs to allow type 2 hypervisors, such as VMware Workstation, to run on a host where Hyper-V is enabled. These APIs allow applications to manage CPU resources, read/write registry values, terminate CPU operation, and generate interruptions.
VMware Workstation before version 15.5.5 uses a Virtual Machine Monitor (VMM) that has direct access to a CPU and virtualization instruction sets (Intel VT-x or AMD-V). A VMM operates in a privileged mode. If Virtualization Based Security features are enabled on a Windows host, then an additional hypervisor layer (Hyper-V) is added between hardware and Windows. Hyper-V has direct access to CPU features used for hardware virtualization, and VMM has no access to CPU virtualization features.
VMware made changes in the architecture of VMware Workstation 15.5.6 to allow their product to use Microsoft WHP APIs and fix the compatibility issue. VMM can now run at the user level (not in the privileged mode) using the WHP APIs and run VMs without direct access to CPU virtualization extensions. This mode is called User Level Monitor (ULM) or a Host VBS mode. If you uninstall Hyper-V-related features from your Windows host, VMware Workstation detects it automatically, and VMM is switched to direct access of CPU virtualization extensions (running in the privileged mode).
Windows Hypervisor Platform (WHP) must be installed on a physical Windows machine where Hyper-V is enabled to allow VMware Workstation to run VMware VMs on this machine. Install the Windows Hypervisor Platform feature in Control Panel by clicking Turn Windows features on or off.
Thus, you can update Windows 10 and VMware Workstation on your physical machine to versions that support running Hyper-V-related features and VMware Workstation VMs on the same machine.
Limitations of the Host VBS mode:
- Windows Hypervisor Platform is not supported on Windows Server 2016 and other Windows Server versions and editions. As a result, VMware Workstation cannot run VMs in the host VBS mode on physical machines running Windows Server.
- Nested Virtualization is not supported. You cannot run nested VMs (VMs inside VMware Workstation VMs).
- VMware VMs can run slower.
- X86 performance monitoring counters (PMC) are not supported.
- User-mode protection keys (PKU) capability is not available.
- Restricted transactional memory (RTM) and hardware lock elision (HLE) capabilities are not available.
VirtualBox and Hyper-V
VirtualBox can co-exist with Hyper-V, Device Guard, and Credential Guard starting from VirtualBox 6.0. VirtualBox 6 can work with Hyper-V APIs similarly to VMware Workstation on Windows 10 v1803 x64.
These features must be enabled on a host Windows machine to allow VirtualBox to work with Hyper-V APIs:
- Hyper-V
- Windows Hypervisor Platform
If the Hyper-V feature is enabled, but the Windows Hypervisor Platform feature is disabled, in System > Acceleration in VM configuration summary, you can see that the Paravirtualisation mode is on. If you try to start a VM, VirtualBox reminds you that you should enable Windows Hypervisor Platform and displays the error message.
The error message:
WHvCapabilityCodeHypervisorPresent is FALSE! Make sure you have enabled the ‘Windows Hypervisor Platform’ feature.
(VERR_NEM_NOT_AVAILABLE).
VT-x is not available (VERR_VMX_NO_VMX).
If the required Hyper-V-related features in Windows are enabled, the following information is displayed for the VM in the System section:
Acceleration: VT-x/AMD-v, Nested Paging, Paravirtualization Hyper-V
The VM should start successfully. A green turtle icon is displayed in the bottom panel of the VirtualBox window. This icon indicates that a VM is running in the Hyper-V paravirtualization mode instead of the native mode that is usually used by VirtualBox when interacting directly with CPU virtualization extensions. The performance of VirtualBox VMs degrades on machines on which Hyper-V and related features are enabled. You can disable or remove Hyper-V as explained earlier to run VMs on VirtualBox in the native mode using CPU virtualization extensions directly.
Read also the VirtualBox vs Hyper-V comparison and the VirtualBox vs VMware comparison.
Conclusion
New Windows features such as Virtualization Based Security (Device Guard and Credential Guard), Windows Sandbox, WSL that use the Hyper-V engine cause a lot of problems to users, administrators, and software developers using other hypervisors such as VMware Workstation, VirtualBox, QEMU, and Google Android Emulator on Windows machines. There are two approaches to resolve these incompatibility issues: Disable/uninstall Hyper-V or use new versions of virtualization applications that support work with Hyper-V APIs, such as Windows Hypervisor Platform API provided by Microsoft.
Running VMs on VirtualBox, VMware Workstation, and other hypervisors on machines with Hyper-V by using APIs can degrade the performance of non-Hyper-V VMs. Data backup is crucial for the cases when virtualization applications fail. If you still haven’t chosen the best Hyper-V backup solution for your environment, consider NAKIVO Backup & Replication. The solution offers robust backup, ransomware protection, disaster recovery and more. Download the Free Edition to see the solution in action.
