Fusion - speed of disk I/O

[bceverly]

Hello everyone.

I'm struggling (and have been since day 1) with the speed of disk I/O in VMWare Fusion. I'm running the latest & greatest version on my Mac Pro:

• 8 cores at 3.0 GHz

• 16 GB of RAM

• Apple's RAID card

• 4 @ Seagate 7200.11 terrabyte drives

• RAID 0+1 configuration of the 4 drives above

From my perspective, this is a smoking fast machine and its behavior under OS X proves that out. Here's my problem, I do ASP.NET programming work on Windows so I am running either XP or Vista (doesn't seem to make much of a difference) in a VM running Visual Studio 2008 and SQL Server 2008 and my disk I/O is really poor. CPU and memory access are very fast, but that disk is a big bottleneck when I'm compiling code, etc.

Anyone know of any tricks to speed things up? I'm using "vanilla" VMs that were created by Fusion, I'm running the latest & greatest VMWare tools and I normally run a 40 GB virtual disk with somewhere between 2 and 4 GB of RAM and 2 cpu's dedicated to the XP or Vista install. 64-bit or 32-bit Vista doesn't make much of a difference either.

Any suggestions/help would be massively appreciated!

Thanks

[BobTheDog]

I see the same thing.

I use Visual Studio for C++ dev and the build speed is a nightmare, disk I/O is the culprit.

I would love to know if there was a way to speed it up.

Andy

[wila]

Hi,

Maybe a stupid question, but have you set Fusion's preferences to optimize for disk speed?

In the VMware Fusion menu, select preferences, then in the general tab page, under Performance, make sure the radio box "Optimize for virtual machine disk performance" is selected. I'm not sure anymore if the change is immediate, eg. you might have to restart your VM/host in order to see the changes.

Hope this helps,

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[BobTheDog]

Its not a stupid question but yes I have it set to Optimize for VM disk performance.

Cheers

Andy

[bceverly]

I recently made a configuration change to my laptop that seems to have helped somewhat. I got rid of the VM, created a bootcamp NTFS partition, reinstalled everything there and then re-enabled VMWare from the bootcamp partition. Using a native partition, build times are better. Wish I could do this on my MacPro but I have the Apple RAID card in that beast and no, RAID 10 doesn't help much on build times using a virtual disk.

[wila]

Hi,

I'm surprised to hear that the bootcamp partition works better for you. The reason for that is that the bootcamp VM does use a proxy helper virtual disk and AFAIK doesn't get direct disk access either. But my understanding of how this works in OS X might be completely off

Another thing you might try is moving your swap disk to an external virtual disk and - if possible - to another spindle.

You can see more of my reasoning on that on the article i wrote here: Windows VM Page File Policies

FWIW, I've also heard that Fusion's performance under Snow Leopard is better, but I haven't been able to test that myself as I do not have Snow Leopard yet.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[bceverly]

I made that change at the same time I upgraded my hard drive. Perhaps the better drive helped. Thanks for the tips.

[DannoXYZ]

Well, I would think that running off a physical drive-partition would be faster than a virtual-disk file. With the VMDK virtual-drives, the WindowsVM executes a write to the virtual hard-drive. Then Fusion would execute a second operation and write the data to the actual disk-file. That certainy would seem slower than if the WindowsVM writes directly to the hard-drive if it's running from the BootCamp partition.

Did you do any benchmark testing with something like HDtach on your VM using virtual-disk files versus BootCamp partition?

[bceverly]

Unfortunately I did not.

[admin]

Well, I would think that running off a physical drive-partition would be faster than a virtual-disk file.

We've found this is generally not the case.

With the VMDK virtual-drives, the WindowsVM executes a write to the virtual hard-drive. Then Fusion would execute a second operation and write the data to the actual disk-file.

No, there's still only one write that happens. We translate the write from what the guest thinks it did to the actual virtual disk file.

That certainy would seem slower than if the WindowsVM writes directly to the hard-drive if it's running from the BootCamp partition.

The guest does not get unfettered access to the hard drive - if it did, it could mess up your OS X partition. Plus, most, if not all, devices are designed for exactly one controller, so we'd have to have some interposition anyway. There are a number of other factors, but the bottom line is that short of a severely fragmented host filesystem, raw disk access is probably worse.

bceverly: benchmarking in the guest would probably be a good starting point. Some things to double check for maximum disk speed are that you're not using HGFS shared folders (they're convenient for some things, but speed isn't one of their strong points), that you're using a SCSI virtual disk (if you used Easy Install, this is the default), that neither the host nor the guest filesystems are fragmented, you're using a preallocated virtual disk with no snapshots, and the virtual machine is on its own drive (separate from the system drive or anything else that would compete for disk access).

[bceverly]

Hi,

I might be able to call this one solved. I am not using a preallocated disk and I do have one snapshot saved. Also, it is on a laptop so it is on the same drive as the OS. How big a deal is that last one?

- Bryan

