05 Sep 2015

Mac + VMWare P2V Procedure

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.

This entry was converted from an older version of the site; if desired, it can be viewed in its original format.