ISO testing with KVM

KVM is a virtual machine emulator similar to VirtualBox, Vmware, and others. It is currently the preferred free virtualisation technology in Ubuntu.

See https://help.ubuntu.com/community/KVM for general information on installing and setting up KVM.

Creating disk images

For ISO testing, it is necessary to create a new virtual disk or machine for every test. This can be done with the virt-manager GUI, or from the command line:

qemu-img create -f qcow2 foo.qemu 100G

The above command will create a 100 gigabyte virtual disk, stored in the foo.qemu file. The file will only use space for the parts of the virtual disk that get written on. Check the size with du, not ls, and you will see the actual disk usage rather than the length. (See sparse files in Wikipedia for details.)

It is handy to have a large virtual disk, so that your installation test won't run out of space.

The qcow2 format is better than the default raw format since it allows snapshotting.

Naming

If you have the hardware resources, you can run several tests in parallel. To keep track of which window is which, it's a good idea to give each machine a distinct name.

If you run kvm from the command line, use the --name option.

Copying logs, etc, out from the virtual machine

When you run into a problem, it can be good to copy log files, or other files, out of the virtual machine. This can be done with ssh, as if on a real machine.

scp /var/log/syslog yourname@yourhost:syslog-failed

You will need a SSH server on "yourhost". This service is installed by the "openssh-server" package. Port tcp/22 will the be opened on your computer.

Snapshotting the virtual machine

Another handy thing you may want to do is make a snapshot of the virtual machine at the point where you notice the error. If you're using the KVM window, press control-alt-2 (not -f2!) to get to the KVM monitor, then type savevm bug to do the snapshot. This can take quite a while. When it's done, type q to quit KVM.

You can copy the disk image (foo.qemu) to a new file, then continue debugging with one of the copies. The other copy is then there and you can go back to it if your debugging messes something up. Think of this as version control of computers.

You can also send the disk image to someone else to let them have a look, and maybe find and fix the problem themselves. For this, you should compress. lzma seems to give the smalles results, but uses a lot more CPU cycles to do so. gzip gives most of the compression, with much less CPU usage. If you have a fast CPU, use lzma, otherwise gzip. Either way, even the compressed image can easily be hundreds of megabytes in size.