From: Eric Blake <eblake@redhat.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>, qemu-devel@nongnu.org
Cc: mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] guest agent vs. host->guest "environment variables"
Date: Wed, 28 Jan 2015 08:25:30 -0700 [thread overview]
Message-ID: <54C8FF6A.9000702@redhat.com> (raw)
In-Reply-To: <20150128150723.GB1762@HEDWIG.INI.CMU.EDU>
[-- 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 --]
next prev parent reply other threads:[~2015-01-28 15:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 15:07 [Qemu-devel] guest agent vs. host->guest "environment variables" Gabriel L. Somlo
2015-01-28 15:25 ` Eric Blake [this message]
2015-01-29 14:23 ` Gabriel L. Somlo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C8FF6A.9000702@redhat.com \
--to=eblake@redhat.com \
--cc=gsomlo@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).