I run Linux as my desktop OS at work, but there are some times when I need to use Windows. I was using KVM, but I had enough problems with it that I gave up and tried using VMware instead. I was pleasantly surprised to see that VMware Player now supports installing my own OS, not just playing existing images.

However, I quickly discovered that performance was miserable with it. My hard drive was constantly grinding away, and my host OS iowait would hover around 15% and frequently be much higher, at least as much as 50%. After some searching about, I discovered that, for some inexplicable reason, VMware keeps an mmap()'d disk-based backing store of the guest machine's RAM, and keeps it as an unlinked file in /tmp. Since RAM changes pretty frequently, it's constantly slamming my hard drive trying to write RAM data in near-real-time. I also discovered that there's no way to turn this backing store off.

I've also found that VMware Workstation, at least the 30-day trial, has the exact same symptom.

Does anyone have any ideas about how to fix this absurd brokenness of VMware, or should I just try something else instead? I've generally been pretty pleased with VMware in the past, but this one has my confidence very severely swayed.

Workstation doesn't do that on my systems. I wonder what config option is misdialed on yours ?

.

I run VMware Server on a Fedora 10 based machine and compared to another machine running VMware Server on Win 7 x64, performance (at least as in user responsiveness in Windows guests) is significantly worse under Fedora 10 I've found. I have played with a few performance settings without much luck.

Yeah, that setting doesn't make any performance difference. It wires the guest's memory, so the host OS doesn't swap it out, but VMware still writes its own backing store. Some people are suggesting that you can move that backing store to be in /dev/shm, but I'm concerned that that will cause double memory usage. I guess I can try it out.

It is ridiculous that it has this backing store at all.

Are you sure about that? Look at the VMware processes' file descriptors.

Oh, you mean this (hidden) file:

lrwx------ 1 root root 64 2010-05-06 15:43 128 -> /tmp/vmware-root/ram0 (deleted)

They've created/opened it, then unlinked it so that it is 100% invisible, apart from /proc/xxx/fd/*

I wonder what they're using it for?

I'm in the same situation, though at the moment, "sometimes" has been 90% of my time. I've been running a Windows 7 VM on a KUbuntu host, and haven't really noticed significant problems in terms of performance, but that may be due to my hardware specs (8Gb RAM, quad core i5 @ 2.67 GHz, software raided disks). Every now and then, I'll get some heavy disk i/o, but it's not frequent enough to seriously impact performance.

You might want to give VirtualBox a try. I gave it a whirl earlier, but went back to VMWare because that's what everyone else in the office was using, and there were already a number of virtual machines set up with it.

The thing that pisses me off most about the VMWare stuff is that it's killed both the alt-tabbing, and my MMB-copy/RMB-paste on the host.

I was actually trying that, and thought that it wouldn't load the VM i had built, but it turns out I had corrupted it somehow, as VMware won't load it any more, either. Yay.

At any rate, I made some changes and it seems to have resolved my problems. I changed my BIOS to present my (single) SATA hard drive as AHCI instead of as a RAID set, I moved the RAM backing store to /dev/shm, which seems not to have doubled RAM usage, I disabled an unused SATA port in the BIOS, and I added the pci=nomsi flag to my kernel boot options.

I know, I should have done one thing at a time, but I'm tired of arguing with it.