VMware® Workstation 17 Pro, Linux VMs keyboard lag

[Rtaylor]

The issue is: "Linux VMs that have more than 1 CPU experience terrible keyboard lag when run on a Windows 11 host".

VMware® Workstation 17 Pro, version 17.0.1 build-21139696

Host is Windows 11 Pro, Version 22H2, OS Build 22621.1555 (fully patched)

I have done extensive testing on this on Windows 11 hosts that have Nvida RTX 2080 Ti video cards, and on hosts that only have built-in Intel video cards. Same issue, entirely different PCs.

Windows 10 fully patched hosts do not experience this issue as yet with the very same Linux VMs.

Reducing the Linux VM to 1 CPU fixes the issue.

Tested with several versions of Kali Linux in the VM from 2019 to the latest fully patched Kali: Linux OffSec 6.1.0-kali7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1kali1 (2023-03-22) x86_64 GNU/Linux

ii open-vm-tools 2:12.2.0-1 amd64 Open VMware Tools for virtual machines hosted on VMware (CLI)
ii open-vm-tools-desktop 2:12.2.0-1 amd64 Open VMware Tools for virtual machines hosted on VMware (GUI)

Jiggling the mouse while typing in the Linux VM makes the keyboard lag go away.

The issue started right about the same time that a Windows 11 patch caused a Windows 10 VM to bluescreen when it was configured with more than 1 CPU. The solution for that Windows VM bluescreen was to upgrade to VMWare 17.

Disabling Accelerate 3D graphics makes no difference.

Turning off Share Bluetooth devices with the virtual machine makes no difference.

Reducing the Linux VMs to 1 CPU fixes the issue completely, though this is not a solution that resolves my needs.

Running GLX gears in the Linux VM in the foreground while typing seems to help but good luck keeping it in the foreground. Not to mention it uses significant CPU which you probably have better uses for.

Running VMWare Workstation Pro 17 on a Linux host and then running the same Linux VMs on that host fixes the keyboard lag, but there are other issues with this configuration. Namely copy paste of files between the VMs and the host rarely works, and it is impossible to get the sound to work without terrible static, lag and cutting out, in a teams session that is running in a Windows VM running on the Linux host. Connecting a USB headset directly to the Windows VM that is running on a Linux Host did not fix the teams sound issues.

I suppose I could wipe everything and go back to using Windows 10 as the host OS on the PCs where this is possible, but I imagine Windows 10 will be end of life at some point.

I need this fixed asap.

Thanks.

[jwunsch]

Hello,

I have similar issues with 17.0.1. I downgraded to original 17.0 by deleting whole Workstation and re-installing it.

There are a few cases where I have huge keyboard input lag on 17.0, but there is a work-around which makes VM linux running GUI usable-ish.

Hardware: Lenovo T16, Core i7-1260P (P and E cores), 48GB ram.

HostOS: Wintendo 11 enterprise

GuestOS: Kubuntu 22 LTS
Tried kernels:
- Ubuntu provided 5.19.0.40.41

- 6.2.11  (currently running) Unsigned kernel via mainline kernel tool

Guest OS has 4 vCPUs and 28 GB of RAM configured, 3 disks, bluetooth, usb etc devices, several network adapters etc.

Absolutely minimum tuning to get this working without input lag and replay of "stuck" keys.

1) Do not allow VMWare Workstation to swap any of the virtual machine memory, if you allow --> Insane lag.

2) Do not allow use any of the SMT virtual cores, if you allow --> insane lag.

On this particular laptop, force use of Nvidia MX550 dGPU, as the intel iris xe iGPU has some driver/hardware issue and is constantly running on 50-70% load. MX550 is running between 1-30%. 3d acceleration on 2 dispalys on vm quest and 2GB VRAM.

How to do it:

1) Stop VM

2) Disable swapping from quest.
    Edit -> Preferences -> Memory -> Fit all virtual machine memory into reserved host RAM

3) Set CPU affinities
So my vm is named "Kubuntu22_LTS". So browse under your vm and look for <vmname.vmx> and edit it.

So for this alderlake i7 1260P we have 4 Performance cores (with SMT) and 8 E cores.

