Virtual Machine Groups¶
Virtual machine (VM) groups are a special type of multinode test job, where dynamically allocated virtual machines participate in a single test job.
To submit a VM group test job, you need:
- a device that supports virtualization (at the time of writing Arndale and Versatile Express boards are known to have it).
- system images for the host system and for the VM’s’. The host system
image needs to include
openssh-server
. - the instance configured to support a
kvm-arm
device type.
A VM group test job consists of a vm_group
attribute, specifying
the host machine and a list of VM’s that will spawned on the host.
See Writing MultiNode JSON tests for more information on VMGroup test definitions. Virtual Machine groups are an extension of MultiNode, so the definition which would be resubmitted as a new VMGroup job will be the VMGroup Definition.
Example job definition:
{
"timeout": 18000,
"job_name": "vm-groups basic test case",
"logging_level": "DEBUG",
"vm_group": {
"host": {
"device_type": "arndale",
"role": "host"
},
"auto_start_vms": true,
"vms": [
{
"device_type": "kvm-arm",
"role": "server"
},
{
"device_type": "kvm-arm",
"role": "client"
}
]
},
"actions": [
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///path/to/host.img",
"role": "host"
}
},
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///path/to/host.img",
"role": "client"
}
},
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///path/to/host.img",
"role": "server"
}
},
{
"command": "lava_test_shell",
"parameters": {
"testdef_urls": [
"file:///path/to/mytestdef.yaml"
]
}
}
]
}
The host
section declares the device that will be used as host for
the VMs. Note the following requirements for system images used for host
devices:
- openssh server must come installed, with
sftp
support. qemu-system
must be installed (or at least the specific flavor that needs to be tested e.g.qemu-system-arm
)
The auto_start_vms
attribute is optional, and can be set to
false
to make LAVA not start the VM’s as soon as the host is
booted (the default value is true
). In that case, signaling LAVA
when the VM’s should be started becomes a responsibility of the test
writer: one has to include a call to lava-start-vms
at a point in
the test code where the VMs should be started, and another call to
lava-wait-vms
before the test code finishes to make sure that the
host will wait until the VM’s are done before allowing a reboot of the
host. Example:
#!/bin/sh
# work work work ... (e.g. build qemu from source)
lava-start-vms
# run tests on the host ...
# done, now wait for VM's to finish
lava-wait-for-vms
The vms
section contains an array of VM descriptions, which
will be used to instantiate the VMs on the host device. Each item in
that array must have the following mandatory attributes:
device_type
: the type of VM that should be spawned. For now the only supported value iskvm
, but it will be updated in the future to supportxen
as well.role
: like in regular multinode jobs, this indicates a label that will be associated with the given VM’s and can be used See Multi-Node LAVA (JSON) for more information. Always make sure you are clear on whatrole
is assigned to eachlava_test_shell
command. See Writing tests for virtual machine groups.image
: which image that should be used to boot the virtual machine. Note that you can also use thedeploy_linaro_kernel
action and use separate kernel/dtb/rootfs images.
There are additional parameters that can be used, but are optional:
count
: number of VM’s of that givenrole
to spawn. The default value is 1.launch_with
: a list of commands to be used in the host to spawn the VM. The last command in the list has to be the call that attaches to the VM console in the current terminal.shell_prompt
: the shell prompt of the VM, used by LAVA to identify that the VM finished booting.
Writing tests for virtual machine groups¶
The VMs will run on the host device and LAVA supports running LAVA Test Shell on the host and inside each VM.
- The host test shell will start and run its tests and then wait until all of the VM test shells have finished.
- If a second test shell command is given for the host, this test shell will only operate once all of the VMs have closed, allowing for tests to be run to check for a successful clean up on the host device.
- If the host device needs to run tests from multiple repositories, see Minimise the number of reboots within a single test.
- See Writing MultiNode JSON tests for more on how to communicate between the VM and the host using the MultiNode API.
- It is not possible to list one test shell for multiple roles, only
for a single role or all roles. If you have multiple tests to run on
different VMs, consider whether it is better to have multiple roles,
each with a
lava_test_shell
command or to combine the tests into one role and use the MultiNode API or other features to distinguish one VM from another.