Hello,
There are many configurable options when starting QEMU that are controlled by environment variables, and I'm trying to figure out how to pursuade LAVA v2 to set them.
As an example, configuring the host audio driver used by QEMU is set by running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to override the qemu-system binary used (it's conditional based on arch), but even a quick hack to allow it to be overriden[1], and adding the env as a prefix didn't because LAVA assumes the first item is an actual binary expected in $PATH. My attempt led to:
Invalid job definition Cannot find command 'QEMU_AUDIO_DRV=none qemu-system-x86_64' in $PATH
Seems like there should be a more general way to pass enviornment variables to QEMU that I must be missing. If there's not, would be the recommended way to add this feature?
Kevin
[1] diff --git a/lava_scheduler_app/tests/device-types/qemu.jinja2 b/lava_scheduler_app/tests/device-types/qemu.jinja2 index 786f53bdb30d..e7c265a3048b 100644 --- a/lava_scheduler_app/tests/device-types/qemu.jinja2 +++ b/lava_scheduler_app/tests/device-types/qemu.jinja2 @@ -41,7 +41,7 @@ actions: {% elif arch == 'arm' %} qemu-system-arm {% elif arch == 'amd64' or arch == 'x86_64' %} - qemu-system-x86_64 + {{ qemu_command|default('qemu-system-x86_64') }} {% elif arch == 'i386' %} qemu-system-i386 {% endif %}
With that change, I added
context: qemu_command: "QEMU_AUDIO_DRV=none qemu-system-x86_64"
to the job definition
On 20 July 2017 at 02:57, Kevin Hilman khilman@baylibre.com wrote:
Hello,
There are many configurable options when starting QEMU that are controlled by environment variables, and I'm trying to figure out how to pursuade LAVA v2 to set them.
It's not something which should be done with the QEMU device type because that is installed on the worker - it is not a device that can be reconfigured to suit test writers and much of the functionality of QEMU must remain off-limits when QEMU is running on the worker.
To have full control over QEMU, it will need to be a test job which runs on a test device with virtualisation support (x86 or mustang etc.) where there is full control available over the environment, the build of QEMU, patches, configuration and command line.
As an example, configuring the host audio driver used by QEMU is set by running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
The worker is typically a server, it might not have any audio support. Even if it does, that functionality is off-limits to test writers. The available options to QEMU must be tightly constrained to protect other tasks on the worker.
Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to override the qemu-system binary used (it's conditional based on arch),
This is deliberate, to protect the worker from aberrant processes and to give the admins sufficient control over how the worker behaves.
but even a quick hack to allow it to be overriden[1], and adding the env as a prefix didn't because LAVA assumes the first item is an actual binary expected in $PATH. My attempt led to:
Invalid job definition Cannot find command 'QEMU_AUDIO_DRV=none qemu-system-x86_64' in $PATH
Seems like there should be a more general way to pass enviornment variables to QEMU that I must be missing. If there's not, would be the recommended way to add this feature?
No. This is not something that the worker can support. It needs to happen only on a test device. The worker is not itself a test device.
Create a standard test job on x86 or mustang or some other device with enough resources to run QEMU in the way you desire. Deploy and boot that device, let a normal test shell definition do the setup to get the appropriate build/version of QEMU, configure it exactly as desired and then execute it inside the test shell. Secondary connections can be used to be able to monitor different outputs or to connect directly to the booted virtual machine.
-
Kevin Hilman -
Neil Williams