[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"
From: |
Gabriel L. Somlo |
Subject: |
Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables" |
Date: |
Tue, 3 Feb 2015 15:54:36 -0500 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
- [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Gabriel L. Somlo, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Denis V. Lunev, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Eric Blake, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables",
Gabriel L. Somlo <=
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Michael Roth, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Gabriel L. Somlo, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Michael Roth, 2015/02/03
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Daniel P. Berrange, 2015/02/04
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Gabriel L. Somlo, 2015/02/04
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Daniel P. Berrange, 2015/02/04
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Gabriel L. Somlo, 2015/02/04
- Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables", Daniel P. Berrange, 2015/02/04