From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIiw4-0003E1-21 for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:14:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIiw1-0007ft-5m for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:14:55 -0500 Received: from relay.parallels.com ([195.214.232.42]:42102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIiw0-0007LG-U1 for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:14:53 -0500 Message-ID: <54D11DFB.906@parallels.com> Date: Tue, 3 Feb 2015 22:14:03 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> In-Reply-To: <20150203190921.GR3354@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" , qemu-devel@nongnu.org Cc: mdroth@linux.vnet.ibm.com On 03/02/15 22:09, Gabriel L. Somlo wrote: > Hi, > > I'm interested in adding a way for a host to pass environment variables > into a qemu guest VM -- analogous to setting environment variables for > a process to access via getenv() and friends. > > The QEMU Guest Agent (QGA) does not appear to quite fit the bill, at > least not in its current form: The agent must have been successfully > started on the guest before the host would have to connect to it (in > a separate act from just starting the guest in the first place), and > get it to execute any hypothetical commands to configure or otherwise > influence the guest. > > For this functionality to really resemble the way environment variables > are used, environment information should be provided as part of the QEMU > command line, without the requirement to make a separate/subsequent > connection to the guest agent. For example: > > qemu-system-x86_64 -guest-env="VAR1=value1;VAR2=value 2" -hda image.qcow2 > > Once the guest is started, it should be possible to query the guest > environment with something like: > > $ qemu-guest-env get VAR1 > value1 > > $ qemu-guest-env get VAR2 > value 2 > > So far, the environment would be read-only from the guest perspective. > A nice additional feature would be to allow setting additional guest-env > variables, or replacing values for existing ones: > > $ qemu-guest-env set VAR3 "foo bar" > > $ qemu-guest-env set VAR4 "blah" > > The actual QGA could then be taught to export guest-env set and get > commands, so that querying/setting data in the guest environment could > be allowed from the outside, via e.g. 'virsh qemu-agent-command'. > > The 'qemu-guest-env' functionality could be incorporated into 'qemu-ga', > or left as a separate (but closely related) binary, most likely packaged > together with qemu-ga. > > In terms of the mechanics, I'll need to figure out the following: > > 1. How would -guest-env="..." actually pass data into the guest? > > Off the top of my head, we could piggyback on top of smbios (by using > a type 11, "OEM strings" structure), which could then be parsed by > qemu-guest-env from the guest side. > > 2. How to support "set-env" (in addition to "get-env") functionality? > > set-env means access to a writable guest memory area, and the least > inconvenient way I can think of accomplishing this would be to put > QGA in charge of it. When starting up for the first time, QGA would > grab the host-supplied environment (e.g. by parsing smbios type 11), > then respond to subsequent get and set requests from its in-memory > environment key-value store. Changes to the environment made after > the guest was started would not be persistent, but that's not something > currently offered by any other platforms either :) > > Ultimately, if this makes it into QEMU, I'd like to also expose the > functionality through libvirt/virsh/virt-manager (so users could set > the initial environment variables as part of the guest VM xml template, > via the gui, etc.) > > So, my question for the QEMU dev team: > > 1. Would you consider this feature a useful addition to QEMU ? > I.e., would this be acceptable (of interest) to the upstream project? > > 2. Is anything similar already being worked on (so I could either join > that effort, or back off, as the case may be) ? :) > > 3. Any technical advice on how to (better) implement it ? > > Thanks much, > --Gabriel > I think that you can do this through guest write/guest exec commands. You can configure service start to perform it is a proper way through guest read/guest write and after that restart the agent. Unfortunately guest exec functionality is still pending...