KVM

From KVM

Contents

Getting started with KVM testing

This article intends to be a guidance for folks new to the KVM test.

Notes

  • Currently supported OS platforms are: Debian/Ubuntu, Red Hat/Fedora (if packages are needed)
  • It is recommended to have at least 50GB of free disk space prior to installation (to test all guests).
  • Make sure you have python 2.4 (or higher) installed.
  • Do this all as root (or at least run the tests as root)
  • Tested on Fedora 10/11/12

Install Prerequisite packages

On RHEL hosts run first:

rpm -ivh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

(It is important to note that EPEL is needed with the sole purpose of providing a git RHEL package)

Install the following packages:

yum install git

So you can checkout the source code.

yum install qemu-kvm qemu-kvm-tools syslinux

The qemu-kvm-tools package provides the kvm_stat profiler used to generate debug data for the tests. syslinux is essential to get guest os install working, qemu-kvm-tools is essential to get the tests working (core for a profiler).

yum install python-imaging

Not vital, but very handy to do imaging conversion from ppm to jpeg and png (allows for smaller images).

yum install git gcc kernel-devel SDL zlib gnutls make bridge-utils alsa-lib SDL-devel alsa-lib-devel zlib-devel pkgconfig libgcrypt-devel dev86 iasl

Those other packages are needed if you are going to build kvm from source.

Get autotest

After the upstream merge, we're doing all autotest development on autotest upstream. For folks that do like git, we have a git tree mirroring the current autotest development branch (svn trunk)

cd <your preferred directory>
git clone git://github.com/ehabkost/autotest.git

For the impatient

Run the script get_started.py, located inside the kvm test directory:

cd <autotest_root>/client/tests/kvm
./get_started.py

This script will help you to get started, using the KVM test default set. Now, it's important to understand what we chose to run as the default set:

  • Guest OS: Fedora 12
  • OS install, boot, shutdown tests
  • The test will try to use the installed qemu-kvm and qemu-img on your system, located under /usr/bin.

The defaults are intended to help you to get started as soon as possible. Of course, if you want to experiment you need to edit the configuration files. The script will offer to download the iso files, in case it can't find a correct iso file where it expects the file to be. Here is an example execution of the script:

[lmr@freedom kvm]$ ./get_started.py 
10:20:02 INFO | KVM test config helper
10:20:02 INFO | 1 - Verifying directories (check if the directory structure expected by the default test config is there)
10:20:02 DEBUG| Creating /tmp/kvm_autotest_root/images
10:20:02 DEBUG| Creating /tmp/kvm_autotest_root/isos
10:20:02 DEBUG| Creating /tmp/kvm_autotest_root/steps_data
10:20:02 INFO | Do you want to setup NFS mounts for some of those dirs? (y/n)
n
10:20:09 INFO | 2 - Creating config files from samples (copy the default config samples to actual config files)
10:20:09 DEBUG| Creating config file /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/address_pools.cfg from sample
10:20:09 DEBUG| Creating config file /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/build.cfg from sample
10:20:09 DEBUG| Creating config file /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/cdkeys.cfg from sample
10:20:09 DEBUG| Creating config file /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/tests_base.cfg from sample
10:20:09 DEBUG| Creating config file /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/tests.cfg from sample
10:20:09 INFO | 3 - Verifying iso (make sure we have the OS iso needed for the default test set)
10:20:09 WARNI| /tmp/kvm_autotest_root/images/linux/Fedora-12-x86_64-DVD.iso not found or corrupted
10:20:09 WARNI| Would you like to download it? (y/n)
n
10:20:13 WARNI| Missing file /tmp/kvm_autotest_root/images/linux/Fedora-12-x86_64-DVD.iso. Please download it
10:20:13 INFO | 4 - Checking if qemu is installed (certify qemu and qemu-kvm are in the place the default config expects)
10:20:13 DEBUG| /usr/bin/qemu-kvm present
10:20:13 DEBUG| /usr/bin/qemu-img present
10:20:13 INFO | 5 - Checking for the KVM module (make sure kvm is loaded to accelerate qemu-kvm)
10:20:13 DEBUG| Running '/sbin/lsmod'
10:20:13 DEBUG| KVM module loaded
10:20:13 INFO | 6 - Verify needed packages to get started
10:20:13 INFO | Please take a look at the online documentation http://www.linux-kvm.org/page/KVM-Autotest/Client_Install (session 'Install Prerequisite packages')
10:20:13 INFO | When you are done fixing eventual warnings found, you can run the kvm test using the command line AS ROOT:
10:20:13 INFO | /home/lmr/Code/autotest-svn/trunk/client/bin/autotest --verbose /home/lmr/Code/autotest-svn/trunk/client/tests/kvm/control
10:20:13 INFO | You can also edit the test config files (see output of step 2 for a list)

