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.)
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.
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.
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.
./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.
./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.
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).
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
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
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.