A few months ago I laid out a procedure that allows you to keep an aging Mac OS 10.6.8 install alive, either in a VM running inside a more recent OS X release or dual-booting alongside it, primarily as a way to keep Apple’s Rosetta compatibility layer around so that old PPC software can still be used.

Well, it works. Sort of. It works great right up until it doesn’t, and then it gets really ugly if you’re fond of your data. Oops.

The problem stems, ironically, not from the hacky part where we get around VMWare’s artificial limit on Mac guest OS versions. Nope, that part is seemingly totally safe. The dangerous part is the way we create a VMDK file that references a physical block device in the host system, in order to avoid copying the 10.6.8’s drive into a disk image and allow bare-metal booting back into 10.6.8 if desired.

What can happen, if you physically reconfigure your hard drives — say, by moving some of your old internal HDDs out into USB chassis in preparation for copying them to bigger, newer, internal drives; this is all purely hypothetical by the way (eyeroll) — is that the disk identifier that used to point to the ‘legacy’ Mac OS installation will instead point to some other drive. Some perfectly innocent drive, just out minding its own business, having no idea of the dangerous neighborhood it was thrust into.

So, for example: say when you did the 10.6.8 ‘virtual dual boot’ procedure, that the 10.6.8 disk was /dev/disk2. So the VMDK file that VMWare uses to point to that drive says /dev/disk2. This is all well and good.

But if at some point in the future you muck around with your hard drives, and suddenly the 10.6.8 drive isn’t /dev/disk2 anymore, and instead /disk2 is occupied by (say) a backup hard drive, and then you fire up your VMWare virtual machine… well, VMWare just assumes that /disk2 is the same as it ever was, and the guest OS continues to use it right where it left off.

Specifically, at least if the VM is suspended (rather than shut down) when all this happens, the VM will actually resume cleanly, but then it’ll start getting errors as it starts to read and write from what it thinks is its hard drive, but which is actually some completely different drive. Oh, and as it does this, it’s corrupting the other drive by writing data from its cache down to it.

This is pretty horrifying, from a technical perspective, because there’s lots of ways that you can prevent it. The VMDK file itself actually contains a drive serial number and other data which would be enough for VMWare to realize “hey, that’s not the drive I was using when you hit the pause button!” but it doesn’t seem to be that bright. Instead, it just chews up whatever drive has the misfortune to have the identifier that it thinks it ought to be using.

So, long story short: be extremely careful with the virtual dual boot procedure previously described. At the very least, don’t run it on a computer that contains data you don’t have backups of elsewhere, and you may also want to physically disconnect your backup drives (e.g. Time Machine disks) before playing around with the virtualized guest.

In a separate post I’ll detail a procedure for converting a ‘virtual dual boot’ configuration with a physical drive for the guest OS, into a more traditional VM configuration using a disk image.

Anyway, that’s what you get for taking technical advice from strangers on the Internet. We’re all dogs in here, and not good at computer.