As you can see, the test copied the sample config files (.cfg.sample) to actual config files (.cfg). If you want to check out all the dictionaries with test params generated (1 dict per test that will be actually executed), execute:

./kvm_config --verbose

And watch all the dictionaries produced. Each dictionary is a set of parameters for one particular kvm test instance. Note that the parser can parse any config file that is valid and follows its syntax:

./kvm_config --verbose -f /path/to/cfgfile

Running the test

The autotest client parses a control file and executes the tests and operations defined on a control file, so calling it is as easy as executing

/path/to/autotest /path/to/control_file

The output of get_started.py will give you the full command for your convenience. The control files present on each client test directory are usually sample control files, but for the KVM test we can use the shipped control file to perform testing, since most of the test data is located on the config files.

You will see a wealth of messages during your test execution. Don't worry with all of the output for now. When the kvm tests are being executed, the test harness will indicate so. If you want to perform further log checking, remember:

  • Test results are written to client/results/default*
  • You can parse the results and see a nice textual output from your current test execution by executing
./scan_results.py
  • The log files can be found at testname/debug, you will see one file for each debugging level, so jumping right to testname.DEBUG might be a good idea.

More about machine setup - Bridges

The above setup will work OK as long as you wish to have the qemu test to run using user networking (vm is on an internal private network, and has dhcp and other network services provided by qemu).

However in real world users will want to use bridge networking. Previous versions of the kvm test used to automatically configure bridge for the users. However, that was considered to be too intrusive and abandoned.

Now the user have to provide that configuration. In order to help on that process, here is a sample kickstart file that we use to configure hosts. You can adapt it to your needs:

install
url --url=[replace-with-installation-repo]
text
reboot
lang en_US
keyboard us
network --bootproto dhcp
rootpw 100yard-
firewall --disabled
selinux --disabled
timezone --utc America/New_York
firstboot --disable
bootloader --location=mbr
zerombr
clearpart --all --initlabel
autopart
%packages
@base
@core
@development
@virtualization
@basic-desktop
git
gcc
make
dev86
iasl
pkgconfig
SDL
zlib
gnutls
kernel-devel
SDL-devel
alsa-lib
alsa-lib-devel
zlib-devel
libgcrypt-devel
bridge-utils
qemu-kvm-tools
tigervnc-server
syslinux
%post
set -x -v
exec 1>/root/ks-post.log 2>&1
# Start post install kernel options update
/sbin/grubby --update-kernel=`/sbin/grubby --default-kernel` --args="console=ttyS0,115200 "
# End post install kernel options update
/sbin/chkconfig NetworkManager off
/sbin/chkconfig network on
echo "[replace-with-nfs-server]:/mnt/data/autotest/iso /tmp/kvm_autotest_root/isos nfs defaults 0 0" >> /etc/fstab
echo "[replace-with-nfs-server]:/mnt/data/autotest/steps_data  /tmp/kvm_autotest_root/steps_data nfs rw,nosuid,nodev,noatime,intr,hard,tcp 0 0" >> /etc/fstab
mkdir -p /tmp/kvm_autotest_root/isos
mkdir -p /tmp/kvm_autotest_root/steps_data
mkdir -p /tmp/kvm_autotest_root/images
echo "Checking interface that will be used to perform bridge setup"
INTERFACES=$(/sbin/ifconfig | grep eth | awk -F " " '{ print $1 }')
ETH=""
for i in $INTERFACES
do
  HAS_IP=$(ifconfig $i | grep "inet addr")
  if [ -n "$HAS_IP" ]
  then
    ETH=$i
  fi
done
if [ -z "$ETH" ]
then
  ETH="eth0"
fi
echo "Interface chosen to perform bridge is $ETH"
MAC=$(/sbin/ifconfig | grep $ETH | grep HWaddr | awk -F " " '{ print $5 }')
echo "r$ETH $MAC" > /etc/mactab
cat > /etc/init.d/kvmbridge << EOF
dhclient -r $ETH
ip addr flush $ETH
ip link set $ETH down
nameif
ip link set r$ETH up
brctl addbr $ETH
brctl addif $ETH r$ETH
ip link set $ETH up
dhclient $ETH
EOF
chmod +x /etc/init.d/kvmbridge
ln -s /etc/init.d/kvmbridge /etc/rc3.d/S11kvmbridge

More about setup - windows testing

Windows testing needs an auxiliary CD (winutils.iso) in order to perform setup steps and assisting with some tests. We plan on shipping such a CD soon, but it's good to have the documentation on how to build winutils.iso here.

The iso contains:

So you have to throw all of them at the a directory, say winutils, and generate a CD:

genisoimage -o winutils.iso -max-iso9660-filenames -relaxed-filenames -D --input-charset iso8859-1 winutils

