oVirt is a virtualization platform aimed for management of virtual machines, storages and virtualized networks. The goal of this GSoC project is to improve oVirt system tests component. The system tests component should be extended with as many new tests as possible to cover different situations. Writing tests is a perfect way to understand the project. It eases the learning of the way oVirt project works and the reasons why it doesn't work sometimes. The acquired knowledge also would be useful form me in the future.
The first problem I faced was a test that should check that increasing number of CPUs in running VM from 1 to 2 works correctly. There were some problems with it:
- Building stable version of ovirt-system-tests. This project based on nested virtualization and as result it requires careful system settings tuning.
- Finding an approach to verify this correctly. Lago uses API for setting and getting VM's CPUs number. However, more reliable way to test it is to connect to VM via ssh and to ask VM directly it's CPUs number. There are some problems with network settings in Lago, that's why accessing non-host VM via ssh became a separate complex test.
The code of this test was accepted to project: Hotplug CPU
The next step was the coding of many different simple tests. All these tests are listed next and are all merged (name is clickable to view code):
-
Next Run unplug CPU CPU hot unplug works in oVirt for some kind of OS that supports it, but it is also possible to change CPUs number after rebooting of virtual machine. This test checks it and is OS-independent. This became possible after changing the high availability setting. Later we will be able to enlarge tests number here because reboot is a long operation, it takes a time. According to oVirt team, all tests should be completed within no more than half an hour. But a single check of cpu unplugs is a basic test with reboot.
-
Template Updating The part of oVirt system is a storage of VM's templates. The
name,description,type,memory,cpu,topology,os,high_availability,display,stateless,usbandtimezoneelements can be updated after a template has been created. This test verifies wheither template update doesn't fail and that the update actually changes something. It usescommentelement for this check. -
Hotplug Memory Next test checks hot increase in memory while running VM. The increasing of any field (such as CPU, memory, etc.) must be agreed with host settings and it's capabilities. Basic suite of oVirt-system-tests creates two hosts. For this test the amount of resources on both hosts is crucial because one of the subsequent tests is VM migration from one host to other. As a result, base memory was decided to be decreased first and then to be restored in this test scenario.
-
VMPools: create, edit, remove oVirt has a system for management of same VMs named VMPools. This is a set of 3 tests: creating a pool with one VM, editing some setting of this pool and this pool removal. It is also the base for various interesting tests that available only for pools. One of them is the next test of editing template version.
-
Edit template version of vmpool This is an interesting feature of VM pools. The template used for creating a basic VM (not in pool) must be used for a pool (it then marks as used last template version). It is possible to update later some of the basic VM's settings (for example, it is a memory in this test) and to create a new version of template as a snapshot of the basic VM. After that, corresponding settings should change in pool's VMs.
-
HA recovery oVirt has an option for VM named 'high availability'. For VM with high availability system guarantees that this VM will be recovered if it has crashed due to failure. This test checks if this high availability VM recovers after killing VM processes in command line at the host VM.
-
SSH to non host vm. This test is unmerged in the moment. The main problem is that ip address for ssh in this VM is hardcode, but this ip is not stable. Unfortunately, it is impossible to set static ip for VM's nic interface or to ask the system about VM nics in the current version of Lago. And after my mentor and I have researched for a solution to this problem, we found some bugs within network configuration. Now the other team members are trying to fix this problem.
-
Cluster compatibility version It is the biggest test in summer project. This test is not in basic suite of oVirt, but in engine-upgrade tests scenarios. To develop this test many of the system-tests scenario files should be changed. Each VM is created as a part of one of oVirt clusters. Each cluster has a compatibility version of system (one of 3.6, 4.0, 4.1 or 4.2 now). This test checks that cluster upgrade works correctly and the compatibility versions of all VMs in this cluster change as they should. Test checks this for both down and up VMs. At the moment this test verifies it for updating from 4.1 compatibility version to 4.2 but it may be extended to updating step by step from first oVirt version (3.6) to last (4.2 now).
oVirt has many interesting features and Lago is a good tool for other python projects decided to use oVirt. It is great that written tests appear to describe python-scenario of how the tested features work. For example, template version updating scenario was not evident for me at first. Many of this tests differ significantly from the first impractical version of scenario. Most tests I developed due GSoC project check previously untested oVirt features. Of course, it is not enough for system-tests. There are many other scenarios that are not covered by the submitted tests. The more tests have been written, the more opportunities for other scenarios using these tests are revealed.