After following the guides at wiki.ubuntu.com I ended up with two fairly long template commands:

sudo virt-install --hvm -n <hostname> -r <memory> -f <hdd_image> -s <image_size_in_gb> \
-c <iso> --accelerate --connect=qemu:///system --vnc --noautoconsole

sudo vmbuilder kvm ubuntu --suite intrepid --flavour virtual --arch amd64 -o --libvirt qemu:///system \
--part vmbuilder.partition --user myname --name 'My Name' --pass default --addpkg puppet \
--addpkg unattended-upgrades --addpkg acpid --mirror http://apt/ubuntu --tmpfs - \
--firstboot vmbuilder.firstboot.sh --hostname <hostname> --mem <memory> --dest <hdd_image_basedir>

The command for virt-install is pretty lean compared to the command for vmbuilder. But vmbuilder allows for most of the configuration to be stored in ~/.vmbuilder.cfg. It did take a bit of digging as not a lot about it was on the ubuntu wiki though.

If you are looking for extra help in vmbuilder have a look at:

vmbuilder kvm ubuntu --help

And after setting up the config files below, to create new machines I just use for example:

sudo vmbuilder kvm ubuntu --hostname cacti --mem 256 --dest /srv/libvirt/cacti/

So here is the config I use as an example for anybody who plans on using vmbuilder a lot.

~/.vmbuilder.cfg

[DEFAULT]
arch = amd64
part = vmbuilder.partition
user = myname
name = My Name
pass = default
tmpfs = -
firstboot = vmbuilder.firstboot.sh
firstlogin = vmbuilder.firstlogin.sh

[ubuntu]
mirror = http://apt/ubuntu
suite = intrepid
flavour = virtual
addpkg = puppet, unattended-upgrades, acpid
part = vmbuilder.partition
#ssh_user_key = .ssh/authorized_keys

[kvm]
libvirt = qemu:///system

http://apt/ubuntu is my local approx machine for caching packages. The ssh_user_key is commented out at the moment as it creates the file correctly in the user account, but sets the owner to root.

vmbuilder.partition

root 8000
swap 4000

vmbuilder.firstboot.sh

# This script will run the first time the virtual machine boots
# It is ran as root.

locale-gen en_AU.UTF-8

apt-get update
apt-get install -qqy --force-yes openssh-server

The firstboot script just ensures that if I create an image and duplicate it a few times that each machine will have a unique ssh host key. But the image must be duplicated before the first boot.

vmbuilder.firstlogin.sh

# This script will run the first time the virtual machine boots
# It is ran as root.

# Prompt for a password change
passwd

Because I did not want to put my password in the configuration files as plain text, I only put default as the password and when I login for the first time I am prompted to change it. This will hopefully be fixed when I get the ssh_user_key working though.

VMBuilder/plugins/libvirt/templates/libvirtxml.tmpl

<domain type='kvm'>
  <name>$hostname</name>
  <memory>#echo $mem * 1024 #</memory>
  <vcpu>1</vcpu>
  <os>
    <type>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <interface type='bridge'>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' listen='127.0.0.1'/>
#for $disk in $disks
    <disk type='file' device='disk'>
      <source file='$disk.filename' />
      <target dev='hd$disk.devletters()' />
    </disk>
#end for
  </devices>
</domain>

And the only difference with this template and the default one is this template file sets up bridge networking with virtio by default.

1. Create a disk image of sufficient size
2. Copy the Windows HDD to the disk image
3. Boot the image with KVM

Yip. Only three steps. Beware that Windows p2v images have all run quite slow for me compared to Windows images that were originally installed in KVM. This I guess is just because of the cruft buildup in Windows and all the driver changes that Windows seems to balk at so much.

Although these instructions are written using Window XP as the guest image, it will work equally (extremely) well for Linux too. The only exception with linux being that you can substitute the clonezilla step for a straight tar copy of the images. Using clonezilla for Windows and Linux though reduces the number of different steps to remember.

Create a disk image of sufficient size

I chose to use qcow2 for spaces sake as I am only testing this on my laptop. Feel free to use any type of disk image that KVM supports.

qemu-img create -f qcow2 windowsxp.qcow2 80G

Copy the Windows HDD to the disk image

For this step I pulled the HDD from the machine to convert and connected it via a usb sata converter. The HDD was then accessible at /dev/sdc. However you connect the HDD to your computer, be it internally or externally, you will need to be able to access it as a block device. So just substitute my references to /dev/sdc with the location of your source HDD.

For copying from p2v I chose to use clonezilla again after how handy it has been for resizing NTFS images for me (ref). Download a clonezilla livecd iso from here.

kvm -m 256 -boot d -cdrom clonezilla-live-1.2.1-39.iso -hda /dev/sdc -hdb widowsxp.qcow2

After booting I selected a disk to disk copy and just accepted all of the default options. I will work both with NTFS and FAT32 partitions. The main thing to be aware of when using clonezilla is that the PHYSICAL drive gets selected as the source. It’s description in clonezilla will be similar to the writing on the HDD label.

If you have more than one HDD for this machine then just repeat the above steps for each disk.

If there source machine is using RAID then you first need to burn the clonezilla iso to cd or create a clonezilla live usb stick. Boot the source machine with clonezilla and copy the source HDD to a spare HDD first, then connect the spare HDD to your machine and copy that. Clonezilla does have options for network copy that may save a lot of extra work in this step, but I have not had time to explore them yet.

Boot the image with KVM

On first boot Windows will detect all the hardware changes and install drivers for them. Most emulated hardware in KVM already has drivers in Windows and I did not get prompted for any drivers etc.

kvm -m 512 -usb -usbdevice tablet -hda windowsxp.qcow2

Upon Windows detecting such hardware changes you will also need to reactivate Windows again too. If you are using libvirt then you can also create a new xml definition and manage the image that way.

If you had any static ip addresses defined in Windows these will need to be setup again too as Windows will have detected new network cards. For Ubuntu it is not so much that the network cards have changed but that the MAC address has changed and the new card is likely assigned to eth1 instead of eth0. If you still want the network card referred to as eth0 the edit /etc/udev/rules.d/70-persistent-net.rules and remove the two line referencing your old network card then reboot and your cards will be named correctly. Or just change /etc/network/interfaces to from eth0 to eth1 as appropriate.