After years of using VMWare, I suddenly had to migrate to VirtualBox; I’ve been using VirtualBox for quite some time now, but not in the way I use VMWare.
First I thought it will be a short-lived trip, but now I’m happily stuck. I still had the image of VBox the way it was in the version 1.x in the head. What a blow it was to fully explore 4.x, in my case 4.0.6!
After the upgrade of the system (in my case Ubuntu 10.10 to 11.04), VMWare 7.0.1 – as usual – refused to compile the kernel modules; I already before had to switch from 6.5.2, that worked for a long time very well for me, to 7.0.1, due to kernel update, as there didn’t seem to be any good cure. The same happened this time, but I had no time to look for the patch, I needed stuff done.
So, I just took the virtual machine and threw it in VBox. Without apparent success, may I say. But the success was just a few steps away.
First, I converted the original .vmdk 2GB-split disk image to the VBox’s native .vdi using
VBoxManage clonehd original.vmdk new.vdi --format VDI --variant Standard
This was fast and painless; tweak the command to your needs.
Then create a VBox virtual machine for the system, pretty much duplicating the settings from VMWare.
My original image was WinXP SP2; for the new disk to work, I had to switch the chipset (Machine -> Settings -> System) from default PIIX3 to ICH9. This got the disk to boot properly and got me to the system.
One annoying thing is, that you cannot uninstall VMWare Tools without having the machine running in the VMWare; deleting the folder under Program Files, and drivers (those that could be deleted) in Safe Mode, took care of that, at least it seems.
Then you can install the VBox’s Guest Additions.
Last minor catch was, that the network adapter didn’t seem to work; it seems like both VMWare and VBox use the AMD PCNet driver to simulate the network adapter; fix was trivial – go to Device Manager, select “Update Driver” for the network adapter, and manually select the appropriate driver – the one that doesn’t say “VMWare”.
Last word – how fast the resume/suspend works on VBox! Why is VMWare so slow on this?
I couldn’t agree more on VMware suspend/resume performance (particularly suspend). I’ve analyzed the behaviour using strace and there seem to be two major reasons.
First Virtualbox only appears to write memory that’s in use to disk. If you have 4GB of ram configured but are only using 1G only that 1G will be written.
More importantly VMware seems to write the data to disk in a completely random fashion. It sends large numbers of very small writes. Virtualbox writes the data out sequentially.
There are also substantial problems with vmware performance while running. This is because vmware will, by default use a memory mapped file to back a VMs RAM. Linux, with default settings, will limit how much of this file can be changed and left uncommited to disk. Once this happens the data must be written to disk. There are settings you can use to improve this, documented in this KB article [1]. Moving the file to /dev/shm has a substantial impact on performance while running.
In my experience none of these optimizations will make it as fast as VirtualBox however, thank you for your article. I’ll now be able to migrate my only VMware VM over.
[1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=844