[admin]

I am not using a preallocated disk and I do have one snapshot saved.

Note my comments are for maximum performance, but I would not expect these to have made a large difference. It might be worth making a backup copy of the virtual machine, then discarding the snapshot, changing to a preallocated disk, and defragmenting the host to see how much that helps.

Also, it is on a laptop so it is on the same drive as the OS. How big a deal is that last one?

Laptop drives are in general slower, so I would expect that putting the virtual machine on a 3.5" external drive would improve performance - in fact, this would be my guess for the single best thing you could do to improve things. However, your original post mentioned a Mac Pro with lots of drives -- what happened to that?

Being on the same drive as the OS matters to the extent that the OS is doing I/O (which would compete with the virtual machine). Activity Monitor might give some insight.

[wila]

Laptop drives are in general slower, so I would expect that putting the virtual machine on a 3.5" external drive would improve performance - in fact, this would be my guess for the single best thing you could do to improve things.

Sometimes it is easy to forget basic things, yes this is very true. This is also why I personally customize my order for laptops and make sure that they come with a 7200rpm disk instead of the default 5400rpm.

If you do use an external disk then I would personally try to get one with a firewire 800 connection over a USB2 one, although the latter should be fairly decent, USB2 still uses CPU for transferring data whereas firewire has its own controller.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[BobTheDog]

Well i have a Firewire 800 two disk raid 0 drive with my VM on for my MacBook Pro and it is very slow at disk access, the kernel % is extremely high when accessing the disk.

The internal Raid 0 on the MacPro is better but still slow.

I did some tests once using different r/w buffer sizes I will see if I can dig out the results, I do know the buffer size had a massive impact on performance.

[wila]

Well i have a Firewire 800 two disk raid 0 drive with my VM on for my MacBook Pro and it is very slow at disk access, the kernel % is extremely high when accessing the disk.

Umm... guessing that you are using software RAID for this? Your firewire disk doesn't have an internal RAID controller on there I suppose? If so then that completely explains the kernel's involvement into accessing the disk. Of course there is always some kernel activities involved, but it should not be extremely high when using firewire disks vs using USB disks.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[BobTheDog]

No not software, the FireWire drive is a hardware raid 0 device internally.

When used from OS X it has much better performance then the internal laptop disk, I got it in the hope of speeding up Fusion.

Also I am talking about XP kernel cpu usage which I would take to be the VMWare drivers for disk access?

Cheers

Andy

[wila]

No not software, the FireWire drive is a hardware raid 0 device internally.

OK, nice

When used from OS X it has much better performance then the internal laptop disk, I got it in the hope of speeding up Fusion.

But it doesn't help at all?

Also I am talking about XP kernel cpu usage which I would take to be the VMWare drivers for disk access?

Sorry to ask, but what makes you think that this is what is using the extra CPU usage, how do you know it is kernel CPU usage? How are you measuring this higher guest CPU usage?

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[BobTheDog]

Hi,

It is definitely quicker than the stock drive in Fusion but still slow.

I am measuring kernel usage via Task Manager with "View->Show Kernel Times" ticked.

In general when using Fusion the Kernel proportion of the cpu load is pretty high, much higher than with XP booting directly.

Cheers

Andy

[wila]

Hi Andy,

I am measuring kernel usage via Task Manager with "View->Show Kernel Times" ticked.

Cool, never seen that one before. The problem with it is that it really tells you no details at all, so you don't know what the kernel is doing and why it shows high usage. For example I just noticed that it was showing very high kernel times when my guest was swapping memory from disk back into RAM.

Perfmon is a better tool for the job as it actually gives you counters for details like swap usage. I strongly doubt that the XP VM has higher kernel usage times because it is stored on an external disk because the XP VM is totally unaware of where it is stored. If the CPU is more active then that would be the CPU time on the host part not the guest.

But that's just my view on this.

In general when using Fusion the Kernel proportion of the cpu load is pretty high, much higher than with XP booting directly.

It would probably be fairer to test between 2 VMs one on your host OS native disk and one on your RAID 1 disk. Then if you run the same load, does it still show much higher kernel times on the VM stored at the RAID 1 disk?

I'm not surprised that the cpu load is higher on a VM vs. native. There are more context switches required as the CPU is shared. Besides time keeping is not always correct either, making such counters a little unreliable as well.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[BobTheDog]

Hi Wil,

Thanks for the interest in this.

To me High Kernel percentages usually signify that the code is spending time in device drivers this leads me to believe that it is the Fusion disk I/O drivers causing the issue, but of course this is a guess.

The percentages are high on any disk access not just over firewire, I think the firewire drive adds a little bit more kernel time but not much.

For me the performance of Fusion for CPU/Memory and Graphics is very near standalone XP while disk speed seems to be around 25%-50% in real world use.

For instance the main system I work on takes just over three hours to do a full build under Fusion on my MacBookPro while on a similar XP machine it takes just over an hour.

Cheers

Andy