Hi All,
I've recently installed VMWare and Ubuntu on a new Windows 10 laptop and I'm finding that after a period of time the VM consistently becomes unresponsive and CPU usage spikes to 100%. If I suspend and awaken the VM it works for a period before the problem reoccurs.
How do I go about solving this?
On the off-chance that this was Linux-specific, I installed DragonflyBSD as well as GhostBSD (FreeBSD 13.1 based I think). They have the same issue...
I have a very similar issue. I have narrowed mine down to the wireless adapter. If I turn the wireless off before I start the VM it runs fine. I am running Ubuntu 22.04.1 LTS and Player 16.2.3 build-19376536. I have no option to select which networking adapter is passed to the VM in the Linux client like I do in the Windows one. Does Workstation Pro have this option on Linux?
I saw a different thread saying that it might be an issue related to Microsoft Visual C++ 2015-2019 Redistributable (x64) and (x86), so I tried reinstalling both and Ubuntu stopped crashing. However that fix only worked for a day.
Here's a thread I was referring to:
https://answers.microsoft.com/en-us/windows/forum/all/msvcp140dll-and-vcruntime140dll-missing-error-...
I can confirm the problem, and a solution which worked for me:
Go to "Turn Windows Features off/on"
There are three possible items:
* Hyper-V - not important here
* Virtual Machine Platform - this is required for WSL2, so leave it enabled
* Windows Hypervisor Platform - this is an API which VMWare can use, but probably only needed for nested virtualisation. Turn it off. VMWare will then use its own hypervisor code, which works fine. This resolves the problem for me.
Thanks for the information - will that stop Hyper-V VM's from running on same machine ?
I was my impression that there can only be one hypervisor ?
I gave up 2 months ago and converted my Ubuntu 22.04 from a VMWare VM to a Hyper-V ditto.
But you loose a lot of nice features doing that (dynamic window resizing, access to devices in VM etc.), so I may convert back.
@vmarb I'm running VMware Workstation 17 on Windows 10 22H2 with an Ubuntu 22.04 VM and have the same issue that the VM hangs, just turning it on and leaving it sitting for 30-60 minutes
Your suggestion of disabling the Windows Hypervisor Platform seems to work (how did you find this?).
Anyway, very grateful for the tip!
The problem seems to have been introduced in a recent Windows Update.
I have never had the Windows Hypervisor Platform enabled and I still have the same freezing issue. Sadly it isn't a solution for me.
I'm simply trying to get Ubuntu 22.04.1 installed and it keeps going dormant. I have to suspend the VM and resume it to get it to continue, and then for only a minute or two. Then I have to do it again ... and again ... and again
Tried plugging an ethernet cable since that seemed to help someone else, no change.
Yeah I spoke too soon, the solution worked for a day or so and now it's back, suspend and resume seems to bring the VM back to life for how long it lasts..
Check your vmware.log file for the virtual machine. If you see Monitor Mode: ULM the windows hypervisor is active on your system.
2022-10-29T03:09:02.385Z In(05) vmx Monitor Mode: ULM
If you see ULM you have to see check several places to confirm if Windows virtualization is active:
Check if hypervisor is set to launch at boot:
bcdedit /enum
...
hypervisorlaunchtype: auto
bcdedit /set hypervisorlaunchtype off
Reboot Required
Check to see if any hypervisor features are enabled:
In order to successfully mitigate the issue you must get the vmware virtual machine to run directly on the CPU. vmware.log should show Monitor Mode: CPL0 if you successfully remove windows virtualization.
2022-12-01T16:38:15.448Z In(05) vmx Monitor Mode: CPL0
I need Hyper-V, WSL enabled (also have docker running locally) so can't disable them sadly 😞
We need these options to co-exist peacefully
I made two changes to my system (then rebooted) which seems to have resolved this. Not sure if both are necessary, but I'll leave others to experiment. Both settings were suggested by other users at various times - I just did both and added a workaround for AzureAD joined workstations:
1. Added "Authenticated Users" to the __vmware__ group. NOTE: I added Authenticated Users, because my workstation is joined to AzureAD, and adding my individual account is a convoluted process, and this seemed simpler (yet still safe).
2. bcdedit /set hypervisorlaunchtype off
My VM has been running for several hours now, without issues.
I thought my problem was also fixed but the next day the problem returned. The problem btw also occurs with other versions of Linux. I can't install Rocky Linux for example (it hangs during installation)
Hyper-V is used for several features on Windows 10 / 11.
https://www.reddit.com/r/vmware/comments/rfs9qh/w11_vmware_workstation_16_and_still_no_amdv/
https://kb.vmware.com/s/article/2146361
Ultimately if you can't get off Monitor Mode: ULM it appears as though you will have to wait to see if VMWare can resolve the nested virtualization issue with the Windows API.
I don't know if any VMWare reps lurk in theses forums to provide some feedback to the community?
Updated to 16.2.5 this morning, and my main Ubuntu MATE 22.04 VM has been running stable for 3 hours now. Since this issue started, I've never been able to keep it running for more than 20 minutes, so it seems the issue is solved. Strangely, the Release Notes do not mention this issue at all...
Great, Please keep us updated - if the fix is long lasting or not.
How is your current configuration in terms of win-version and hyper-v settings.
Unfortunately, I celebrated too early (again). Last night everything was running OK when I suspended my laptop (without first suspending the VM). This morning I resumed, the VM seemed to run OK but then became really sluggish until at completely froze again. The 'old trick' of suspending and resuming the VM to get it to work again does not work this time: VMWare Workstation fails to resume the VM.
I'm hoping this is just because I suspended my laptop, so I've just relaunched the VM and will keep it running all day today.
FYI, I don't see any (obvious) error messages from:
VMWare log file contains the following at the time the VM becomes completely unresponsive:
😪😪😪
Nope, froze after only 23 minutes with the dreaded: