I couldn’t find any updated information on this online, so this is my ultra short guide to converting VMWare disk images to VirtualBox. This is tested with VirtualBox 3.0.0 under Fedora 11.
Step one is to concatenate fragmented VMWare images. This might not me necessary in your case, but we’ll do it anyway. Let’s assume the image you want to convert is called leopard-fragmented.vmdk:
vdiskmanager -r leopard-fragmented.vmdk leopard.vmdk
Now you’re got a rather huge VMWare disk image file, and we’ll use qemu to convert it into a raw disk image:
qemu-img convert leopard.vmdk leopard.bin
This will take a while, and you’ll probably end up with a less-than-huge file since this is the raw file, without any fancy compression. Now you’ll want to convert this to the VirtualBox disk format, vdi:
VBoxManage convertfromraw leopard.bin leopard.vdi
The vdi ended up being around 7GB – more or less the exact size of the vmdk file. The temporary bin file was 32GB though. Be sure you’re got enough room on your disk for this job.
As a website developer, I unfortunately need to test everything in Microsoft’s dreaded Internet Explorer. For this, I’ve got a Windows XP running on an installation of VMware® Workstation on my Linux desktop. It works like a charm, except when the kernel is updated.
Aside from being a website developer, I’m also a paranoid system administrator. One of the first thing I add to my login scripts, is umask 077 – the command that sets the permission mask for newly created files. Setting this to 077 prevents anyone but the current user from being granted any rights – read, write or execution. It’s a sane thing to do, but unfortunately a lot of scripts fail to explicitly grant access to other users, especially when installing RPM packages or – in this case – running VMWare after a kernel upgrade to build new VMWare-specific kernel modules.
In this specific case, VMWare kernel modules were built by the root user, and ended up in /lib/modules/2.6.27.19-170.2.35.fc10.x86_64/misc/ which was created by the build process. Read permissions were not explicitly granted to everyone, so when running vmware as a mortal user, it was unable to actually read and verify the newly built kernel modules. The natural response to the user wasn’t “Unable to read kernel module files”, but instead “You need to build kernel modules for your specific kernel”. Makes a lot of sense, eh? 
Manually granting read and execution rights on the /misc directory and the files in it fixed the issue.
