Tuesday, November 13, 2012

qemu init scirpt for gentoo

It's over a year ago since i've posted a gentoo init script for qemu guests. Privately i've updated and added features regularly. Now i've uploaded an updated version which has lots of changes and an easier configuration file.

The most notable changes/features are:
  • per default i'm using now the qxl video card for guests
  • for many options there are default's which the init-script would use if there are no settings
  • guests don't have to run as root, you can specify an different user
  • spice support (you can choose between vnc and spice)
  • qemu guest agent support (qga has to be installed in the guest)
  • snapshot mode, guests can run in an snapshot-mode where changes won't be saved.

init script start and stop
The script needs following packages to work:
  • app-emulation/qemu
  • sys-apps/coreutils
  • sys-apps/net-tools
  • sys-apps/grep
  • sys-apps/iproute2
  • sys-process/procps
  • net-misc/bridge-utils
  • net-analyzer/netcat6
Download the script: Link

Basically most of these packages should be already installed on any system. However, you must configure an bridge first otherwise networking wouldn't work. To install the script there are just a few steps to do. First, extract the file:
 tar xzf qemu-init-script.tar.gz -C /etc/init.d/  

Move the default.config to /etc/conf.d/:
 mv /etc/init.d/kvm.config /etc/conf.d/  

For every guest you have to create an symlink to the init script (example for a guest called windows7):
 cd /etc/init.d/  
 ln -s kvm.init kvm.windows7  

You also have to create an new config file for this windows7 guest:
 cd /etc/conf.d/  
 cp kvm.default kvm.windows7  

Afterwards you have to edit the config to your needs. Basically you must change at least VM_IMAGE and BRDEV. BRDEV is the name of your bridge and VM_IMAGE is the path to the image file or lvm2 partition.
For an new guest you also have to change the boot settings. VM_BOOT_DEV sets how to boot (network/disk/cdrom/floppy), while VM_CDROM should point to an iso file or a cd.
The rest of the config should be quite self explaining. Anyway, i've tried to explain all variables as good as possible.

Thursday, November 8, 2012

qemu lvm2 vs qcow2 benchmark

Playing around with virtual guests always takes quite some time when creating or copying images. Recently i've started looking for a good solution how to store virtual guests. I always vacillate between lvm2 partitions and qcow2 files. Both have their pros and cons. LVM2 is fast and you have the ability for live snapshots while qcow2 files are easy to maintain and and need less space.
Some time ago i already  started an benchmark where i compared the different cache settings on different filesystems + lvm. The result was the there wasn't a big gap between those filesystems and lvm2, though comparing build times isn't a real benchmark.
VM Details

Now i made another benchmark. This time i choose to use the phoronix-test-suite benchmark tool to see what's the difference between qcow2 on btrfs and lvm2. PTS has many good present for testing and i just used an default disk benchmark present. The vm was an typical minimal gentoo amd64 system where i also didn't had X or anything else running, so the result should be quite accurate. I choose to test it with btrfs because it also has an snapshoting feature which might be an alternative to lvm2 one day.

Converting an lvm2 image to qcow2 is pretty simple and is done via:
 qemu-img convert -O qcow2 /dev/vg/g64 /mnt/vms/g64.qcow2  

Below are the result. I was quite surprised because i though using lvm2 has an greater impact on performance. However, as you can see, at a few benchmarks qcow2 were even faster than lvm2.

green = lvm2red = qcow2

For me the biggest drawback of qcow2 and other file formats right now is the lack of an snapshot feature which i could use for creating live backups while the system is running. Even though qemu has an snapshot feature, this one isn't working for me.
I might have an deeper look into qemu's snapshot feature in the future, but for now i'll stay with lvm2. Disk space isn't a real problem and other than that i don't want to rewrite my backup scripts (again).