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