qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"
Date: Wed, 4 Feb 2015 09:31:32 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Feb 03, 2015 at 04:38:59PM -0500, Gabriel L. Somlo wrote:
> 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
> 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 :)

AFAICT, you're describing the exact scenario that cloud-init solves.
You have a generic cloud base image, and you provide metadata to the
guest (either via a transient CDROM image generated at boot, or via
a speciall network interface with well known IP addr + HTTP service)
which is uses to configure itself for a specific task as boot up.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]