Hi Neil, Kevin !
On 20 July 2017 at 02:57, Kevin Hilman <khilman at 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.
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.
A see. There is a valid point here in that there should not be control of the environment from the 'outside' though a job description.
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.
Now for the above case: QEMU_AUDIO_DRV=<option> qemu-system-*
I see this as a *very valid env var* for a server-side deployment - exactly as you said - a server does not have a sound card and QEMU_AUDIO_DRV=none is what we need to use there to prevent qemu from looking for a host sound card. We should even set this by default - we don't expect any sound to reach the worker - do we ;) ? I don't think so.
IMHO this should be an option set on the worker node in the lava- dispatcher.conf (e.g. LAVA_EXTRA_QEMU_ENV="QEMU_AUDIO_DRV=none"). Enable the admins to choose this.
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.
As I said, I think this belongs to the worker setup and we should enable the admins to make their choice.
Dipl.-Ing. Jan-Simon Möller
jansimon.moeller@gmx.de
On 20 July 2017 at 11:33, Jan-Simon Möller dl9pf@gmx.de wrote:
Hi Neil, Kevin !
On 20 July 2017 at 02:57, Kevin Hilman <khilman at 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.
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.
A see. There is a valid point here in that there should not be control of the environment from the 'outside' though a job description.
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.
Now for the above case: QEMU_AUDIO_DRV=<option> qemu-system-*
I see this as a *very valid env var* for a server-side deployment - exactly as you said - a server does not have a sound card and QEMU_AUDIO_DRV=none is what we need to use there to prevent qemu from looking for a host sound card. We should even set this by default - we don't expect any sound to reach the worker - do we ;) ? I don't think so.
IMHO this should be an option set on the worker node in the lava-dispatcher.conf (e.g. LAVA_EXTRA_QEMU_ENV="QEMU_AUDIO_DRV=none").
There is no need to create a LAVA specific variable. In this specific case, this can be handled in the existing environment support.
LAVA V2 supports env.yaml
/etc/lava-server/env.yaml /etc/lava-server/dispatcher-config/env.yaml
# Configure the environment that will be used within the server and the dispatcher.
If admins want to set QEMU_AUDIO_DRV=none then that would be the place to set it. It's not a default at the moment simply because we haven't had problems with QEMU tests in this way.
However, there are lots of other environment variables which QEMU can use and plenty of command line options which are available which could let QEMU test jobs interfere with the performance of the worker as a whole. Care is needed here.
If particular tests need to use the full functionality of QEMU, those tests must be performed by running QEMU on a suitable test device, not by running QEMU on the worker.
Hi Neil!
On Thursday 20 July 2017 12:44:35 Neil Williams wrote:
There is no need to create a LAVA specific variable. In this specific case, this can be handled in the existing environment support.
LAVA V2 supports env.yaml
/etc/lava-server/env.yaml /etc/lava-server/dispatcher-config/env.yaml
# Configure the environment that will be used within the server and the dispatcher.
Perfect. Thanks for the pointer.
If admins want to set QEMU_AUDIO_DRV=none then that would be the place to set it. It's not a default at the moment simply because we haven't had problems with QEMU tests in this way.
Agree, this is a new use-case we stumbled upon.
However, there are lots of other environment variables which QEMU can use and plenty of command line options which are available which could let QEMU test jobs interfere with the performance of the worker as a whole. Care is needed here.
Full ack.
If particular tests need to use the full functionality of QEMU, those tests must be performed by running QEMU on a suitable test device, not by running QEMU on the worker.
For our case above, we just need to present sound hardware to the guest. So it is fine to just let qemu throw the data away and use the worker directly. I agree that more complex setups should go on a separate device.
Thanks for the pointer on the env.yaml, Neil. We'll try it.
On Thursday 20 July 2017 14:28:40 Jan-Simon Möller wrote:
/etc/lava-server/env.yaml /etc/lava-server/dispatcher-config/env.yaml
So I'd need to create the file /etc/lava-server/dispatcher-config/env.yaml like so: http://paste.debian.net/977313/ ?
On 20 July 2017 at 13:34, Jan-Simon Möller dl9pf@gmx.de wrote:
On Thursday 20 July 2017 14:28:40 Jan-Simon Möller wrote:
/etc/lava-server/env.yaml /etc/lava-server/dispatcher-config/env.yaml
So I'd need to create the file /etc/lava-server/dispatcher-config/env.yaml like so: http://paste.debian.net/977313/ ?
The file should already exist - it will need to exist on the server because all the dispatcher config is sent from the server to the worker.
There should not be anything in /etc/lava-server on a V2 worker.
Simply append what you need to the existing file on the master.
https://staging.validation.linaro.org/static/docs/v2/simple-admin.html#lava-...
On Thursday 20 July 2017 13:39:30 Neil Williams wrote:
On 20 July 2017 at 13:34, Jan-Simon Möller dl9pf@gmx.de wrote:
On Thursday 20 July 2017 14:28:40 Jan-Simon Möller wrote:
/etc/lava-server/env.yaml /etc/lava-server/dispatcher-config/env.yaml
So I'd need to create the file /etc/lava-server/dispatcher-config/env.yaml like so: http://paste.debian.net/977313/ ?
The file should already exist - it will need to exist on the server because all the dispatcher config is sent from the server to the worker.
There should not be anything in /etc/lava-server on a V2 worker.
Simply append what you need to the existing file on the master.
https://staging.validation.linaro.org/static/docs/v2/simple-admin.html#lava-... server
So the file exists in /etc/lava-server/env.yaml . But it does not exists in /etc/lava-server/dispatcher-config/env.yaml.
The documentation in lava-server.git/etc/env.yaml and https://staging.validation.linaro.org/static/docs/v2/simple-admin.html#lava-... is not clear about that and the difference between /etc/lava-server/env.yaml and /etc/lava-server/dispatcher-config/env.yaml .
So over here /etc/lava-server/dispatcher-config/env.yaml does not exist ... only /etc/lava-server/env.yaml.
Which one should I use ??
-
Jan-Simon Möller -
Neil Williams -
Remi Duraffort