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