I recently replaced a couple of servers within a friends business with an oVirt virtualisation setup, I’m really pleased with the whole configuration which consists of a single engine host and 2 hypervisor nodes, the storage is shared over the 2 hosts with glusterfs. The guests which run on the platform replace the services that ran separately on a couple of physical servers, LAMP stack for intranet, Asterisk PBX, postfix/dovecot mailserver, squid proxy cache, Bind DNS, and DHCP server.
The big problem I saw with the setup was the Windows XP virtual machine which was running on the existing server as a libvirt/kvm guest. This was an emergency config which was provisioned to fulfil a temporary need which, as usual, became permanent. Originally when I decided on the ovirt configuration, I presumed with it being kvm based an import would be a simple case of importing an image file. Unfortunately with the current version this is not the case, but I believe it is planned for future releases. This doesn’t help me now, so with Google being my friend i decided to search around a bit, I found clumsy solutions using cat (which I tried without luck), and other solutions such as v2v required the original guest to be running, which wasn’t an option for me. So I had a little play around and actually ended up with a working image.
First thing I did was convert the qcow2 image to a raw image using qemu-img convert, (-p gives a progress report):
qemu-image convert windowsxp.img -O raw windowsxp-raw.img -p
You can confirm the image details or even look at the existing image details using the command:
qemu-img info windowsxp-raw.img
I worked this out from seeing the process which occurred during an export/import process within ovirt, this was from a temporary ovirt machine I used to pre-build the servers before the arriving to their office.
Next I created a guest within ovirt, and created a new disk for this machine. At this point the disk files didn’t exist so I powered on the virtual machine. Happy the files were created I then powered the vm off. I verified that the files existed by browsing to the datastore from a console, using the UUID of the disk image which was created and looked in the directory of that name.. for example if the disk image had a uuid of abcdefgh-1234-5678-90ab-abcdefghjklmn on a datastore vmstore the path would be something like
In this directory would be several files, but the one without an extension would be your disk image, you could probably work this out by looking at the sizes of the files.
On the same principle of the cat method I previously mentioned, which I wasn’t too keen on the sanity of I decided to try trusty old dd.
dd if=/windowsxp-raw.img of=/data/vmstore/uuidofdatastore/images/abcdefgh-1234-5678-90ab-abcdefghjklmn/abcdefgh-1234-5678-90ab-abcdefghjklmn bs=4M
Once this completed I powered on the virtual machine, and to my surpise I was eventually presented with the Windows XP desktop I was expecting.
I downloaded the virtio drivers iso from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/ and attached it to the virtual machine and allowed the hardware to be detected and reinstalled correctly.
I hope this helps anyone else in a similar situation