giovedì 16 luglio 2009 Posted by Freddy at 17:48 10 comments

Scusi, devo fare un bonifico...

- E la causale?
- Mah... faccia lei...
- Vediamo subito.


martedì 14 luglio 2009 Posted by Freddy at 15:29 10 comments

How to migrate from VirtualBox to VMware

If this post is useful to you, please consider a small donation in Bitcoins, thank you.

1MobQb3zWcepeNriJ8K2MLPcFru5GKiKrJ


This is one of the few posts in english and probably the first and only technical post on this blog.

If you are going to switch from VirtualBox to VMware it will be probably one of the few posts available on the net, as it seems that all the others talk about switching from VMware to VirtualBox.

While there are good reasons to to use Sun VirtualBox (it's free, light, pretty fast and updated often), unfortunately there are several others not to use it.

Reasons like the console crashing 100 times a day or the Virtual Machines refusing to run because they were left in an inconsistent state after a proper power off, or the cumbersome snapshot management system...

So maybe you just want to go back to VMware, but you want to keep your virtual machines without the need to reinstall them from scratch.

You could install "VMware Converter" inside the guest OS and choose to convert a "psysical machine" and then move the oputput files on the host OS (recommended if the Guest OS is MS Windows), or you could perform the conversion entirely on the host OS.

If you are wondering, no you cannot just run VMware Converter and perform a direct VirtualBox (VDI) to VMware (VMDK) conversion because Sun's VDI format is not yet supported.

Another option could be to just export a virtual machine from VirtualBox as a "Virtual Appliance" and then import (convert) it into VMware using VMware Converter or ovftool, after all there was a big emphasis on this new interoperable OVF format...

Well... unfortunately in the real world such a process fails 9 times out of 10 with VMware Converter complaining about the OVF file.

Now you could edit the OVF file and try to "fix it" so that VMware Converter / ovftool stop complaining, but at the end you will still need to perform a conversion, so I have decided to share a simple method that does not involve the use of the above-mentioned tools at all and that, surprise surprise, doesn't need you to create intermediate massive RAW disk images like most of the tutorials available tell you to do.

Assuming that on your machine you have installed both VirtualBox and VMware here you are the process step by step:

Launch the Virtual Box console and launch the virtual appliance export wizard (File->Export appliance), choose the virtual machine to export, decide where to save it and press "EXPORT" (this step can be done using the command line as well, but it's simpler to just use the GUI).

Once the export process is over, you will have a OVF file describing the VM and a new highly compressed VMDK file containing the Virtual Disk.

Now you probably are thinking that you could just create a new virtual machine within VMware with the same parameters as the one in VirtualBox and use this brand new virtual disk and you are done.

You can try, but chances are that VMware will just throw some criptical error at you, something like this (spelling error included):

VMware Workstation unrecoverable error: (vmx)
ASSERT /build/ob/bora-156735/bora/devices/disk/disk.c:3868 bugNr=21838
A log file is available in "/My_VMs/SomeOS/vmware.log".
A core file is available in "/My_VMs/SomeOS/vmware-vmx-3156.dmp".
Please request support and include the contents of the log file and core file.
To collect data to submit to VMware support, select Help > About and click "Collect Support Data".
You can also run the "vm-support" script in the Workstation folder directdly.
We will respond on the basis of your support entitlement.

In order to avoid the error above, you will need to process the disk image once more in order to have it in a suitable format. To do so, you will need to run the "virtual disk manager" command line utility available in the directory where VMware was installed and perform a conversion:

vmware-vdiskmanager -r EXPORTED_VM.VMDK -t X WORKING_VM.VMDK

Where X can be:
1: growable virtual disk split in 2GB files
3: preallocated virtual disk split in 2GB files

Depending on the size of the Virtual Disk, you may want to experiment also with:

0: single growable virtual disk
2: preallocated virtual disk
4: preallocated ESX-type virtual disk

Keep in mind that with disk types other than 1 and 3 if the resulting Virtual Disk is too big for the FileSystem where you are performing the conversion, the utility will throw an error.

Let's see it in action with a "growable virtual disk split in 2GB files":

vmware-vdiskmanager -r ./exportedappliance.vmdk -t 1 ./workingimage.vmdk

Creating disk './workingimage.vmdk'
Convert: 1%.....100% done.
Virtual disk conversion successful.


Now you can optionally defrag the virtual disk:

vmware-vdiskmanager -d ./workingimage.vmdk

Defragment: 1%.....100% done.
Defragmentation completed successfully.


And shrink it:

vmware-vdiskmanager -k ./workingimage.vmdk

Shrink: 1%.....100% done.
Shrink completed successfully.


Now you can start the VMware console and create a new Virtual Machine using the same parameters as the old one in Virtual Box, attach the newly converted Virtual Disk image to it and start it up. Once started, you will need to install the Vmware tools and optionally uninstall the old VirtualBox guest additions.

Remember to attach the Virtual Disk to the same controller type/model (PATA/SATA/SCSI) as in the old virtual machine or chances are that the system will not boot.

If you were using X, your xorg.conf will be broken. Just install the VMware tools in text mode. You will have the possibility to run a configuration script later that will fix everything for you.

If the Guest OS was Windows and you get a blue screen immediately after boot, maybe you should think about installing VMware Converter and perform the conversion from within the Guest OS while it is running on VirtualBox, unless you know how to force the usage of generic IDE drivers using Windows' recovery console.