As promised previously, here is a quick rundown of a procedure that will let you migrate a Mac’s existing bootable hard disk, containing an old version of OS X (particularly versions capable of running Rosetta), into a VMWare Virtual Machine.

This is probably a much better idea than the halfassed virtual dual boot idea I had a few months ago, which had the benefit of allowing bare-metal dual booting into the ‘legacy’ OS version, but also carried with it a certain risk of catastrophic data loss if the disk IDs in your system ever changed.

So, here goes. (The “happy path” procedure is based loosely on these instructions, incidentally.)

1. Install a modern OS X version on a separate hard drive from the ‘legacy’ (e.g. 10.6.8) install. Or alternately, put the drive with the old installation in a USB chassis and attach it to a newer computer, whichever you prefer. N.B. that this will probably not work with installations from PowerPC machines or pre-EFI Macs.

2. Use Disk Utility to obtain the disk identifier for the drive containing the ‘legacy’ installation. This is not entirely obvious; you get it from Disk Utility by selecting the partition in the left pane, then clicking on the Info button and looking for “Disk Identifier” in the resulting window.) It’ll be something like disk7s3. Really, we only care about the disk, not the slice.

3. cd /Applications/VMware\ Fusion.app/Contents/Library/

   This is just to make commands less ugly. You can execute the commands from wherever you want, just use absolute paths.

4. ./vmware-rawdiskCreator create /dev/disk7 fullDevice /Users/myUser/Desktop/hdd-link lsilogic

   This creates a .vmdk file that is really just a pointer to the attached block device, in my case /dev/disk7. It doesn’t actually copy anything.

   Astute readers might remember this from my misguided attempt to create a dual-boot configuration. In that scenario, I used the resulting VMDK pointer as the basis for a whole virtual machine. Here, we’re not going to do that, because we’ve learned our lesson about where that road leads.

5. ./vmware-vdiskmanager -r /Users/myUser/Desktop/hdd-link.vmdk -t 0 /Volumes/BigHardDrive/OldImage.vmdk

   This is where the magic happens; this copies the contents of the drive and puts it into a VMDK container file, somewhere else on the filesystem. (In the command above it’s going to an external HDD called “BigHardDrive”. You can put it wherever, but the destination has to have as much space free as the size of the drive being imaged. Not just space in use, but the size of the entire drive.)

   It would be more elegant to create the result as a sparse image, but I wasn’t having any luck getting that to work.

6. Assuming you have a properly patched (see here for VMWare Fusion 6 patches, and here for Fusion 7+) version of VMWare, you should be able to create a new custom VM and point it to the VMDK file, and it’ll boot.

In my case, though, I got a couple of weird errors:

Failed to convert disk: This function cannot be performed because the handle is executing another function (0x10000900000005).

And also:

Failed to convert disk: Insufficient permission to access file (0x260000000d).

Weird. So, tried to mount it with Disk Utility — maybe the fact that it couldn’t be mounted was a sign of Something Bad with the drive. Yep, it wouldn’t mount. It told me to run a repair cycle against the drive. Which I did.

The not-very-encouraging result: Error: Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files. Which I’d really like to try and do, but I’m not being allowed to for some reason. Ugh.

After a lot of poking around which I’ll spare you the details of, I discovered via top that there was a weird fsck_hfs process running occasionally, taking up a lot of CPU and happening at the same time that I’d see and hear disk thrash to the ‘legacy’ drive. That had to be the problem.

Basically, the system was trying to run fsck against the drive, it was failing and hanging, but in doing so preventing any other processes from accessing the drive. Only by killing the fsck process could I touch the drive’s contents. (And this wasn’t a one-time thing; fsck would periodically restart and have to be killed over and over. It’s a persistent little bastard.) I don’t think this problem has anything to do with the P2V migration, but I’m leaving the problem and solution out here in case anyone else finds it via Google.

Once I killed fsck, I was able to copy the drive to a VMDK, use that VMDK as the basis for a new VM, and it seemed to work acceptably well. Unfortunately I won’t ever be able to boot directly from this virtual machine, unlike the old dual-boot configuration, but it does have the side benefit of not destroying one of my attached hard drives every once in a while.

So it’s got that going for it, which is nice.

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.