If you’re not satisfied with VMWare’s support regarding Linux, and your VMWare Server 2.0.x doesn’t behave reliably, it’s time to migrate to KVM, if you are on Linux. I’ve done this, and I am quite happy. It’s working better, than I thought.
Although there are quite a few HOWTOs and Migration instructions, nevertheless none of them met my needs. This is a step be step migration guide for an Ubuntu Karmic (9.10). (Should work for SuSE, Gentoo and Fedora with a few mods, too)
This guide is devided into these four steps:
- aptitude install …
- vmware-vdiskmanager …
- qemu-img convert …
- modifying /etc/network/interfaces -> br0
- restarting, ifconfig
- changing the xml output for br0
- change path to new vm and SCSI in xml output
- adding with virsh
- starting with virsh
- other tools/methods
Let’s go, it’s not that difficult…and you won’t work on the originals. If all goes well and you’re experienced, you’ll be finished within 15 mins. I was, at least when i ported my second vm client 😉
First check if you will use qemu, or kvm. If the command below returns anything, go ahead, because your processor do support virtualization and you can use kvm.
If nothing returns, you can use qemu, which runs without hardware support, it’s slower, this guide doesn’t cover that (but would be almost identical, libvirt is the true hero anyway).
cat /proc/cpuinfo | egrep "(vmx|svm)" --color
If your VMWare image exists as multi-vmdk-file, like this one:
ll *.vmdk -rw------- 1 root 443 2010-02-23 20:28 Ubuntu.vmdk -rw------- 1 root 524288 2010-02-23 20:27 Ubuntu-f003.vmdk -rw------- 1 root 2147221504 2010-02-23 20:27 Ubuntu-f002.vmdk -rw------- 1 root 2147221504 2010-02-23 20:28 Ubuntu-f001.vmdk
then you have to convert it first, and this is done with the
vmware-vdiskmanager -r Ubuntu.vmdk -t 0 Ubuntu-2.vmdk
If you uninstalled your VMWare Server already, you’ve been too fast!
Unfortunately you’ll get an error message, if you try to convert this file with an another vmware-vdiskmanager, installed somewhere else. You have to do the conversion with the installation, under which you images were running.
Failed to convert disk: You do not have access rights to this file (0x260000000d).
The conversion itself is pretty fast, and takes only at most two minutes for approx. 4Gig.
Now we have to bring this image into a kvm/qemu format. We’ve got to install all the necessary stuff for it first:
sudo aptitude install virt-goodies qemu-kvm kvm libvirt-bin ubuntu-vm-builder bridge-utils virt-top
Now do this:
qemu-img convert Ubuntu-2.vmdk -O qcow2 Ubuntu-2.qemu
This procedure is even faster than the step before, and is actually not really necessary. But if you like to be able to perform snapshots of your running virtual machine – and you really should – then you need this second step, too.
We are almost there. What we need now is a network environment and tools which let us handle the virtual instances a bit more easy.
Let’s create the appropriate network environment for our virtual machines first. The goal is, to have machines in your current netblock. Let’s say your netblock is
and you like your to be converted vm-client be a part of it (like before).
If you checked your devices after the last aptitude statement, you’d have already noticed that we’ve got an extra nic (network interface) called
virtbr0. This new interface is for the netblock
and you likely don’t want to be a member of this one. If you would start your vm now, your vm-client would use
NAT (network address translation) and not
bridging, what we actually have in mind. There’s nothing wrong with NAT. If you like it to use it that way, simple skip the next step. Your virtual machine will automatically be a member of the NAT netblock then.
The bridge interface isn’t there yet. We have to create it first. This is quite easy and can be done undone as quick as you’ve added it to
Make your interfaces file look like this (adopt the appropriate values, if needed)
auto lo iface lo inet loopback auto eth0 iface eth0 inet manual auto br0 iface br0 inet static address 192.168.1.3 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0
and you should see a
if you perform a
ifconfig on the command line.
Now comes the trick. We need the VMWare’s definition file (.vmx) in xml. Therefor we must convert and add it then to our kvm manager.
vmware2libvirt -f Ubuntu.vmx > Ubunut-2.xml
Before you add this file to our manager, we have to make a few (for me essential) changes to the
- we must tell our virtual machine to use a bridged network, instead of NAT. Change this
<interface type='network'> <mac address=.../> <source network='default'/> </interface>
<interface type='bridge'>> <mac address=.../> <source bridge='br0'/> </interface>
And now – if you’ve got your previously VMWare machine running on a SCSI device, you have to tell it your new machine also, because the default device for hard disks is IDE, and if you start your machine it won’t be able to boot from sda, because there is none. You’ll get this or a similar prompt at boot time:
Begin: Waiting for root file system... ... TSC appears to be running slowly. Marking it as unstable Time: acpi_pm clocksource has been installed. Done. Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev ALERT! /dev/sda1 does'not exist. Dropping to a shell! Busybox v1.1.3 (Debian 1:1.1.3-4) Built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty: job control turned off (initramfs)
To solve this, you have to adopt the xml file one more time. Change the section with the
<disk type='file'.... Append to
Second: You have to provide the full path you your new qemu image also, else it won’t be found (here: …/Ubuntu-2.qemu).
<disk type='file' device='disk'> <source file='/var/lib/vmware/Virtual Machines/Ubuntu2/Ubuntu-2.qemu'/> <target dev='hda' bus='scsi'/>
Finally we can add this xml you our vm manager. In our case it’s
virsh. Do the following on the command line
virsh -c qemu:///system define Ubuntu-2.xml
This is vital for bridging!
and now you can start it:
virsh start <name>
Look up Your virtual machine’s name in the xml file. It’s usually the second entry from the top.
We are done.
You can use
to connect to your machine graphically. Or you can start
to manage all your virtual machines in a VMWare alike console style.
will show you your machines in a top-alike style, too.
And the biggest plus of this all is, it’s completely open source, and you can now make a server upgrade every time you like, without the need of recompiling your vmware modules again.
Any questions, Comments, suggestions or typos?
8 thoughts on “HOWTO: Migration from VMWare to KVM (Linux)”
Depending on your use case, you might be better off with VirtualBox. Would have made for a short blog however, without all the VMware image conversion and network adaptation… 😛
I know. Support for USB, Serial ATA and Gigabit Ethernet, according to innotek, will be handed over to the Open Source community, and you can already use it now, for non-commercial purpose. And having Sun by their side is not necessarily a drawback, as less as it is with RedHat for libvirt.
But where’s the point? This is an HOWTO for KVM, and not for VirtualBox anyway.
But as soon as I find a problem with VirtualBox, I will report on that, too 😉
i am using kvm some months with success in most cases.
Now i am on the way migrating a windows 2000 server vmware guest to kvm.
The original vmware environment is not available anymore, but i am sure the guest formerly uses vmware virtual scsi disk devices connected to a vmware scsi controller. The conversion of the image with vmware-vdiskmanager and qemu-img works as usual but if i try to revive the guest with kvm i get a blue screen with “inaccessable boot device”. I have no clue for changing the guests disk interface.
Did you already try the bus=’scsi’ and target dev=’hda’ described above?
You have to do this manually in the xml definition file first.
I prefer native qemu-kvm over libvirt but this makes no difference in this case.
I tried qemu-kvm -drive file=xyz.qcow2,if=scsi,bus=0,unit=0,media=disk … without luck. This is what Your libvirt parameters bus=scsi and dev=hda would be translated to.
I think the only promising solution is to get rid of the proprietary vmware scsi controller driver inside the guest OS.
So my next approach is to disable vmware driver and inject default ide drivers into the guests registry with the help of “Reparaturconsole” and mergeide.reg .
Everything worked perfectly, except the device is not bootable… “Not bootable device” etc.
There is a change in configuration needs, so adding type=’qcow2′ to driver stanza solves the problem.
Here is example:
Would be cool to have the example 🙂
added after “no bootable device” into the xml file.
Done a ‘undefine’ and ‘define’ again.
Read here for more:
Comments are closed.