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:
- VLC media player - http://www.videolan.org/vlc/
- The creative commons film "The Elephant's Dream" (theora video file) - http://orange.blender.org/download
- Autoit, a gui test automation framework for windows - http://www.autoitscript.com/autoit3/downloads.shtml
- rss.exe (shipped on kvm test source distribution, under deps/ folder)
- setuprss.exe (shipped on kvm test source distribution, under deps/ folder)
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.