This means that cores 0,2,4 and 6 are the physical P cores and 1,3,5,7 are its SMT logical cores. And 8-15 are those E cores.

So we allow use of 0,2,4 and 6. All other are set to FALSE.

Processor0.use = "TRUE"
Processor1.use = "FALSE"
Processor2.use = "TRUE"
Processor3.use = "FALSE"
Processor4.use = "TRUE"
Processor5.use = "FALSE"
Processor6.use = "TRUE"
Processor7.use = "FALSE"
Processor8.use = "FALSE"
Processor9.use = "FALSE"
Processor10.use = "FALSE"
Processor11.use = "FALSE"
Processor12.use = "FALSE"
Processor13.use = "FALSE"
Processor14.use = "FALSE"
Processor15.use = "FALSE"

4) Start VM

 
NOTE: I have not tested if the input lag exists when allowing use of E-cores (they do not have SMT), but for some extremely stupid reason Wintendo/VMWAre will assign ALL work on E-cores and that's horrible slow.

NOTE2: If any SMT logical core is allowed to be used, input lag is horrible. And sometimes even typed text gets removed without pressing backspace / delete.

-- EDIT  --

I have also set priority to "High" when vm window is active.

VM ->  Settings -> Option s -> Advanced -> Process priotities: "input grabbed" : High

[klaw24]

I have the same exact problem with an ideapad 5 pro (i5- 13500H, 32gb RAM, NVIDIA RTX3050) and windows 11 pro (22H2).

I have tried all the suggested ideas on how to fix it and apparently the only one working is if I set only 1 CPU and 1 core. But then, it works really slow... 

Why are we having these issues?

[aiv00]

I've had the same issue and have tried many of the fixes from the following thread.

https://communities.vmware.com/t5/VMware-Workstation-Pro/Noticeable-typing-lag-in-Linux-VM-terminals...

I was chasing up any leads I could think of for this and long story short, I came across this article:

https://www.makeuseof.com/windows-11-disable-vbs/

I tried it and I don't seem to be having any issues any more. I haven't seen any mention of VBS as a possible culprit to the problem. So could the issue be due to Windows 11 new Virtualization-Based Security?

While I may have been able to remedy my situation. It doesn't seem to me to be the ideal solution as I use my Kali vm for CTFs which are typically considered to be hostile environments. The extra security that VBS supposedly provides seems desirable in my situation.

Perhaps someone smarter than I could try to replicate my "fix" to validate the suggestion.

[cyberWhiz_dev07]

This issue makes this version basically unreliable to use.

[klaw24]

It's interesting enough because, in the meantime I have returned my previous laptop (a lenovo ideapad5 pro), and bought an asus vivobook. The issue was only present on lenovo laptop.

Interesting also, I have tested the vm on a dell xps laptop. The lag was there. 

Might be something related to host os? 

[cyberWhiz_dev07]

I actually downgraded to v16.1.2 because to me it's unworkable.

[johnsrz]

I have a Lenovo laptop as well, with windows 11. I have been able to get rid of the issue by connecting an external keyboard using "Removable Devices". The input lag/keyboard lag while typining dissapears if I connect an external keyboard to my laptop and use the external one.

That makes the external keyboard unusable to the host machine, unless you remove it using the "Removable Devices" option. And even if you use the external keyboard while it's connected, the built-in one still has the delay.

If you try to connect an external keyboard without using the "Removable Devices" option, just plugging it directly on the USB port, you will experience input delay with the external keyboard as well. At least, it is my case.

However, I'm on a laptop, can't bring my external keyboard outside. And must of the time I just wanna use the built-in one.

But that's the only fix that has worked for me. I TRIED a bunch of stuff, a nothing works, only that. It's getting annoying.

This doesn't happen to me on the Windows virtual machines, only Linux. I don't know why.

[darkmoon0039]

You could try Virtual Machine Settings > Processors > Virtualization engine > Virtualize  IOMMU.

It resolved my keyboard lag issue.

[johnsrz]

Thank you so much, this actually solved my issue. I need to investigate why thought. Thank you!

