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

[Gabriel L. Somlo]

On Tue, Feb 03, 2015 at 12:26:47PM -0700, Eric Blake wrote:
> On 02/03/2015 12:09 PM, Gabriel L. Somlo wrote:
> > 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.
> 
> Have you considered passing SMBIOS information to the guest?  Right now,
> qemu supports passing specific pieces of information through table 1 and
> 2, and arbitrary pre-populated binary files for other tables.  SMBIOS
> data is directly readable by the guest when it boots.

It can do piece-wise table types 2, 3, 4, and 17 as well (oops, I
should send a follow-up patch to make that visible on the '--help'
usage output :)

> > 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.
> 
> Ah, so you have thought about it.  The question then becomes writing
> guest software to conveniently take advantage of whatever you
> arbitrarily pass down, as well as adding sugar on the host side to make
> it easier to package the information to be sent into the guest (easier
> than a binary SMBIOS blob, at any rate).

OK, I had a hunch about this being probably the cleanest,
least-resistance way to do it; the fact that you also thought "smbios"
gives me some extra confidence :)

> >  
> > 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 :)
> 
> Are you proposing that the host can change the environment that the
> guest would re-query on the fly, or that the host's contribution is
> startup-only, and all further setting of variables is guest-side only?
> Or some hybrid where the initial environment is host->guest, but then
> QGA allows either side to communicate further changes in either direction?

I'm really interested in startup-only host->guest, but for completenes
(and feature parity with other platforms) I'd like the hybrid
approach. The key-value store of environment data resides on the
guest, but QGA allows subsequent changes to be initiated from either
side.

> > 2. Is anything similar already being worked on (so I could either join
> >    that effort, or back off, as the case may be) ? :)
> > 
> 
> Not that I'm aware of, although the work on making qga able to request
> arbitrary process exec within the guest might be a piece of the puzzle
> for letting the host easily call into your proposed qemu-guest-env program.

Some guest-side process should be responsible for maintaining a
writeable version of the environment (for the part where we allow
further changes after startup). If that's QGA itself, then arbitrary
process exec is kinda orthogonal.

> 
> > 3. Any technical advice on how to (better) implement it ?
> 
> Your ideas seem reasonable as a first place to start.  You may still
> want to consider setting up a file in the guest, rather than relying on
> in-memory representation, so that things in the guest can survive a
> guest-agent restart.

That's something worth thinking about. The semantics get a bit
complicated -- distinguishing between a qga restart and a first start
which finds a left-over environment file from a previous execution
of the guest, in which case how do we resolve any conflicts between
what's in smbios and the leftover environment file :) But definitely
worth pondering...

> It would certainly be wise to propose a spec of
> the initial SMBIOS string passing and subsequent QGA commands involved
> for coordinating the host->guest relationship, as a first patch in any
> proposed series.

Thanks for the feedback!

--Gabriel