I've set the preferences file to r/w, saved the VM, and closed the ui. It overwrote the file and it did set pref.ws.session.window.count = "0" (it was "1" when the ui was first opened this evening). ui log attached.
I've also attached the dnf update transaction that (I suspect) influenced this. Many new KDE framework components...
I've failed to reproduce this in another fully patched Fedora 43 KDE installation. The host with the fault does have four display panels, if that matters...
-------------------------------------------
Original Message:
Sent: Mar 02, 2026 02:36 PM
From: James Lin
Subject: VMware Workstation for Linux 25H2u1-25219725 is out...
We haven't changed anything with regard to those window session preferences in a very long time (and certainly not between Workstation 25H2 and 25H2u1), so it's very weird that you're seeing that. (I've never encountered it and can't reproduce it.) It looks like your UI log is from starting a new UI instance after pref.ws.session.window.count = "0" was already written, but it'd be more useful to provide a UI log from after you quit the UI when it wrote that incorrect entry.
Original Message:
Sent: Mar 02, 2026 03:06 AM
From: richard612
Subject: VMware Workstation for Linux 25H2u1-25219725 is out...
New bug maybe? The last round of Linux updates (installed today) did include a bunch of new KDE Plasma components...
My installation has begun to write pref.ws.session.window.count = "0" to ~/.vmware/preferences. Which is a problem because it then deletes preferences including pref.ws.session.window0.<prefname>. Apparently when window count = zero all those saved prefs fall out of scope and are therefore subject to removal?
Workaround is to chmod 400 the preferences file after restoring missing entries and also set the window count to "1".
vmware-app and vmware-ui logs attached.
Original Message:
Sent: Feb 26, 2026 07:14 AM
From: richard612
Subject: VMware Workstation for Linux 25H2u1-25219725 is out...
Appears to be fixed:
- Keypress lag in Windows guests. I've backed out all my .vmx hacks and everything seems fine.
Appears to be not fixed:
- Keypress lag in Linux guests when 3D acceleration is enabled. Best workaround hacks I've found are
mks.svgaThread.forcePolling = "TRUE" plus mks.svgaThread.pollUS = "250". Some report success with keyboard.vusb.enable = "TRUE" but this may cause the guest to ignore media keys (vol up/down/mute). (guest type set to fedora-64) - Extra mouse buttons inop. in Linux guests. Best workaround hack I've found is
mouse.vusb.enable = "TRUE" along with ensuring the guest has a virtual USB controller. (guest type set to fedora-64) - Cut-and-paste flakiness on a Wayland host same as before. Best hack I know is to cut/copy then immediately click the VMware Workstation titlebar to [hopefully] kick the clipboard hamsters into gear. Applies to all guest OS types.
Possible new problem [maybe]:
- Heavy guest writes to a virtual NVMe disk seem to become "stuck" for 10-15 seconds at a time. Noticed on a Fedora guest during
dnf update -- the second install phase would run for ~five seconds then the whole VM would freeze for a while. This cycle repeated until dnf was finished. I rolled the VM back to the most recent snapshot, shut it down, changed the controller type to pvscsi, then re-randnf update. All was well after that. Nothing in the system journal, nothing indmesg, nor anything noteworthy in vmware.log nor mksSandbox.log. - I'm trying to reproduce the above with
fio now. - Related to the above, tried CrystalDiskMark on a Windows VM with an NVMe virtual disk. Set to a 1G test size the Seq1M write test never finishes. It just.... hangs. Unlike the Linux guest, Windows acts like nothing's wrong. No errors/warnings in the Event Log. Once this occurs Windows will be unable to shut down (it'll hang with the spinning circle indefinitely).
-------------------------------------------