There is another version of this problem. If you're using a vmdk with a separate data file and descriptor file (e.g. foo.vmdk plus foo-flat.vmdk), VirtualBox adds some lines to the descriptor file that break vmware-mount. If you delete the offending lines (that all begin with "ddb.geometry.bios", you can again vmware-mount the disk. Full details are at http://www.kleinfelter.com/vbox-vmdk
The problem with the "dd" commands offered by "[~225873]", (above) is that you only get the disk-descriptor section in the resulting
"cleaned" VMDK file, in other words, the file is truncated and unusable.
Alternatively, you can try these steps, which I put into a script. I probably would not have thought
of this without "[~225873]" "dd" editing ideas.
I tested the following shell script on a monolithic, growable (type 0) VMDK file which got trashed by VirtualBox:
#!/bin/sh # Strip out VirtualBox settings from VMDK file # Usage: $0 <vmdkfile> # dd if=$1 bs=512 count=1 of=vm.hdr && \ dd if=$1 bs=512 skip=1 count=2 of=vm.ddesc && \ cat vm.ddesc | grep -a -v ddb.uuid.image \ | grep -a -v ddb.uuid.modification \ | grep -a -v ddb.uuid.parent \ | grep -a -v ddb.uuid.parentmodification \ | grep -a -v ddb.geometry.biosCylinders \ | grep -a -v ddb.geometry.biosHeads \ | grep -a -v ddb.geometry.biosSectors > vm.novb.ddesc && \ dd if=vm.novb.ddesc conv=sync,notrunc of=vm.new.ddesc bs=512 count=2 && \ dd if=$1 bs=512 skip=3 of=vm.nohdr && \ cat vm.hdr vm.new.ddesc vm.nohdr > $1.fixed
Note, this script has minimal error checking and validation. The output file is named by using
the input vmdk file name appended with ".fixed", which you will need to rename before
It would be a lot easier if VMware could just ignore the VirtualBox ddb settings. I am running
VMware Fusion 2.0.6 on MacOSX 10.5.8.
This workaround should work for any guest OS contained in a type=0 VMDK (monolithicSparse)
Since performing a cleanup to remove VirtualBox-specific settings from the VMDK file can take
a long time (due to moving dozens of gigabytes of data around on the harddrive), the solution
of changing the VMDK file is not practical if you still want to be able to quickly switch back
and forth to/from VirtualBox and VMware (e.g. during evaluation).
In that case, I have another workaround which leaves the VMDK file with the extra VirtualBox
ddb settings. Instead, you can reconfigure grub to search for it's boot device by the
device name rather then the UUID of the device. This way, you can boot the same, unchanged
VMDK file with either VMware or VirtualBox. The only caveat is that the device name
gets "baked in" to grub's config when you run "update-grub", such that if you are booting from
an external USB drive, you need to make sure it always gets assigned the same device
name - usaully by insuring you plug in the same USB devices in the same order from boot
to boot of the host OS. (this is one advantage of searching for boot devices by UUID, this search
method is immune to device name changes due to adding devices in different sequence)
This solution only works with Linux VMDK files as guest OSs.
When the Linux guest is up and running either on VMware or VirtualBox, perform
You're supposed to be able to just run "update-grub" and be done, but
there appears to be a bug in grub (at least the version with Ubuntu-9.1,
1.97_beta4) such that update-grub still adds UUID-related searching to
the grub menu items.
To workaround this problem, as root, go to this directory:
Make a backup of the script module, "10_linux":
cp 10_linux bak.10_linux
chmod 444 bak.10_linux
(Note the backup file name MUST NOT have a number/digit prefix)
Edit "10_lunux" and comment out the line which begins with:
Now run "update-grub".
The result is that the grub config file:
Will have changes to the menu selections (which you don't even see unless
you hit escape, then 'e' on a given item)
...from UUID-type device search:
search --no-floppy --fs-uuid --set 472bb5e7-c394-405f-9d5e-f7639ecf143a
linux /boot/vmlinuz-2.6.31-14-generic root=UUID=472bb5e7-c394-405f-9d5e-f7639ecf143a ro single
...to older style device-name search:
linux /boot/vmlinuz-2.6.31-14-generic root=/dev/sda1 ro single
Now this VirtualBox VMDK can boot either from VMware or VirtualBox.
BTW, if you're nervous about updating the grub configuration, you can
reconfigure on-the-fly by hitting escape as soon as grub starts to load,
then you'll be presented with a menu of OSs to boot - typically the
normal Linux and a recovery-mode Linux, you just highlight the one
you want with the up/down keys, then press 'e' (to edit the menu item)
and change the search style from UUID to device (see lines, above),
then hit Control-X to boot.
This problem might possibly be due to ambiguous vmdk spec. I am looking a a document called,
Virtual Disk Format 1.1, filename, vmdk_specs.pdf. There is a section called.
The Disk Database, but all it says is:
Additional information about the virtual disk is stored in the disk database section of the
descriptor. Each line corresponds to one entry. Each entry is formatted as follows:
ddb.<nameOfEntry> = "<value of entry>"
There's no word on what values of are valid, so I suppose there was an assumption
by the VirtualBox people that any value could be used. However, if I sift through the strings of the
vmware-2.0.6 executable, I see:
strings vmware | grep ddb
ddb.%s = "%s"
DISKLIB-DSCPTR: Unrecognized ddb entry. ID='%s' Val='%s'
Which seems to support the idea that only certain values of ddb.<nameOfEntry> will be accepted
by VMware, although I fail to find any string, "Unrecognized ddb entry" in any log file, unless I need
to change the log level, but I have no idea how to do that.
I frequently use a vmdk file under VMware Fusion and VirtualBox with no problems, even booting up the virtual machine.
SnapShots and AutoProtect are not used with such virtual machines (used under both products) as those features/facilities modify the vmdk files.
For good measure, I get a back-up of the files before 'flipping' products
In my scenario, the host is MacOS 10.5 and the guest is Ubuntu-9.1 and the VMware Fusion is release 2.0.6 and the VMDK
file type is 0 (monolithicSparse), a single growable file. I also do not use AutoProtect nor Snapshots.
Which release of Fusion are you using? Also, is your guest OS Windows? I tried a Windows-XP Home guest and this seems to be ok
under both VMs, so apparently this problem is only manifest when the guest is Linux, maybe even when it's specifically Ubuntu.
However, even in the Windows guest case, I had to change the drivers per this tech note:
The only reason I make a big deal out of it, is because of a number of similar complaints logged over at VirtualBox bug database:
Unfortunately, these issues don't include specific host/guest/vm release name/numbers to better understand
which combinations manifest the problem.
VMware Fusion Release: Started using both products since Fusion 2.0.?
Guests: always a Windows flavor, never a Linux flavor and never a boot camp as the VBox tickets seem to imply
Virtual Drives: Always ensured that the same type used/defined (same geometry, same controller) for the virtual machines (are you a thrill-seeker?)
The 'flipping' products is no time to trying a conversion (implied in one of the tickets)
Edited: if -> of