Since purchasing a Razer Blade 15 Advanced, I have been using Windows 10 Pro as my primary operating system. Although I am no stranger to Windows, it has been over sixteen years since I last used it as my daily driver.

As highlighted in the article “macOS and Windows”, the transition to Windows was fairly seamless. However, I have had a few challenges with my development workflow, which on macOS utilised a combination of Docker and VMware Fusion. I would do the majority of my development locally, leveraging Docker natively installed on macOS, but also have a range of virtual machines (e.g. Fedora, Ubuntu, Windows 10) running to support specific activities.

In theory, the same setup is viable on Windows 10. However, unfortunately VMware Workstation Pro (the Windows alternative to VMware Fusion) can only launch a Virtual Machine if Hyper-V is disabled. This would be fine, except the default install of Docker for Windows requires Hyper-V.

This frustrating “catch-22” means that you cannot run Docker and VMware Workstation Pro simultaneously. If you attempt to do so, you will receive the error “VMware Player and Device/Credential Guard are not compatible”.

VMware Workstation Pro - Issue

Outlined below are three options to mitigate this issue.

Option One: Hyper-V Only

Hyper-V is the native Microsoft Hypervisor built into Windows 10 Pro. Knowing that Docker is built on Linux Container technology, it leverages Hyper-V to run containers on Windows. This makes sense, as Hyper-V is performant, efficient and natively available, allowing Docker to focus on their code (instead of the Hypervisor). There are third-party projects that attempt to make Docker run on a VMware Hypervisor, however, as these are community developed, I am not convinced they can be trusted for business workloads.

Knowing that Hyper-V is a hypervisor, the first option would be to use Hyper-V to host all virtual machines? This would remove the need for VMware Workstation Pro and therefore avoid the conflict, mitigating the issue.

Hyper-V is an excellent hypervisor, especially when acting as a backing service and/or managing server-side workloads. Unfortunately, the client experience has some frustrating limitations.

  • The initial setup and networking configuration for guest operating systems can be cumbersome.
  • Access to virtual machines will need to occur via RDP (or equivalent), which will impact some native features of the guest operating system (e.g. audio, video, graphics, etc.)
  • Installation of native drivers on a virtual machine is complex and in some cases, not possible.
  • Limitations associated with dynamically attaching and removing external devices from the virtual machine.
  • Specific limitations related to running Linux virtual machines, impacting core services (e.g. sound, etc.)

In short, Hyper-V on Windows 10 Pro is essentially a “free” embedded hypervisor, primarily used to facilitate specific Windows 10 tasks. VMware Workstation Pro is a paid, standalone product, focused exclusively on hosting virtual machines. Therefore, it should be no surprise that VMware offers the superior experience.

With this in mind, although I could probably make Hyper-V work, I do not feel replacing VMware Workstation Pro with Hyper-V is the right option for me.

Option Two: VMware Only

The second option would be to leave Hyper-V disabled, enabling VMware Workstation Pro and installing Docker on a guest operating system running in a virtual machine.

This option assumes that Hyper-V is not required for any other service, as well as places a higher emphasis on the virtual machine. For example, to maximise productivity, it would likely make sense to shift your entire development workflow to the virtual machine. This could bring some advantages (the use of native Linux), but would also impact performance and require you to perpetually maintain a second operating system.

I prefer this option over option one, helped by the fact that I usually maintain a Fedora virtual machine for other purposes. However, there is something about working for long periods within a virtual machine that feels inefficient and cumbersome, likely caused by the additional abstraction layer between the user input and underlying hardware (audio, video, etc.)

Option Three: Hyper-V / VMware Switching

The final option would be to simply enable or disable Hyper-V depending on the situation.

In my scenario, I would need to decide to run Docker or VMware Workstation Pro, but not both simultaneously. Although this would be frustrating, I rarely execute commands at the same time, therefore making the option viable.

The most efficient way to disable Hyper-V is to run the following command as an administrator.

bcdedit /set hypervisorlaunchtype off


Once complete (image below), the system will need to be restarted.

Disable Hyper-V

To reenable Hyper-V, simply run the following command as an administrator.

bcdedit /set hypervisorlaunchtype auto


Again, once the command has completed (image below), the system must be restarted

Enable Hyper-V

On a performant system, the overall process should only take a few minutes, but can still be inconvenient, especially if you have multiple applications open.

Conclusion

Today there is no perfect option. I prefer options two or three, however, they both have drawbacks.

In the future, I hope that Windows Subsystem for Linux (WSL) will permanently remediate this issue, allowing Docker to leverage WSL 2 as the backend. In theory, this would remove the need for Hyper-V, replaced by a native Linux kernel.

It would appear this capability is in development (which is great news), but currently only available as a “tech preview”, when combined with a Windows 10 Pro insider build (19018 or higher). I tend to avoid natively installing pre-release software on my primary system, therefore will wait for the general release to complete my testing (expected in April 2020).

software virtualisation virtual_machine windows windows_10 vmware workstation workstation_pro vmware_workstation_pro microsoft hyper-v windows_subsystem_for_linux wsl lifeinwork