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

[Michael Roth]

Quoting Gabriel L. Somlo (2015-02-03 15:38:59)
> On Tue, Feb 03, 2015 at 02:11:12PM -0600, Michael Roth wrote:
> > 
> > This does seem like useful functionality, but I think I'd like to know
> > more about the actual use-cases being looked at.
> 
> The proposed functionality is mostly equivalent to that offered by
> "GuestInfo variables". So yes, initial activation scripts :)
> 
> > Is this mostly about executing initial activation scripts? Because after
> > that point, a key-value store can be managed through the
> > guest-file-read/write interfaces for anything on the guest-side that's
> > interested in these variables.
> > 
> > Even activation could be done using this approach, where the
> > scripts start QGA and wait for the host to coordinate the initial creation
> > of the file containing those variables, then setting a file marker that
> > allows activation to proceed. And if that seems wonky, I'm fairly sure you
> > could script the creation of the initial key-value store prior to starting
> > the guest using libguestfs:
> > 
> >   http://libguestfs.org/
> 
> Specifically, I'm trying to port to QEMU a simulation/training setup
> where multiple VMs are started from the same base image, and guestinfo
> environment variables help each instance determine its "personality".
> 
> Editing the disk image is not feasible, since the idea is to share the
> base disk image across multiple VMs. And needing to connect to each VM

Well, I assume by shared a base image you mean using a template image
as the backing image for a COW image allocated for each guest prior
to activation? As long as the editing is done against the COW image rather
than the backing image it should work. Maybe it's not ideal, but it's
feasible.

I hadn't really considered the SMBIOS approach though. That might be
more straightforward to get the initial store to the guest.

> after having started it, wait for it to bring up the QGA, then get it
> to accept environment variables, that's precisely the wonkiness I'm
> trying to avoid :)

Understandable :)

> 
> I can certainly start small and implement read-only, host->guest startup
> time values (the smbios type11 strings plus a way to read them via a
> guest-side binary associated with a guest-tools package), and we can
> decide whether we want to support "set-env" operations and exporting
> set-env and get-env via the agent at a later stage. That functionality
> is available with GuestInfo variables, but the system I'm trying to port
> to QEMU doesn't require it as far as I can tell.

Seems like a reasonable start to me.

> 
> Thanks much,
> --Gabriel
> 
> > 
> > I think we'd need a very strong argument to bake what seems to be
> > high-level guest management tasks into QEMU. If that can
> > avoided with some automated image modifications beforehand that seems
> > to me the more reasonable approach. Libvirt could ostensibly even
> > handle the task of writing those XML strings into the image's
> > key-value store to make management easier, but I suspect even that is
> > a bit too low in the stack for this level of management.