A little while ago now I wrote about the initial libvirt TCK (Technology Compatability Kit): http://www.mail-archive.com/libvir-list@redhat.com/msg12703.html Since that time, it has moved on somewhat and I am regularly running it during development & immediately before release. It has caught a large number of bugs and was very helpful porting QEMU to the JSON mode monitor and -device syntax First and foremost, I moved the source repository to libvirt.org after we switched to GIT http://libvirt.org/git/?p=libvirt-tck.git The list of Perl module pre-requisites is still accurate as per the original mail. To simplify its use, it is now possible to run it on a system which you already have VMs on. The only restriction is that none of your virtual machines, storage pools, networks etc have a name that starts with the string prefix 'tck'. The test suite will complain & refuse to run if it finds any clashes. The --force option will tell it to blow away your existing VMs with names matching 'tck*'. I still, however, only recommend its use on machines that you don't care about. While I make reasonable effort not to trash your system, this kind of testing always has a fairly high level of risk / danger, either from bugs in libvirt, the HV, or the TCK itself. For many of the tests you can actually run within another virtual machine. eg, I have a Fedora 12 host, on which I run KVM. For running TCK tests, I installed a Fedora 12 guests, and then run the TCK in this. Obviously you won't be testing anything that requires hardware virt this way, but it is good enough for the vast majority of tests so far. It also makes it easy to setup tests against a large number of different OSs. It is no longer neccessary to manually download kernels/initrds. The test suite knows where to grab kernels/initrds off the interweb for Xen and any fullvirtualization. It uses the hypervisor capabilities data to determine the best kernels to use, and if it detects container based virt will setup a busybox chroot for testing instead. It will also create any disk images it needs, usually as sparse files, but sometimes as full files. The config file controls where these are created if you are short on space There are now somes tests which require access to hardware, so the config file allows the admin running the TCK to specify any disks, USB devices,m and PCI devices that can be used. If none are specified, any tests that require them are skipped automagically. Again, testing within a virtual machine makes this easy. Just add 4 extra PCI nics and a bunch of USB disks to your guests. You can then tell the TCK to play with them for its tests. The number of tests has increased sigificantly * domain/030-dominfo.t The virDomainGetInfo API works * domain/050-transient-lifecycle.t Basic lifecycle operations on transient guests * domain/051-transient-autostart.t Verify autostart is blocked on transient guests * domain/060-persistent-lifecycle.t Basic lifecycle operations on persistent guests * domain/061-persistent-autostart.t Verify autostart is allowed on persistent guests * domain/065-persistent-redefine.t Verify a persistent guest config can be updated * domain/070-transient-to-persistent.t Conversion of transient guests to persistent guests * domain/080-unique-id-define.t * domain/081-unique-id-create.t Verify name/uuid/id uniqueness when creating / defining guests * domain/090-invalid-ops-when-inactive.t Get suitabe errors for APIs which should not run on inactive guests * domain/100-transient-save-restore.t * domain/101-persistent-save-restore.t Save/restore to/from files for guests * domain/102-broken-save-restore.t Verify a nice error message for delibrately corrupt save files * domain/120-disks-stats.t The disk IO stats reporting * domain/200-disk-hotplug.t Basic hotplug of disks * domain/205-disk-hotplug-ordering.t Ordering of disks when hotplug different types (virtio/scsi) * domain/210-nic-hotplug.t Basic NIC hotplug * domain/215-nic-hotplug-many.t Hotplug of many NICs * domain/240-usb-host-hotplug.t USB hostdevice assignment to guests, by vendor/product and dev/bus * domain/250-pci-host-hotplug.t PCI hostdevice assignment to guests * qemu/100-disk-encryption.t A QEMU specific test for qcow2 disk encryption * storage/100-create-vol-dir.t Create of all types of files in a directory pool * storage/110-disk-pool.t Operation of the disk pool type (ie adding/removing partitions) * storage/200-clone-vol-dir.t Cloning of disk volumes There is of course scope for many many more tests to be added. Not least for storage we have NFS, iSCSI, SCSI, filesystem pools, LVM. The entire of the network interface APIs. Many more aspects of guest domain mgmt. Host devices, etc There is also work to be done to ensure the tests are fully portable across hypervisors. I've only really tested with QEMU/KVM, and to a lesser extent Xen and LXC. Running the tests is quite simple - Install the pre-requisite Perl modules (all in Fedora 12 and other distros) - Get a GIT checkout of the libvirt-tck - Build it perl ./Build.PL ./Build - Take the default config file conf/default.cfg in source tree, or5B /etc/libvirt-tck/default.cfg after installation and set the hypervisor URI. Optionally list some usb, pci & block devices if available for testing - Run it libvirt-tck -c /path/to/your/config.cfg The '-v' flag prints detailed progress info. The '-t' flag lets you point it to a single test script to avoid running all of them every time It is possible to run without installing it too export PERL5LIB=$TCK_GIT_TREE/lib perl $TCK_GIT_TREE/bin/libvirt-tck -c my.cfg -t $TCK_GIT_TREE/scripts Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|