VMplayer: Silencing excessive hard disk activity + getting rid of freezes
The disk is hammering
For some unknown reason, possibly after an VMplayer upgrade, running any Windows Virtual machine on my Linux machine with WMware Player caused some non-stop heavy hard disk activity, even when the guest machine was effectively idle, and made had no I/O activity of its own.
Except for being surprisingly annoying, it also made the mouse pointer non-responsive and the effect was adverse on the hosting machine as well.
So eventually I managed to get things normal by editing the virtual machine’s .vmx file as described below.
I have Vmplayer 6.0.2 on Fedora 12 (suppose both are considered quite old).
Following this post, add
isolation.tools.unity.disable = "TRUE" unity.allowCompositingInGuest = "FALSE" unity.enableLaunchMenu = "FALSE" unity.showBadges = "FALSE" unity.showBorders = "FALSE" unity.wasCapable = "FALSE"
(unity.wasCapable was already in the file, so remove it first)
That appeared to help somewhat. But what really gave the punch was also adding
MemTrimRate = "0" sched.mem.pshare.enable = "FALSE" MemAllowAutoScaleDown = "FALSE"
Don’t ask me what it means. Your guess is as good as mine.
The Linux desktop freezes
Freezes = Cinnamon’s clock stops advancing for a minute or so. Apparently, it’s the graphics that doesn’t update for about 1.5 second for each time that the mouse pointer goes on or off the area belonging to the guest’s display. But it accumulates, so moving the mouse all over the place trying to figure out what’s going on easily turns this freeze out to a whole minute.
Just turn off the display’s hardware acceleration. That is, enter the virtual machine settings the GUI menus, pick the display, and uncheck “Accelerate 3D graphics”. Bliss.
Nope, it didn’t help. :(
November 2023 update: Could this be related to keyboard mapping? I had a similar issue when playing with xmodmap.
Also tried to turn off the usage of OpenGL with
mks.noGL = "FALSE"
and indeed there was nothing OpenGL related in the log file (vmware.log), but the problem remained.
This command was taken from a list of undocumented parameters (there also this one).
Upgrading to VMPlayer 15.5.6 didn’t help. Neither did adding vmmouse.present = “FALSE”.
But after the upgrade, my Windows XP got horribly slow, and it seems like it had problems accessing the disk as well (upgrading is always a good idea, as we all know). Programs didn’t seem to launch properly and such. I may have worked that around by setting the VM”s type to “Other” (i.e. not something Windows related). That turns VMTools off, and maybe that’s actually a good idea.
The solution I eventually adopted was to use VMPlayer as a VNC server. So I ignore the emulated display window that is opened directly by VMPlayer, and connect to it with a VNC viewer on the local machine instead. Rather odd, but works. The only annoying that Alt-Tab and Alt-Shift keystrokes etc. aren’t captured by the guest. To set this up, go to the virtual machine settings > Options > VNC Connections and set to enabled. If the port number is set to 5901 (i.e. 5900 with an offset of 1), the connection is done with
$ vncviewer :1 &
(or pick your other favorite viewer).
The computer is a slug
On a newer machine, with 64 GiB RAM and a more recent version of VMPlayer, it took a few seconds to go back and forth from the VMPlayer window to anything else. The fix, as root is:
# echo never > /sys/kernel/mm/transparent_hugepage/defrag # echo never > /sys/kernel/mm/transparent_hugepage/enabled
taken from here. There’s still some slight freezes when working on a window that overlaps the VMPlayer window (and other kinds of backs and forths with VMPlayer), but it’s significantly better this way.