As for the binary applications shipped with the KVM test, here we also leave documentation on how to build them on your own. Obviously a very valid way of building the helper windows applications shipped is to:

  • Pick up a windows box, or windows VM
  • Install mingw on it
  • Compile the code

However, Fedora 11 and later ships a functional cross compilation environment, to compile windows applications (therefore I never tested the above outlined procedure). Compiling the applications under Fedora 11 is fairly straightforward. Make sure the cross compilation packages are installed:

yum install mingw32-gcc mingw32-gcc-c++ mingw32-w32api

To compile finish.exe:

i686-pc-mingw32-g++ finish.cpp -lws2_32 -o finish.exe

To compile rss.exe:

i686-pc-mingw32-g++ rss.cpp -lws2_32 -mwindows -o rss.exe

Test structure

Understanding the test structure better might help to understand the preparation steps better and therefore, making the whole process smoother, so you are advised to keep reading this session.

The KVM test is a regular autotest client test, but it has some distinctive characteristics, such as:

  • It's larger than the average autotest client test, and it has a significantly higher amount of files.
  • It has its own configuration files and configuration system

Top level files

  • kvm.py: This is the actual autotest kvm test class. As the KVM test spans through subtests, this is just a class that loads the kvm subtests, located under the tests directory accordingly.
  • control: The autotest control file. This is what the autotest client will parse in order to execute your set of tests. It is pretty much a python program and it supports all python syntax. The only thing you might find a bit weird is that the autotest client automatically brings into the control file namespace some names and objects that you don't see explicitely loaded in the file itself. Don't worry with this.
  • kvm_config.py: Test configuration parser and debugger. Prior to test execution, you can check what test configurations your config file yields by running it as a stand alone program.
  • address_pools.cfg.sample: Sample configuration file containing IP and mac address ranges for the VMs that will be used by the test in case you use TAP device mode for VM networking.
  • build.cfg.sample: Sample configuration file containing parameters for the build test. The build test is disabled by default.
  • cdkeys.cfg.sample: Sample configuration file containing CD keys. * tests_base.cfg.sample: Library with test functions.
  • tests.cfg.sample: Sample main configuration file.
  • kvm_preprocessing.py: Utility functions to create vms, and eventually modify their internal set of options.
  • kvm_subprocess.py: Library to control subprocesses attending to the very special needs of the kvm testing framework. It's mainly used to control qemu, even though it can be used by any subprocess.
  • kvm_vm.py: Contains the representation of a KVM based virtual machine. It implements its methods mainly by controlling and manipulating qemu processes.
  • kvm_utils.py: Utility functions.
  • kvm_test_utils.py: Higher level test utility functions.
  • ppm_utils.py: Utility functions to deal with ppm files (qemu screendump image files).
  • cd_hash.py: Program to calculate several types of hashes (md5, sha1) for CD images (well, in fact it could be used by any file).
  • common.py: Allows all stand alone programs inside this dir to load the autotest library.
  • html_report.py: This is a simple program that can parse autotest results and create a fancy (and static) HTML file with a structured execution report.
  • scan_results.py: Can scan autotest result directories and generate a textual results report.
  • step_editor.py: GTK+ application that can load and edit step files.

Subdirectory structure - static (part of the source distribution)

  • tests: Contains the KVM subtests. As tests are where the actual action happens, there's a special session of documentation for them, please access KVM-Autotest/Tests for more information.
  • scripts: Contains scripts that will be used to perform environment setup for some kvm subtests. Those scripts should be written in python when possible.
  • unattended: Contains unattended install files (kickstart for red hat based distros, answer files for windows). Unattended install is the default and preferred OS install method.
  • steps: Contains step files (those describe the OS install process for one of the guest OS install methods).
  • autoit: Contains scripts for the Windows GUI testing automation system autoit (http://www.autoitscript.com/autoit3/). It's used by the autoit kvm subtest.
  • autotest_control: Contains autotest control files that we desire to run on guests, used by the autotest subtest.
  • deps: Contains dependencies created specially for kvm testing. The rss remote shell for communication with windows guests is an example of external dependency.

Subdirectory structure - static (user have to provide)

  • isos: Contains iso files used to install operating systems on KVM guests. You need to provide a location with the needed CDs (you can figure out what those are by looking into the configuration file), either by symlinking an nfs share on your system with the CDs or any other method you rule as being convenient.
  • images: Will hold the virtual machine disk images that the test will generate as it is being executed. Please provide a location on your filesystem with plenty of space for kvm test usage.

Subdirectory structure - dynamically generated

  • src: qemu and kvm source code will be downloaded to this folder, provided that you run the build test.
  • build: If you choose to run the build test, KVM will be installed to this location and symlinks will be created accordingly.
Views Article Discussion Edit History
Personal tools:  Log in / create account
Toolbox What links here Related changes Upload file Special pages Printable version