From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIlLf-0006VQ-4N for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:49:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIlLb-0003TP-FH for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:49:31 -0500 Received: from relay.parallels.com ([195.214.232.42]:42183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIlLb-0003T5-8U for qemu-devel@nongnu.org; Tue, 03 Feb 2015 16:49:27 -0500 Message-ID: <54D14262.2080802@parallels.com> Date: Wed, 4 Feb 2015 00:49:22 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> <20150203201112.6410.67335@loki> <20150203213858.GU3354@HEDWIG.INI.CMU.EDU> In-Reply-To: <20150203213858.GU3354@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , Michael Roth Cc: qemu-devel@nongnu.org On 04/02/15 00:38, 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 :) > > I can certainly start small and implement read-only, host->guest startup > time values (the smbios type11 strings plus a way to read them via a > guest-side binary associated with a guest-tools package), and we can > decide whether we want to support "set-env" operations and exporting > set-env and get-env via the agent at a later stage. That functionality > is available with GuestInfo variables, but the system I'm trying to port > to QEMU doesn't require it as far as I can tell. > guest exec with ability to pass an environment could solve your problem even without read/write. Boot guest, wait guest agent startup, start something you need from agent with desired environment. this is a quote from the patchset being discussed at the moment. [PATCH v2 0/8] qemu: guest agent: implement guest-exec command for Linux +## +# @guest-exec: +# +# Execute a command in the guest +# +# @path: path or executable name to execute +# @params: #optional parameter list to pass to executable +# @env: #optional environment variables to pass to executable +# @handle_stdin: #optional handle to associate with process' stdin. +# @handle_stdout: #optional handle to associate with process' stdout +# @handle_stderr: #optional handle to associate with process' stderr +# +# Returns: PID on success. +# +# Since: 2.3 +## +{ 'command': 'guest-exec', + 'data': { 'path': 'str', '*params': ['str'], '*env': ['str'], + '*handle_stdin': 'int', '*handle_stdout': 'int', + '*handle_stderr': 'int' }, + 'returns': 'int' } > Thanks much, > --Gabriel > >> >> I think we'd need a very strong argument to bake what seems to be >> high-level guest management tasks into QEMU. If that can >> avoided with some automated image modifications beforehand that seems >> to me the more reasonable approach. Libvirt could ostensibly even >> handle the task of writing those XML strings into the image's >> key-value store to make management easier, but I suspect even that is >> a bit too low in the stack for this level of management. > > >