After an update to a Windows 10 system to the 20H2 build, it was quickly noted that the device manager added virtual ethernet ports to support Hyper-V. A sneaky suspicion that this would break VMware Workstation 15 and it did.
A VMware Workstation Solution
The first thought, why not try to launch a virtual machine in the existing VMware Workstation 15. The following message presented itself.
Your host does not meet minimum requirements to run VMware workstation with Hyper-V or Device/Credential Guard enabled.
Since the introduction of Hyper-V, including Credential Guard and Device Guard, enabling any of these features prevented VMware Workstation from launching virtual machines. According to VMware, an update to 15.5.7 should resolve everything.
After updating to the latest free update 15.5.7 an attempt to launch the same virtual machine revealed a new error.
VMware Workstation does not support nested virtualization on this host. Module ‘MonitorMode’ power on failed.
Something that used to work in older versions of VMware Workstation no longer works. To resolve this problem, ensure that the following items are unchecked in the Virtualization engine section under the Virtual Machine Settings. Technically, from what I have read, uncheck the top two and the Virtualize IOMMU (IO memory management unit) may be checked.
After removing those features, I was able to start the virtual machine. However, another problem remains. There are many virtual machines that are suspended. These virtual machines have the Virtualization engine options greyed out. A forceful shutdown will be needed, but will loose the current state. If you are not in this predicament, then you can stop reading here.
More Drastic Measures
Since there could be lost data, the next approach is to attack this problem from the other side, Microsoft. There are two approaches.
To disable Device Guard or Credential Guard disable the group policy setting that was used to enable Credential Guard.
- On the host operating system, click Start > Run, type gpedit.msc, and click Ok. The Local group Policy Editor opens.
- Go to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security.
- Select Disabled.
Another approach is run the following bcdedit command at an elevated command prompt and reboot.
bcdedit /set hypervisorlaunchtype off
Since the first of the two solutions looks to be too many steps, I elected to use the bcdedit approach. After a reboot, the suspended virtual machines started successfully and a quick peak at the network devices reveals that the virtualized Hyper-V cards are all removed.
I could either leave the hypervisorlaunchtpe off or gracefully shutdown all suspended virtual machines, edit their settings to remove the offending virtualization engine options and then re-enable the hypervisorlaunchtype to on. Options abound.
bcdedit /set hypervisorlaunchtype on
Source(s)
- https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html
- https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v
- https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-does-not-support-nested-virtualization-on/td-p/1864217
