From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIj84-0007dT-96 for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:27:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIj80-0002wW-0W for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:27:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIj7z-0002uu-Or for qemu-devel@nongnu.org; Tue, 03 Feb 2015 14:27:15 -0500 Message-ID: <54D120F7.70100@redhat.com> Date: Tue, 03 Feb 2015 12:26:47 -0700 From: Eric Blake MIME-Version: 1.0 References: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> In-Reply-To: <20150203190921.GR3354@HEDWIG.INI.CMU.EDU> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1qgkNQMvRxJp3VGdg05JSHcgDAPGpXCwW" 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1qgkNQMvRxJp3VGdg05JSHcgDAPGpXCwW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/03/2015 12:09 PM, Gabriel L. Somlo wrote: > Hi, >=20 > 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. >=20 > 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. Have you considered passing SMBIOS information to the guest? Right now, qemu supports passing specific pieces of information through table 1 and 2, and arbitrary pre-populated binary files for other tables. SMBIOS data is directly readable by the guest when it boots. > In terms of the mechanics, I'll need to figure out the following: >=20 > 1. How would -guest-env=3D"..." actually pass data into the guest? >=20 > Off the top of my head, we could piggyback on top of smbios (by usin= g > a type 11, "OEM strings" structure), which could then be parsed by > qemu-guest-env from the guest side. Ah, so you have thought about it. The question then becomes writing guest software to conveniently take advantage of whatever you arbitrarily pass down, as well as adding sugar on the host side to make it easier to package the information to be sent into the guest (easier than a binary SMBIOS blob, at any rate). > =20 > 2. How to support "set-env" (in addition to "get-env") functionality? >=20 > 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 someth= ing > currently offered by any other platforms either :) Are you proposing that the host can change the environment that the guest would re-query on the fly, or that the host's contribution is startup-only, and all further setting of variables is guest-side only? Or some hybrid where the initial environment is host->guest, but then QGA allows either side to communicate further changes in either direction= ? >=20 > 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.) >=20 > So, my question for the QEMU dev team: >=20 > 1. Would you consider this feature a useful addition to QEMU ? > I.e., would this be acceptable (of interest) to the upstream project= ? Seems like it is reasonable, from my point of view. >=20 > 2. Is anything similar already being worked on (so I could either join > that effort, or back off, as the case may be) ? :) >=20 Not that I'm aware of, although the work on making qga able to request arbitrary process exec within the guest might be a piece of the puzzle for letting the host easily call into your proposed qemu-guest-env progra= m. > 3. Any technical advice on how to (better) implement it ? Your ideas seem reasonable as a first place to start. You may still want to consider setting up a file in the guest, rather than relying on in-memory representation, so that things in the guest can survive a guest-agent restart. It would certainly be wise to propose a spec of the initial SMBIOS string passing and subsequent QGA commands involved for coordinating the host->guest relationship, as a first patch in any proposed series. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --1qgkNQMvRxJp3VGdg05JSHcgDAPGpXCwW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU0SD3AAoJEKeha0olJ0Nq4dEH/j28C9dIH1E+mmBrYkHtPqD4 EaRWOoaLhRj+RPpJUaF9r5kiJD+kCQIjynLrtMxN6bDm5ASthmDFUAAEU8PqCMHh 5d0wB4EN0C/NgNNXfwTjhz5t0VnDVX8cxcq5bOZkYXa6BtE4XiaR756aM9suAlgE s/ozUkT54c2HXRLzCqmkQUEACnrPQVpW3Z8e+sWs6UqlzwQLs0YTELmK2hY9v+vr cs6L0vOzop2ZEqbmBG7Ak/4i75Cr2o7d24ug/xs8vsKkZTcsdlseK2X4zuTyhX48 /t3RFvnsxfXuzbnoqb0rwBLT/fTVYO1bJPeKdW+YdLWNamAi7mRX547OTSKMhJg= =X3Id -----END PGP SIGNATURE----- --1qgkNQMvRxJp3VGdg05JSHcgDAPGpXCwW--