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