From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIwJF-0005US-V5 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 04:31:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIwJB-0002y4-5Y for qemu-devel@nongnu.org; Wed, 04 Feb 2015 04:31:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIwJA-0002y0-U4 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 04:31:41 -0500 Date: Wed, 4 Feb 2015 09:31:32 +0000 From: "Daniel P. Berrange" Message-ID: <20150204093132.GJ3032@redhat.com> References: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> <20150203201112.6410.67335@loki> <20150203213858.GU3354@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150203213858.GU3354@HEDWIG.INI.CMU.EDU> Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables" Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: Michael Roth , qemu-devel@nongnu.org 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 :|