qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"


From: Denis V. Lunev
Subject: Re: [Qemu-devel] RFC: Proposal to add QEMU "Guest Environment Variables"
Date: Tue, 3 Feb 2015 22:14:03 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]