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: Gabriel L. Somlo
Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"
Date: Wed, 4 Feb 2015 10:20:14 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hi Daniel,

On Wed, Feb 04, 2015 at 09:31:32AM +0000, Daniel P. Berrange wrote:
> 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.

Thanks for the pointer, cloud-init does indeed sound very interesting,
and I'll definitely keep it in mind when creating new content (new VM
images) for the application.

However, looking at this:

https://cloudinit.readthedocs.org/en/latest/topics/capabilities.html

I found the following:

  "Cloud-init's behavior can be configured via user-data [...] which
   can be given by the user at instance launch time. This is done via
   the --user-data or --user-data-file argument to ec2-run instances
   for example.

   * Check your local clients documentation for how to provide a
     user-data string or user-data file for usage by cloud-init on
     instance creation"

I guess what I'm proposing is a low-overhead, flexible way
to pas such a user-data string into qemu, via its command line,
and without adding the non-trivial requirement that whatever I'm
doing must happen within the context of a cloud infrastructure
such as ec2, openstack, etc., which is how user-data is currently
provided to cloud-init on the starting VMs.

Please kick me if I totally missed something obvious! :)

Thanks much,
--Gabriel



reply via email to

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