Re: [Qemu-devel] guest agent vs. host->guest "environment variables"

[Gabriel L. Somlo]

On Wed, Jan 28, 2015 at 08:25:30AM -0700, Eric Blake wrote:
> On 01/28/2015 08:07 AM, Gabriel L. Somlo wrote:
> > I'm looking for an equivalent to VMWare "guestinfo" variables
> > (the stuff one may set on a VM via e.g. the vSphere client, under
> > Summary->Annotations->Notes, and looks like a bunch of "name = value"
> > environment variable definitions. These can then be retrieved from
> > the guest via 'vmtoolsd --cmd "info-get guestinfo.name"', which would
> > print the string "value" to stdout.
> > 
> > After some initial digging, it appears that the QEMU guest agent is
> > the closest thing to "vmtoolsd" right now, but it doesn't look like
> > it supports the functionality I'm interested in.
> > 
> > My question is, am I missing anything obvious? Is there anything in
> > the kvm/qemu/libvirt universe that currently offers this type of
> > functionality? If not, would it be of any interest? I'm willing (and
> > hopefully able) to send patches, if it comes to that :)
> 
> The existing qga allows you to write arbitrary contents from the host
> into an arbitrary file on the guest; you could use the contents of that
> file to be your name/value store or anything else.  As for whether it
> makes sense to make it easier for the guests to access queries from such
> a file, I guess we could patch the qga package to provide such a helper
> app for use in the guest.  Or if you want to add an entirely new
> guest-agent command that makes such contents easier for the host to pass
> than what you get by writing a raw file, you could try that as well.
> There are several example threads in the list archives of proposals to
> add new qga commands.
> 
> > 
> > Also, while extracting this type of "environment variable" on the
> > guest seems perfectly suited to something like qga, it also appears
> > that injecting them on the host side might involve cooperation from
> > a higher layer, such as libvirt.
> 
> Yes, if you have a new qga command and/or new app bundled with qga used
> for querying a specific format of a specific file written by existing
> qga commands, then it would be reasonable to patch libvirt to make it
> easier to expose that functionality to the end user.  But even without
> formal libvirt support, you can use the backdoor of 'virsh
> qemu-agent-command' to pass arbitrary qga commands through to the guest.

Thanks, that was interesting and helpful! After some more digging
though, it looks like all of this is host-initiated, and relies on the
guest having completed its startup process (including having launched
the guest agent).

What I'm looking to replicate is the ability to allow the host to
supply some (set of) environment string(s) to the guest, to be read
at the guest's leisure (or not). Akin to a program having the option
to call "getenv()" at its leisure :)

For added context, I'm trying to port an application currently running
on VMWare, which starts multiple guests from the same base image.
Guests use "info-get guestinfo.<env_var_name>" during bootup to set
things like host name, packages or package groups to "yum install"
on top of the base image, etc. The guestinfo variables are simply part
of the VM template, and there's no need for the host to establish a
communication channel with the guest for this purpose, after having
started it.

So I briefly went through a couple of other ways to accomplish this:

  - adding yet another chardev to the qemu command line
        - if it's a pipe, we're back to the same place we were with
          QGA, only in an ad-hoc, hacky way :) We still have the
          problem of the host having to synchronize with the guest
          when one writes into, and the other reads from that pipe
        - if it's of type 'file', things don't work, as "chardev file"
          is uni-directional, from guest to host only, and gets
          overwritten when qemu starts; so, not useful to allow
          the guest to read some static data from the host
        - besides, we're expecting the guest OS to find some char
          device and read from it, rather than run some standardized
          program (e.g. QGA or vmware-tools).

  - placing a config file in a per-guest folder, then mapping that
    as a "-drive file=fat:ro:./Folder" into the qemu guest
        - again, very ad-hock-y, and the guest OS now has to deal
          with a new drive, which may conflict with other drives
          it may have otherwise had connected to it.

Would extending QGA (or adding a helper tool to it) make sense to
allow guest-initiated reading of host-supplied environment variables ?
I'm talking specifically about replicating the "info-get" command
supported by vmware-tools...

Thanks again,
--Gabriel