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

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

[Gabriel L. Somlo]

Hi,

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 :)

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.

Any pointers, ideas and tips much appreciated (even just "directions"
to a more appropriate mailing list)...

Thanks much,
--Gabriel

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

On 01/28/2015 08:07 AM, Gabriel L. Somlo wrote:
> Hi,
> 
> 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.

> 
> Any pointers, ideas and tips much appreciated (even just "directions"
> to a more appropriate mailing list)...
> 
> Thanks much,
> --Gabriel
> 
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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