Writing Avocado Virt Tests

Basic example: Boot test

Avocado virt tests are similar to non-virt ones, they only differ on that they use some specialized libraries, that let you use special virt features.

Here’s an example of a basic virt testing, a test that starts QEMU with a guest image, then it’ll try to establish an ssh connection to this guest:

from avocado.virt import test


class BootTest(test.VirtTest):

    def test_boot(self):
        self.vm.power_on()
        self.vm.login_remote()

    def tearDown(self):
        if self.vm:
            self.vm.power_off()

The base class for the test is avocado.virt.test.VirtTest instead of the base avocado.test. The reason for this is that the VirtTest class can make the params from the test runner available for tests, and provide other convenience methods for your tests.

If you chose to not override or extend the default virt test setUp() method, you’ll have at your disposal a basic vm object in self.vm. The VM is not started (powered on) yet, and you need to start it yourself. Calling self.vm.power_on starts the QEMU process, then from that point forwards we are just waiting for the VM to be active. The proof that the VM started and the guest OS is healthy is that we can establish a remote session (SSH on linux guests) to it, by using the login_remote method. That method is going to wait for a default 60 seconds until the SSH connection is established, and fail in case the connection can’t be established.

If we have an SSH connection, all is good, the test passed, and we’re going to clean things up as a good practice. The cleanup method is going to run a shutdown command in the remote connection, and then we proceed to shutting down the VM (end the QEMU process), through the power_off method.

If that goes fine as well, the test passed and everybody is happy. We ended our test with PASS. If any of the operations described above FAIL, avocado is going to proceed accordingly and FAIL the test.

Basic example: Migrate test

Now, what if I want to migrate the state of a QEMU VM to another QEMU process on that very same machine? Here’s what a live migration test looks like:

from avocado.virt import test


class MigrationTest(test.VirtTest):

    def test_migrate(self):
        self.vm.power_on()
        migration_mode = self.params.get('migration_mode', 'tcp')
        for _ in xrange(self.params.get('migration_iterations', 4)):
            self.vm.migrate(migration_mode)
            self.vm.login_remote()

    def cleanup(self):
        if self.vm:
            self.vm.power_off()

Fortunately, most of the migration logic is wrapped up in the method vm.migrate. Here we modeled things after the concept of live migration, so you have a single vm object, that when migrated keeps working just as it did work before, with no service interruption (it doesn’t care that the VM state was passed on to another QEMU process). The method will clone the command line of the current VM, add the appropriate snippets for incoming migration, start the new process, and call the appropriate migrate command in the QMP monitor of the source VM. After it detects the migration is over, we might repeat the process again migration_iteration times (here it has the default value of 4).

More to come

This is a basic guide, as the plugin is in heavy developmemt. Soon we’ll have more APIs and cover more cases.