VMware fast for first user, sluggish for second

After launching VMware and opening the virtual machine prepared by another user, Windows 7 runs very slowly. File read/write is 10-30x slower than it should be and Windows has started to animate window move/resize, which brings the OS (or VMware?) to its knees.

How do I go about debugging the problem?

Clarification The two users are two accounts on the very same MacBook. The two users share the same OSX, and so it seems reasonable for them to also share the same Windows VM.

Update After yet another fresh installation of VMware + Windows 7, this time installed and used exclusively by one user, the same sluggishness is starting. There are a few suspicions.

Mds is going berzerk, for instance. Could it be that it is indexing (and interfering somehow) with the separate partition on which the windows VM is installed?

The sluggishness starts after a little use: the unzipping of my code and a few debugging cycles under windows. Could my going along with VMware's default of making the disk usage grow as needed be contributing to some fragmentation so early on? VMware, as I now see, suggest using the non-default (allocate disk storage from the first moment of install) for production use. (What other use is there? And how could the non-production use be the default?)

Solution 1:

Read VMware support article 1015676 to learn about the things that could be causing slowdowns and what you can do about them.

As standard practice, I change some memory management settings as I explain in this answer to another VMware performance question.

Things to check in particular, given "mds going berzerk":

• Exclude your VMs from Time Machine Backups
• Disable Spotlight indexing on your FAT32 drive (if it's not already disabled), or at least for the folder you have your VMs in (by adding the folder to the System Preferences -> Spotlight -> Privacy tab).

With regard to pre-allocating disk space, whether or not that is a performance penalty or not or how big an impact it has on you completely depends on your disk usage pattern. It is a performance hit to expand the size of the drive. If you rarely delete stuff from the disk but often add stuff (especially if you are running programs that are generating files, e.g. log files or transcoded media files) then you will suffer the most. If you download big files, use them, and then delete them, you'll probably end up with enough allocated free space to not notice the difference.

You can also experiment with:

• Enable hard drive buffering. This was critical for me when my VM was on a RAID 5 array, but otherwise didn't matter. VM settings -> Advanced, set "Hard drive buffering" to "Enabled"
• Enable/Disable Windows Pagefile. For a real computer the best advice is to leave the pagefile active and system managed under Windows 7 (as opposed to XP, where it is probably better to remove it if you have enough RAM). For a VM using a virtual disk it is not as clear cut, but easy enough to test. Follow these directions to get to the page file settings but instead of choosing a size, select "No paging file".

Solution 2:

How do I go about debugging the problem?

Passing VM images around is tricky business. The image is often created with hypervisor extensions that take advantage of specific hardware features on the machine where the VM was created. If you're not using precisely the same hardware (especially the same CPU) the VM can run slowly or even crash your host OS or lock up your CPU.

I'd start with getting the VM back to an initial state:

1. Delete all the snapshots in the VM
2. Power down the guest OS so it's "off", not just suspended
3. Bring up the Virtual Machine Library window (Shift+Cmd+L) and select the VM
4. Click the Wrench icon in the toolbar to bring up the settings window for this VM
5. Select 'Advanced' and make sure the preferred virtualization engine is set to 'Automatic' and that hard disk buffering is also set to 'Automatic'
6. Click 'Show All' to return to the main settings
7. Click 'Compatibility' and make sure the VM's compatibility is set to be with the version of VMWare you're running or higher (in my case that's Fusion 4 or higher) so you don't need legacy VM capabilities maintained
8. Click 'Show All' and return to the main settings
9. Click 'Display' and make sure 3D graphic acceleration is on. If it cannot be turned on this is a pretty good hint that the VM was created with another chipset and really isn't compatible with your machine.
10. Click 'Show All' and return to the main settings
11. Click 'General' and then press the 'Clean Up Virtual Machine' button. This will get rid of all the extra cruft from snapshots and get you back to a nice clean VM image state.
12. Click 'Show All' and return to the main settings
13. Click 'Processors & RAM' and set these to suit your needs. You need at least 1 processor, but if you have a multi-core machine you could set this higher. Ideally you wouldn't ever set the number of processors in the VM to any more than Physical Cores in the Machine - 1. That way your physical machine always has one core to itself. RAM should be set to at least the recommended value. If you have a lot of RAM in the machine you can increase this but don't go too crazy with it.
14. Now power up the VM and do a re-install of the VMWare Tool (Virtual Machine -> Reinstall VMWare Tools...).

Other things to consider:

• The VM should be on fast disk. This usually means your primary drive in your machine. If it's on a USB-attached disk or a network attached drive performance will suffer.
• You can't both use the VM image at the same time. I say this in case you have it on a shared drive and you're both trying to run it at the same time. You have to make your own, unique copies of the image.
• Check the Task Manager in the VM to see what's running. Maybe you have a process or two that's going off the rails and eating up all the VM CPU. If that's the case you're in to a straight why-is-this-process-misbehaving-in-Windows type question and you'd need to take it to http://superuser.com I suspect.

If this doesn't get the VM in to a useable state it's likely that your hardware and the hardware the VM was created on are too far apart in compatibility for you to pass the VM around.