Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"

[Michael Roth]

Quoting Gabriel L. Somlo (2015-02-03 13:09:22)
> Hi,
> 
> I'm interested in adding a way for a host to pass environment variables
> into a qemu guest VM -- analogous to setting environment variables for
> a process to access via getenv() and friends.
> 
> The QEMU Guest Agent (QGA) does not appear to quite fit the bill, at
> least not in its current form: The agent must have been successfully
> started on the guest before the host would have to connect to it (in
> a separate act from just starting the guest in the first place), and
> get it to execute any hypothetical commands to configure or otherwise
> influence the guest.
> 
> For this functionality to really resemble the way environment variables
> are used, environment information should be provided as part of the QEMU
> command line, without the requirement to make a separate/subsequent
> connection to the guest agent. For example:
> 
>     qemu-system-x86_64 -guest-env="VAR1=value1;VAR2=value 2" -hda image.qcow2
> 
> Once the guest is started, it should be possible to query the guest
> environment with something like:
> 
>     $ qemu-guest-env get VAR1
>     value1
> 
>     $ qemu-guest-env get VAR2
>     value 2
> 
> So far, the environment would be read-only from the guest perspective.
> A nice additional feature would be to allow setting additional guest-env
> variables, or replacing values for existing ones:
> 
>     $ qemu-guest-env set VAR3 "foo bar"
> 
>     $ qemu-guest-env set VAR4 "blah"
> 
> The actual QGA could then be taught to export guest-env set and get
> commands, so that querying/setting data in the guest environment could
> be allowed from the outside, via e.g. 'virsh qemu-agent-command'.
> 
> The 'qemu-guest-env' functionality could be incorporated into 'qemu-ga',
> or left as a separate (but closely related) binary, most likely packaged
> together with qemu-ga.
> 
> In terms of the mechanics, I'll need to figure out the following:
> 
> 1. How would -guest-env="..." actually pass data into the guest?
> 
>    Off the top of my head, we could piggyback on top of smbios (by using
>    a type 11, "OEM strings" structure), which could then be parsed by
>    qemu-guest-env from the guest side.
> 
> 2. How to support "set-env" (in addition to "get-env") functionality?
> 
>    set-env means access to a writable guest memory area, and the least
>    inconvenient way I can think of accomplishing this would be to put
>    QGA in charge of it. When starting up for the first time, QGA would
>    grab the host-supplied environment (e.g. by parsing smbios type 11),
>    then respond to subsequent get and set requests from its in-memory
>    environment key-value store. Changes to the environment made after
>    the guest was started would not be persistent, but that's not something
>    currently offered by any other platforms either :)
> 
> Ultimately, if this makes it into QEMU, I'd like to also expose the
> functionality through libvirt/virsh/virt-manager (so users could set
> the initial environment variables as part of the guest VM xml template,
> via the gui, etc.)
> 
> So, my question for the QEMU dev team:
> 
> 1. Would you consider this feature a useful addition to QEMU ?
>    I.e., would this be acceptable (of interest) to the upstream project?

This does seem like useful functionality, but I think I'd like to know
more about the actual use-cases being looked at.

Is this mostly about executing initial activation scripts? Because after
that point, a key-value store can be managed through the
guest-file-read/write interfaces for anything on the guest-side that's
interested in these variables.

Even activation could be done using this approach, where the
scripts start QGA and wait for the host to coordinate the initial creation
of the file containing those variables, then setting a file marker that
allows activation to proceed. And if that seems wonky, I'm fairly sure you
could script the creation of the initial key-value store prior to starting
the guest using libguestfs:

  http://libguestfs.org/

I think we'd need a very strong argument to bake what seems to be
high-level guest management tasks into QEMU. If that can
avoided with some automated image modifications beforehand that seems
to me the more reasonable approach. Libvirt could ostensibly even
handle the task of writing those XML strings into the image's
key-value store to make management easier, but I suspect even that is
a bit too low in the stack for this level of management.

> 
> 2. Is anything similar already being worked on (so I could either join
>    that effort, or back off, as the case may be) ? :)
> 
> 3. Any technical advice on how to (better) implement it ?
> 
> Thanks much,
> --Gabriel