VMware workstation nested virtualization and WSL2 disaster

Got caught into the WSL2 hype and ran into the surprise of errors such as “Virtualized Intel VT-x/EPT is not supported on this platform”? me too (…) welcome to VMware’s dumpster fire of nested virtualization not working along with Hyper-V. 

This was a well-known issue and VMware tried to calm waters back in may with little success, as you can see in their blog post announcing Workstation 15.5 supporting Hyper-V mode, where they had to turn off commenting because people was ranting like crazy.

https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html

Long story short, as of Workstation release 16.0.0 build-16894299 this still doesn’t work. The symptoms are always related to VMs with Virtualization Engine features enabled, ending up in errors such as the one mentioned before “Virtualized Intel VT-x/EPT is not supported on this platform”.

There are common factors for such error and for most people (or at least fellow network engineers around me) are:

  • WMware Workstation Pro version 15.5.5 and up.
  • Windows 10 version 2004, in any flavor in the 19041.x OS build.
  • Windows Subsystem for Linux enabled for WSL2, including system features:
    • Virtual Machine Platform
    • Windows Hypervisor Platform

This combo enables Hyper-V as a competing virtualization engine in your computer which VMware Workstation doesn’t like and therefore makes nested virtualization unusable (virtual machines inside your virtual machine). VMware is nowhere near to have this solved (surprisingly VirtualBox is closer to get it sorted out) and I gave up for now looking for options out there (there are some, but with heavy penalties to performance both for the VM and your base OS). I needed my nested VMs back so here’s a recipe for rolling back to middle ground: nested virtualization back but only with WSL1, if you can live without a full Linux kernel in your terminal then this is for you.

1 Launch a CMD terminal as administrator and check your current WSL VMs version with  wsl -l -v 
1
2
3
wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-18.04    Stopped         2
2 Rollback your existing VMs to WSL1 with  wsl –set-version {VM NAME} 1  and crosscheck that migration was successful with the same command from step 1
1
2
3
4
5
6
7
wwsl --set-version Ubuntu-18.04 1
Conversion in progress, this may take a few minutes...
Conversion complete.

wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-18.04    Stopped         1
3 Set the default WSL version for newer VMs to version 1 to avoid issues with later installs  wsl –set-default-version 1  
4 Now disable both the virtual machine and the hypervisor features in Windows using DISM like so  dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /featurename:HypervisorPlatform /norestart   Note the “/norestart” parameter so you can save your work before restarting your computer.
1
2
3
4
5
6
7
8
9
10
dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /featurename:HypervisorPlatform /norestart

Deployment Image Servicing and Management tool
Version: 10.0.19041.572

Image Version: 10.0.19041.572

Disabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.

Now restart your computer and you will get the classic “we’re working on your updates” screen. After login, if everything went well, you should be able to start a VM with nested virtualization while keeping at least WSL1. It’s a huge trade-off, i know.

Thanks VMware

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.