Fun Times with VMware Beta 3

I’ve been closely following the progress of the VMware Fusion product as it matures from early to late beta. In particular, their latest beta 3 seems to have some competitive advantages over the competition from Parallels:

  • VMware’s guest OS NAT setting now properly works with TUN/TAP based VPNs, like OpenVPN or Juniper’s Network Connect product. Previous betas would not route through the host OS’s routing table, meaning that you’d have to run two VPN clients to use both Mac OS X and the guest OS on a VPN.
  • Performance seems quite good. If your workflow is like mine, you probably care more about the responsiveness of the host OS (ie, Mac OS X, Mail, TextMate, Terminal, etc.) than the performance of whatever emulated software is running.
  • This is purely subjective, but VMware seems to manage the host OS’s resources a bit better. For example, my MacBook runs cooler — for longer on battery power — when running VMware than with Parallels.
  • I’ve also seen some blue screens under Vista in Parallels which don’t seem to happen in VMware.

Still, Parallels has been around on the Intel Mac for a bit longer and is probably better tested in the marketplace, though your mileage may vary. VMware doesn’t do anything like Parallels’ coherence mode, for example, if you like that kind of thing, but Parallels doesn’t have snapshots. VMware’s latest beta adds the ability to boot a VM from a Boot Camp partition, which Parallels has had for some time now.

It is pretty cool to have a few different virtualization solutions, I’m definitely looking forward to what new technologies will come to light as the competition continues to heat up between these two products.

(Of course, if you get attached to VMware’s betas, it is as-yet unclear how much the commercial licenses will cost, once the product is out of beta, which is another factoid to consider…)

UPDATE 4/10/2006: I have run into some problems with building a Visual Studio project that’s stored on a VMware shared folder; it looks like whatever VS2005sp1 is doing to ‘vc80.idb’ (the IntelliSense database) fails on the VMware shared folder, but succeeds on the VM’s C: drive. VS, of course, despite that it is running in “command line” mode, decides that IntelliSense info is so important that it should, you know, fail every build of anything. Because it insists on shitting all over the source tree regardless of how I have my directories configured. Man, I can’t wait to kick the VS* tools to the curb… oh, wait, this post is about VMware. Anyway, I digress. Got around this by making a VM C:-drive local copy, but this is less than ideal. Parallels works transparently here.

UPDATE 4/10/2006: Disk access, both on the VM C:-drive and to the NAT-shared folder, is definitely faster in VMware. Also, some of Parallel’s kexts won’t unload with sudo kextunload xxxxx.kext, which is a little disturbing.


About this entry