Microsoft and VMware have ended an ancient grudge that made the latter's Workstation desktop hypervisor behave badly on Windows.
As explained by Zongmin, product manager for VMware Workstation, Fusion and the vSphere remote console: "Since the introduction of Hyper-V, including Credential Guard and Device Guard, enabling any of these features prevented VMware Workstation from launching virtual machines."
The desktop product couldn't do so because it uses a virtual machine manager that requires direct access to the CPU so it can use the silicon-level virtualization extensions offered by Intel's VT-x and AMD's AMD-V. But as a machine running Windows with Hyper-V enabled runs even Windows as a VM of sorts, anything else running on Windows gets the same privileges. Which meant that VMware Workstation couldn't touch the CPU directly, couldn't access CPUs' virtualization extensions and therefore couldn't run VMs.
Seeing as Workstation's whole purpose is launching VMs, that's not good.
So Microsoft and VMware got together to sort it out. The solution they devised used Microsoft's Windows Hypervisor Platform APIs, tools designed to allow third-party virtualization stacks and applications to create and manage partitions at the hypervisor level. Using the APIs got Workstation working again, but meant the Workstation virtual machine manager now runs at user level instead of in privileged mode. VMware also tickled its product so it is happy without direct access to the CPU.
None of which should be too scary, given that Microsoft has designed Hyper-V to work this way.
All this new goodness is baked into the otherwise-obscure 15.5.5 release of VMware Workstation Pro.
Developers are the main users of desktop hypervisors, which come in handy to run multiple OSes on one machine and/or to simulate apps that run on virtualized servers. While Hyper-V makes that possible from Windows 10 desktops, VMware Workstation has its adherents who value its Virtzilla-centric features. Such developers can now get on with their jobs without hassles. And VMware and Microsoft can point to ever-deeper collaboration, and put the unpleasantness of Hyper-V's late 2000s genesis as a VMware irritant behind us all. ®