[bp787]

unfortunately, this only made it moderately tolerable for me...  

[banksiaboy]

What _seemed_ to make a difference for me was to change the CPU mapping of threads to cores to be the same as the host. I have an olde  Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz.  I changed my CPU settings from 4 cores, to 2 cores with 2 threads each.

I have all the virtualisation settings on. Plenty of memory, no 3d acceleration.
Running a Debian 13 freshly installed guest. Workstation 17 on Ubuntu 22.04.3 LTS host.

[banksiaboy]

Nope - back again 😂

[cynar]

I have been trialling turning on "Virtualize IOMMU (IO memory management unit)" as a completely isolated change for a few hours.

It does seem as if enabling "Virtualize IOMMU (IO memory management unit)" addresses the unacceptable keyboard behaviour of VMware Workstation 17 Pro, running on a Windows 11 Pro host, with Fedora Linux 38 inside (on Linux kernel 6.4.13), on the KDE Desktop, with "accelerated key repeat" configuration in KDE.

The host hardware is a Dell Inspiron 7610 notebook, with a Tiger Lake 11800H CPU (i.e. no big.LITTLE / performance+efficiency CPU core split), a hybrid Intel+NVIDIA GPU setup, 64 GB RAM. The VMs get 16 cores + 32 GB + max VRAM + 3D acceleration.

With this, I have been able to run VMware Workstation 17 on the Microsoft Windows hypervisor stack ("bcdedit /set hypervisorlaunchtype auto") with tolerable UI performance for the first time ever; I could run VMware Workstation 17 with WSL2 in parallel and not be totally put off by VMware Workstation. Interactive performance of VMware Workstation 17 in this specific mode still is noticeably worse compared to running it at CPL0 ("bcdedit /set hypervisorlaunchtype off"), but it is useable for the first time ever, with KDE.

[marshelper]

Turning on Virtual IOMMU (IO memory management) did the trick for me

[twkonefal]

I was running 4 processors with 1 core each. Now I'm at 2 processors with 2 cores per processor and the stuttering is a little better, but it's still there.

[vmwareuser11321]

Got the same issue. Looking at the log file, I see thousands of entries like these:

2023-09-29T13:09:15.244Z In(05) vcpu-0 VIDE: (0x170) Unexpected IN for cmd 0xa3 len 2
2023-09-29T13:09:15.244Z In(05) vcpu-0 VIDE: (0x170) Unexpected IN for cmd 0xa3 len 2
2023-09-29T13:09:15.244Z In(05) vcpu-0 VIDE: (0x170) Unexpected IN for cmd 0xa3 len 2
2023-09-29T13:09:15.244Z In(05) vcpu-0 VIDE: (0x170) Unexpected IN for cmd 0xa3 len 2

Does anyone else also have these entries?

[vmwareuser11321]

Was able to fix this, seems to be related to this: https://bbs.archlinux.org/viewtopic.php?id=288723

My workaround: check SATA instead of IDE in CD/DVD > Advanced

[twkonefal]

1. ---

   @vmwareuser11321 wrote:
   

   Was able to fix this, seems to be related to this: https://bbs.archlinux.org/viewtopic.php?id=288723

   My workaround: check SATA instead of IDE in CD/DVD > Advanced

   

   ---

   
   Amazing. I just removed the CD/DVD device from the VM and the stuttering has disappeared.

[iPaq]

Likely related to a recent kernel bug involving the scsi driver's behavior with the VMware IDE CDROM device https://lore.kernel.org/linux-scsi/20230915022034.678121-1-dlemoal@kernel.org/

Valid solutions I’ve confirmed:

1. Shutting down and X’ing the CDROM drive in VMware before starting the guest up again

2. Running rmmod -f ata_piix to unload the driver for Intel PIIX/ICH ATA controllers. This is quick, instant and suitable for the stock VMware virtual IDE CDROM drive which is an IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE PCI device. Only a good idea if you aren't presenting your guest's virtual disks over IDE for some reason.

3. Downgrading the kernel to the previously known working version for now or installing and using linux-lts if need-be. Or applying the linked patch and re-building a new kernel.