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

[Daniel P. Berrange]

On Wed, Feb 04, 2015 at 10:20:14AM -0500, Gabriel L. Somlo wrote:
> 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.

Yes, there is some overhead in setting up QEMU on the host to provide
the data cloud-init needs, but it isn't all that difficult. For example
Rich Jones describes how to setup a virtual disk for cloud-init

  
https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/

Given the prevalence of cloud-init across distros, I think you'll be hard
pressed to get them to support an alternative method, even if it is a bit
simpler at the QEMU setup level.

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