VMware Fusion performance degrading after few hours

I've been having an issue with VMware Fusion for some time now, where the VM (running Windows) runs fine initially, but will slow down to a grind after some time (best guess is a couple of hours). It's so slow that there's even a delay when typing.

The issue is not restricted to one VM: I have multiple Windows 7 VMs showing the same problem.

Any hints would be greatly appreciated in locating the source of this issue. Below are the configuration details and what I've attempted so far.

Configuration:

  • OS X 10.9.2
  • VMware Fusion 6.0.2
  • MacBook Pro (Mid 2012) Intel Core i7 2.3Ghz, 8GB RAM, Apple SSD
  • VM running Windows 7, 8 cores, 4GB RAM, SATA disk (not preallocated)
  • VM network: bridged

Changes (optimisations) performed so far

Windows (Guest):

  • Disabled all non-essential Windows services (e.g. Windows Search, Media, …)
  • Disabled NTFS access time modification
  • Disabled 8.3 filenames
  • Disabled Aero
  • Configured performance setting to Best performance

Mac (Host):

  • Disabled energy saving
  • Disabled automatic switching of display adapter

VMware:

  • Moved the VM from external USB3 disk to internal SSD
  • VM compatibility set to VMware 6 (latest available)
  • Upgraded VM HD controller from SCSI or IDE to SATA
  • Set VM hard disk buffering to enabled
  • Disabled Troubleshooting (set to None)
  • Removed the appleListCache folder and replaced it with a dummy file

Update:

I created a support request with VMware to get to the bottom of this, and have received these two additional actions to try:

  • Reinstall the VMware tools
  • Exclude VMware from the AppNap feature in OSX by performing the following steps:

    1. Shutdown all Virtual Machines and quit Vmware Fusion.
    2. Go to Applications Folder and right click on VMware Fusion
    3. Select Get Info
    4. Select the option Prevent App Nap.
    5. Startup the Virtual Machine and recheck the issue.

Update 2:

In addition to the action above, VMware Support asked me to do the following:

  • Lower the number of CPU cores assigned to the VM — My MacBook Pro has 8 cores, of which VMware suggested only assigning 2 to a VM.
  • Lower the RAM assigned to the VM — I always assigned as much RAM as possible, leaving just enough for OSX. VMware suggested lowering this to 2GB.
  • Disable the shared folder feature — I normally share a few folders between the host and guest OS for easy file exchange.

While I didn't expect these changes to make any difference (esp. lowering the resources assigned to the guest OS), the VM's I've tried so far have all run stable and without any real hiccups, even when run from the USB3 external WD disk.


Solution 1:

I have same problem, but these solutions was not fixed my issues. However I have found a blog post from artykul8, what fixed fixed all of my issues!

http://artykul8.com/2012/06/vmware-performance-enhancing/


Tweak: Disable memory swap files .vmem files

mainMem.useNamedFile = "FALSE"

Unfortunately this parameter does not work for VMware Player, as it always creates virtual machine’s full memory swap file. For VMware Fusion on Mac and Linux instead of mainMem.useNamedFile you have to set mainMem.backing flag.

mainMem.backing = "swap"

Tweak: Choose the right disk controller and specify SSD

Instead of the latest SATA AHCI controller choose LSI Logic SAS controller with SCSI disk for Windows guest OS, or PVSCSI for other types of OS. Unfortunately SATA AHCI on VMware has the lowest performance out of the three controllers and highest CPU overhead (see the references on the topic at the end). In addition to choosing the right controller, if your host disk is SSD you can explicitly specify the disk type as SSD to guest OS.

scsi0:0.virtualSSD = 1

Tweak: Disable log files for VM

logging = "FALSE"

Alternatively you can specify a different location to store the log file, if you ever need them:

log.filename = "c:\Windows\Temp\vm1.log"

Tweak: Other Disk & Memory I/O Performance Optimization

Disable memory trimming:

MemTrimRate = "0"

Disable page sharing:

sched.mem.pshare.enable = "FALSE"

Disable scale down of memory allocation:

MemAllowAutoScaleDown = "FALSE"

Tweak: Disabling Snapshots

Disable snapshots if you are not using them and prefer full backups:

snapshot.disabled = "TRUE"

Tweak: Disable Unity Mode

Unity might be a great feature for running virtual desktops operating systems, but it is not the most useful for virtualizing server OS. An annoying sign of enabled unity is GuestAppsCache or caches folder with a large number of files and subfolders. In order to disable it for your VM add the following lines:

isolation.tools.unity.disable = "TRUE"
unity.allowCompositingInGuest = "FALSE"
unity.enableLaunchMenu = "FALSE"
unity.showBadges = "FALSE"
unity.showBorders = "FALSE"
unity.wasCapable = "FALSE"

Solution 2:

I had quite the same issue with my VM guests. (Also in VMWare 5.x on 10.8 by the way). What solved this issue for me was to disable the VM hard disk buffering. This seems to take all the available RAM of the system to buffer disk data (you can monitor this in activity monitor too). But giving back the RAM when needed by other system resources seems not to be one of the strong abilities of VMWare.

Since I disabled this I had no more issues with slowing down VM guests.

Solution 3:

I've had similar problems with my setup running OS X 10.10.2 and before I upgraded OS X to.

What I found was that when I changed display settings in OS X to use the "Default for display" Resolution. I then unticked in VMware the "Automatically adjust user interface size in Windows" and ticked "Use full resolution for Retina display" this does how ever give my windows interface a resolution of 2560 x 1600 witch is very small on 13" screen. But no problem med slugish behaviour anymore.

It is the same behaviour for both Windows 7 Pro and Windows 8.1 Ent

After that I used a external screen with lid closed and external keyboard and mouse and that works like a charm.

Don't know if this help you home in but maybe your problem to is related to the screen.