Experimental Virtual Machines

Written by Barry Warsaw in technology on Mon 07 June 2010. Tags: canonical, python, ubuntu,

I'm doing some work these days on trying to get Python 2.7 as the default Python in the next version of Ubuntu, Maverick Meerkat (10.10). This work will occasionally require me to break my machine by installing experimental packages. That's a good and useful thing because I want to test various potentially disruptive changes before I think about unleashing them on the world. This is where virtual machines really shine!

To be efficient, I need a really fast turnaround from known good state, to broken state, back to known good state. In the past, I've used VMware Fusion on my Mac to create a VM, then take a live snapshot of the disk before making my changes. It was really easy then to revert to the last known good snapshot, try something else and iterate.

But lately Fusion has sprouted a nasty habit of freezing the host OS, such that a hard reboot is necessary. This will inevitably cause havoc on the host, by losing settings, trashing mail, corrupting VMs, etc. VMware can't reproduce the problem but it happens every time to me, and it hurts, so I'm not doing that any more :).

Back to my Lucid host and libvirt/kvm and the sanctuary of FLOSS. It's really easy to create new VMs, and there are several ways of doing it, from virt-manager to vmbuilder to straight up kvm (thanks Colin for some recipes). The problem is that none of these are exactly fast to go from bare metal to working Maverick VM with all the known good extras I need (like openssh-server and bzr, plus my comfortable development environment).

I didn't find a really good fit for vmbuilder or the kvm commands, and I'm not smart enough to use the libvirt command line tools, but I think I've figured out a hack using virt-manager that will work well enough.

  1. Create a disk for the baseline VM (named 'scars' in my case :) manually:
% qemu-img create -f qcow2 scars.qcow2 20G
  1. Create the baseline VM using virt-manager:
    • I use dhcp internally, so I give this thing a mac address, assign it 1GB of RAM and 1 processor.
    • For storage, I tell it to use the scars.qcow2 file I created above.
    • Boot from the Maverick ISO of your choice, install everything you want, and get your development environment in place
    • Shut this machine down
  2. Clone your baseline VM:
    • In the virt-manager Manager window, right click on your baseline VM and select "Clone".
    • You will not be given an opportunity to select a disk or a mac address, so for now just go with the defaults.
    • Do not start your clone
  3. Create an 'overlay' disk that is a backed by your baseline disk:
% qemu-img create -f qcow2 -b scars.qcow2 scars.ovl
  1. Edit your clone:
    • Delete the disk given to your clone by default.
    • Create a new virtio storage that points to scars.ovl.
    • Delete the nic given to your clone by default.
    • Create a new virtio network device with the mac address of your baseline. You'll get a warning about a mac address collision, but this can be ignored (see below).
  2. Boot your clone.

At this point you'll have a baseline which is your known good system, and a clone/overlay which you can break to your heart's content. When it's time to iterate back to a known good state, shut down your clone, delete the overlay disk, and create a new one from the baseline qcow2 disk. This is pretty fast, and your turn around time is not much more than the time it takes to shutdown one machine and boot another. It actually feels a lot faster by the wall clock than Fusion ever was to snapshot and restore.

One downside is that you cannot run both VMs at the same time. I think mostly this is because of the MAC address collision, but also because creating the overlay requires that both machines be powered off.

The other downside seems to be that if you want to update your known good baseline, say by installing more packages or apt-get update/upgrade, you will have to recreate your overlay disk for your next experiment. Changes to the underlying disk do not seem to propagate to the overlay automatically. Maybe that's intentional; I can't find much documentation on it. (Note too that the manpage for qemu-img does not describe the -b option.)

I guess the last downside is that I spent way too much time trying to figure all this out. The Googles were not a lot of help but did give me the qemu-img clue. But at least now you don't have to! :)

Comments

comments powered by Disqus