Brian's Brain

As follow-up to my recent VMware Fusion coverage, I briefly got on the phone last week with Senior Product Manager Pat Lee to answer some of my questions about the product.

Expanding Virtual Disks

Right now, my Windows XP virtual machine has a 20 GByte maximum disk size, since my MacBook's 160 GByte hard drive was already quite full when I created the VM (a 100 GByte HFS+ partition containing OS X and a variety of apps, along with ~20 GBytes' worth of Windows data that I'd copied over from the defunct 60 GByte NTFS Boot Camp-created partition). Since it looks like I'm going to abandon the Boot Camp approach and go with virtualization going forward to run Windows XP on this system, I no longer need the NTFS partition; conversely, I'm going to need a much bigger virtual disk.

Pat explained that the easiest way to accomplish this task without needing to reinstall Windows from scratch would be (after deleting the NTFS partition to free up additional space) to create another (and larger) virtual machine and then clone-and-expand my existing Windows image to it. After I verify that the new VM works fine, I can delete the old one to free up disk space. Google-searching suggests that it's also possible (albeit in a VMware-unsupported fashion) to expand the in situ virtual machine using a combination of VMware- and open source-supplied tools.

Virtual Disk Compaction

Pat confirmed that VMware Fusion (along with, for that matter, any virtualization product) that creates its own virtualized disk instead of leveraging an existing Boot Camp or other physical partition exhibits a quirk that I'd last encountered with Microsoft's Virtual PC for Mac v6. In brief, whether the virtualized disk is monolithic or split, and sparse or preallocated, it doesn't work like a traditional drive; deleting files and directories does not free up available space, and updating files similarly results in incremental virtual disk space utilization. As VMware's documentation notes:

Fusion has a very low-level view of the world - it doesn't know what files are to the guest, just that a guest wants to write some data to a particular block. For efficiency, most (all?) filesystems not only store data (e.g. the contents of that document you've been working on) but also metadata (e.g. the name, path, date modified, size, and so on). When you delete a file, most of the time you're deleting the metadata, not the actual data - this is why a giant file doesn't take long to delete, and is key for how data recovery software works (they try to guess/reconstruct the metadata). However, from Fusion's point of view, it doesn't know what the data means, so deleting metadata doesn't look any different from writing a small amount of data - Fusion has no idea that the data the file referred to isn't important anymore.

Disk defragmenters are quite troublesome to use on a virtual disk for this reason, and are therefore not recommended. Fortunately, the tools suite included with VMware Fusion includes a 'shrink' utility that, working in conjunction with the guest operating system, can "tell what's actually a file (and thus contains valuable data) vs. what's wasted space (and can thus be gotten rid of and save space)." The shrink tool does not automatically run, since it takes quite a bit of time to accomplish its task and since the guest operating system is unusable while compaction is in process. You'll need to remember to periodically kick off a manual compaction session; alternatively, you'll sooner or later be prompted to do so by a disquieting 'disk full' message from the guest operating system!

Migration And Reactivation

Pat reminded me why I didn't have difficulty reactivating Windows XP Professional, already established on the Boot Camp partition, when I subsequently installed it on the VMware-created virtual disk. I had a retail copy of XP with me, which allows for a limited number of reactivations with the same keycode even if the underlying hardware platform drastically changes (as was the case in my situation).

On a related note, Windows XP (and Vista) reinstallations on different virtual disks within the same computer (as I allude to in the beginning of this writeup) similarly shouldn't cause reactivation problems, since the virtualized hardware setup presented to Windows is largely unchanged (aside from, perhaps, a different virtual disk capacity). And migrating a virtual machine from one computer to another also shouldn't cause an activation failure; although the CPU itself isn't virtualized by VMware Fusion and would therefore present itself has having changed to the virtualized operating system on the new computer, Pat didn't think that this one change would be enough to prompt a reactivation request.

Stay tuned for more impressions as I further plunge into VMware Fusion-based virtualization in the weeks ahead.