I started blogging again, and wrote about how I am now using Windows Live Writer as my blog editor. Problem is, that I use Mac computers exclusively, so I needed to run WLW under VMware Fusion (inside a Windows Virtual Machine).
That works pretty well, for the most part, but VMware Fusion does not do copy/paste of images between the virtual machines (yet). And, since I like to include an image with every post, it’s kind of a pain to save the image to a file under Mac OS X only to turn right around and load the image into Windows Live Writer. For me, the writing process is enhanced when friction is removed from the process.
So, I thought, naively, that perhaps the free VirtualBox tool might have this capability. Download the product and install it on my Mac OS X Leopard Server and give it a go. The VirtualBox site says that you can use your existing VMware VMDK (Hard disk image) files with VirtualBox. There is evena video showing you that it works great. The VirtualBox User manual says:
Starting with version 1.4, VirtualBox also supports the popular and open VMDK container format that is now supported by a large number of virtualization products. This means you can import your existing VMDK files by way of the Virtual Disk Manager just like existing VDI images; see chapter 3.5, The Virtual Disk Manager, page 34. While VirtualBox fully supports using VMDK files in most situations, the more advanced features of virtual hard disks are presently not supported.
After trying, and failing, to import my VMDK files into VirtualBox, I found, much to my dismay, that my VMDK files were trashed by the VirtualBox import and no longer readable by VMware Fusion. The term "import" usually implies that it is non-destructive. Nope.
I blamed the Fusion failure on the Apple Security Update that I had just installed. Silly me.
After quite a few hours of reading VirtualBox code and poking around with the VMware VMDK on-disk formats, I was able to "patch" my VMDK files into something that Fusion would once again read. Take a look at the VMware Community Forum article for detailed history.
In the corrupted VMDK that was mucked with by VirtualBox, mine looked like the following:
# Disk DescriptorFile
# Extent description
RW 41963828 SPARSE "AmyOffice-000001.vmdk"
# The Disk Data Base
ddb.toolsVersion = "7362"
ddb.virtualHWVersion = "6"
And, it was padded by NULL characters. I extracted it from the VMDK using "dd":
# dd if=AmyOffice-000001.vmdk bs=512 skip=1 count=2 > out
I didn’t like the look of the entries: Note that there is no equals sign between the cylinders/heads/sectors section at the bottom and the values. That did not sit well with me at all. Nor did I like the value of the cylinders was 0 and the heads/sectors did not match the binary values in the first data structure after the MAGIC KMDV in the VMDK file.
Comparing this text header info with a very old backup of my VMDK file, it appeared that I could drastically simplify this section.
So, I did.
I edited the "out" file, and made the following changes:
- Changed the CID to 613506eb
- Deleted everything after this line (but keep it in): ddb.toolsVersion = "7362"
- Extended the NULL padding at the end to get the file back up to 1024 bytes exactly.
Then, I patched the VMDK with the following command:
# dd conv=notrunc if=out of=AmyOffice-000001.vmdk bs=512 oseek=1 count=2
Don’t forget the "conv=notrunc", or your VMDK file will be truncated (which I did, and had to copy over from backup again, sigh).
And, guess what? The VMware Virtual Machine booted up with no problem!
I promptly uninstalled VirtualBox. You get what you pay for sometimes.
Now, if I could just get Time Machine to efficiently backup my 30GB Windows VM…