I've been having an intermittent issue with my Linux guest VMs, after using them for a while they stop accepting keyboard and mouse input completely. The VMs are continuing to run, the system clock progresses as normal, but I cannot interact with the VM at all, even the Ctrl-Alt-Del button isn't passed to the guest. The VM still reacts to having the Workstation window resized.
I've only had this issue with Linux guest VMs so far, I've tried multiple distributions and window managers and display managers as well as X11 and Wayland.
I've compared the logs of multiple VMs when this has happened and there are no common errors, suspending and resuming the VM doesn't help, only restarting the VM allows me to resume control.
Specs are as follows:
- Windows 11 22H2 (OS Build 22621.2428)
- VMWare Workstation 17 Pro (17.5.0 build-22583795)
- CPU: Intel i7-1365U
Does anyone know what could be causing this?
I'll upload some logs when I next observe this activity, are there any additional logs I can collect other than vmware.log?
Nope, not CPU related. I have exactly the same issue. It started with update to VMWare Workstation Pro 17.5.
My specs:
AMD Ryzen 7 5800X
Host: Windows 11
Guest: Linux Mint 21.2
There are multiple threads with the same issue.
No, you're definitely not alone.
Hmmm.. 13th gen Intel processor. Windows does a crappy job of trying to schedule threads to run on P-cores vs E-cores.
Have you tried to disable Windows setting the power throttling on the vmx executable:
From a command prompt run as Administrator:
powercfg /powerthrottling disable /path "C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe"
The path may be different on your system, so you might have to search around to find the right location for the vmware-vmx.exe file.
Nope, not CPU related. I have exactly the same issue. It started with update to VMWare Workstation Pro 17.5.
My specs:
AMD Ryzen 7 5800X
Host: Windows 11
Guest: Linux Mint 21.2
Really encouraging to hear I'm not the only one having this issue, I've been troubleshooting and searching for weeks. Hopefully we can both provide enough information to get this issue fixed.
I may try rolling back to an older version of Workstation is possible and see if the problem persists, even if it's a temporary workaround it'll allow me to work at least.
There are multiple threads with the same issue.
No, you're definitely not alone.
Having the same issue here as well where eventually a Linux guest will just stop taking mouse & keyboard input.
I've also tried changing between different Linux distributions (including making fresh new ones) and reinstalling VMWare Workstation 17 Pro (17.5.0 build-22583795) and it still persists. Turning off Memory Integrity protection & "bcdedit /set hypervisorlaunchtype off" also did not resolve the issue.
YES! THIS!
I was trying to write an exam the other day that required me to use Linux in my VM. This happened to me about 6-7 times resulting in me having to reboot the VM and have to set up the exam over and over again.
Everything continues to run in the background on the VM. I can see the Network activity and CPU activity continue, but the mouse and keyboard stop working. Trying to switch to another TTY doesn't work, and I can't send ctrl + alt + delete either.
I was also running on Windows 11 on VMWare 17.5. CPU is a Ryzen 7 5800X, so it's not a CPU architecture issue.
The issue seems to be caused by Workstation 17.5, rollback to the previous version. I'm still getting some intermittent issues with keystrokes repeating and some awful performance issues.
@GenBison Ticket has been raised internally. Relevant team will look into the same.
Two things people can try:
(1) Power off the VM, and add the config option:
keyboard.allowBothIRQs = FALSE
This might cause your Linux VM's input to hang if the Guest tries to Sleep/Hibernate, but it may work-around the problem.
(2) Power off the VM and make sure the VM has a USB controller, and add this config option to switch to the virtual USB keyboard:
keyboard.vusb.enable = TRUE
That will switch from using the PS/2 keyboard to the USB keyboard, but may make your key-repeat get stuck more often.
I think (1) should be sufficient to fix this, but if not try (2) as well.
I've been able to consistently replicate the issue. Let me try these and I'll let you know what works.
So I can reproduce the issue by holding down an arrow key and clicking the mouse on the host desktop. This forces the issue to occur.
After testing, I can confirm that adding this line: keyboard.allowBothIRQs = "FALSE" to the VMX file fixes the issue.
I then removed that and added keyboard.vusb.enable = TRUE and this also seemed to fix the issue.
Based on my scenario both fix the issue. Not sure which is the better one to use.
If keyboard.allowBothIRQs = FALSE works, that's a much better tested path than the virtual USB keyboard.
I was having the same problem, and it was really repeatable. The keyboard.allowBothIRQs = FALSE option did stop the problem from occuring, but interestingly enough this is the error message from /var/log/syslog in the guest that was generated when it started ignoring input.
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE)
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) Backtrace:
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 0: /usr/bin/Xwayland (0x55c1e2cdf000+0x1651c9) [0x55c1e2e441c9]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 1: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x2fd612) [0x7f1b0a8fd612]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 2: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x14f74d) [0x7f1b0a74f74d]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 3: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x1615fb) [0x7f1b0a7615fb]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x13468f) [0x7f1b0a73468f]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x1380c9) [0x7f1b0a7380c9]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so (0x7f1b0a600000+0x13e899) [0x7f1b0a73e899]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 7: /usr/bin/Xwayland (0x55c1e2cdf000+0x657b3) [0x55c1e2d447b3]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 8: /usr/bin/Xwayland (0x55c1e2cdf000+0x54930) [0x55c1e2d33930]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 9: /usr/bin/Xwayland (0x55c1e2cdf000+0x550ad) [0x55c1e2d340ad]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 10: /usr/bin/Xwayland (0x55c1e2cdf000+0x19ea3c) [0x55c1e2e7da3c]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 11: /usr/bin/Xwayland (0x55c1e2cdf000+0x19f14e) [0x55c1e2e7e14e]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 12: /usr/bin/Xwayland (0x55c1e2cdf000+0x4f406) [0x55c1e2d2e406]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 13: /usr/bin/Xwayland (0x55c1e2cdf000+0xef2c6) [0x55c1e2dce2c6]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 14: /usr/bin/Xwayland (0x55c1e2cdf000+0x109bfb) [0x55c1e2de8bfb]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 15: /usr/bin/Xwayland (0x55c1e2cdf000+0xa714e) [0x55c1e2d8614e]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 16: /usr/bin/Xwayland (0x55c1e2cdf000+0x34c63) [0x55c1e2d13c63]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (0x7f1b18000000+0x29d90) [0x7f1b18029d90]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x80) [0x7f1b18029e40]
Nov 21 12:39:31 micah-vm1 gnome-shell[2435]: (EE) 19: /usr/bin/Xwayland (0x55c1e2cdf000+0x36495) [0x55c1e2d15495]
@GenBison Please upgrade to the latest Workstation version 17.5.1 as this issue has been fixed in this release.