In anticipation of the upcoming KVM Autotest Install Fest I thought I’d get a bit of a head start on the basic autotest install so I can spend the day doing fun things like actually writing some new tests!

In this post I will be documenting my own experiences/procedures in the basic setup for getting up and running with autotest. In a follow-up post I will be documenting my experiences in writing my own kvm-autotest tests.

For this installation we’ll be doing the basic autotest client install, which is simple setup for running autotest tests on single host. There’s also a server installation, which we won’t go into here. My host is Ubuntu 10.04 Lucid, so I’ll be focusing on that. Your results may vary, but hopefully most of these items will be generally applicable.

INSTALL:

For the install, we’ll be following the instructions here fairly closely:

There’s a get_started.py script that will handle basic setup for you. This consists mainly of creating required directories in /tmp, copying the sample config files over to expected config locations, verifying qemu-kvm and qemu-img are at the expected locations, and confirming that a Fedora 14 ISO (the guest used for default installs) can be obtained via web. Unfortunately it was written specifically for Fedora and will break on Ubuntu. But there’s not a whole lot going on here, so we’ll walk through the steps manually.

– Create required folders.

You can change these, but unlike most configuration directives, these aren’t very easy to overwrite since they’re declared in multiple config/control files.

Before you start, I’d recommend creating a new branch in autotest.git…autotest is a complex framework, and you may find yourself needing to tweak the source here and there for your particular setup, so tracking these changes in your own branch will ensure you don’t end up with a Frankenstein you can no longer keep in sync with upstream. Creating your own branches for any tests/control files you add will be useful in this regard as well, making it easier to track your local changes and get your tests upstream if you think they’ll be generally useful.

cd ~/dev/kvm/autotest.git/client/tests/kvm
git checkout -b local1

– build.cfg

This file specifies parameters for the kvm build/install test. There are templates here for doing builds/installs from git, release tarballs, yum, etc. This is useful if you’re testing modifications to qemu (build/source code changes, regression testing, etc). By default this test is skipped, so if that’s sufficient you just need to copy over the template:

cp build.cfg.sample build.cfg

For our simple example, I don’t actually need to build a modified qemu binary. But I may want to if I need to test changes to qemu, and Ubuntu 10.04 uses a fairly outdated version of qemu-kvm (0.12.3), so I’d prefer pointing to a fresh build anyway. Autotest actually supports building from local source, or a git repo, as part of the test procedure, but I ended up needing to modify the autotest.git source code to actually get it working, and beyond that there are a few annoying quirks. And after working through those, I was somewhat dismayed to find that there was no way to pass configure options in to the build procedure without further source code modification. This might not be a huge deal with qemu-kvm.git since it has KVM-centric default config options, but, with qemu.git, being able to specify –target-list=x86_64-softmmu to avoid building a bajillion emulated target platforms, and specifying –enable-io-thread, are really important. I may work through these issues and get some patches to the autotest folks in the future, but for now I’ve resorted to pointing autotest to the binaries sitting in my local git repo and handling the build process myself. So the default build.cfg is sufficient for now, and we’ll set the paths to our binaries elsewhere.

– cdkeys.cfg

This file specifies CD keys that may be required for automated installs of your ISOs. Not needed in my case but we’ll go ahead copy over the sample:

cp cdkeys.cfg.sample cdkeys.cfg

– tests_base.cfg

Again, mostly defaults here. You shouldn’t need to mess with these too much as the more important parameters can be overwritten in tests.cfg. Eventually you should set some sane defaults here as the requirements for your setup become clearer however. I did need to modify the default path to my RHEL6 ISO:

Now to the heart of it: defining an actual test. You’ll see some examples in tests.cfg.sample which include some default tests for install/boot/shutdown for Fedora, as well as a deceptively simple looking “@full:” entry will will basically run all tests for all permutations of guest/guest setup. At least it would seems that’s the case, perhaps some heuristics (only ISOs you actually have present, etc) are used to cull things down somewhat. Not gonna try it, personally, but be my guest!

In our case we just want to do a simple install/boot/shutdown test of RHEL6 to make sure everything is set up properly (feel free to plug in the distro of your choice, the Fedora 14 default is probably a good choice for most). The default “@qemu_kvm_f14_quick” entry serves as a good starting point. Poking around in tests_base.cfg we see there’s a “RHEL” variant of the “Linux” guest type, and a “6.x86_64” variant of that, so in place of “only Fedora.14.64” we’ll use “only RHEL.6.x86_64”. Since in this case we’re using binaries from a local qemu.git repo, we’ll also modify qemu_binary, qemu_img_binary, and add some extra params to pass to qemu to enable kvm and specify a bios image from the repo.

Here’s the diff between tests.cfg.sample and the tests.cfg I ended up with: