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

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

[Gabriel L. Somlo]

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

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

[Denis V. Lunev]

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

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 4083 bytes --]

On 02/03/2015 12:09 PM, 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.

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

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

>  
> 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 :)

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?

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

Seems like it is reasonable, from my point of view.

> 
> 2. Is anything similar already being worked on (so I could either join
>    that effort, or back off, as the case may be) ? :)
> 

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

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Michael Roth]

Quoting Gabriel L. Somlo (2015-02-03 13:09:22)
> 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?

This does seem like useful functionality, but I think I'd like to know
more about the actual use-cases being looked at.

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/

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.

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

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

[Gabriel L. Somlo]

Hi Denis,

On Tue, Feb 03, 2015 at 10:14:03PM +0300, Denis V. Lunev wrote:
> On 03/02/15 22:09, Gabriel L. Somlo wrote:
>>
>>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
>> [...]
> 
> 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.

Are these supposed to be commands issued from the qemu monitor prompt
(or qmp) ? My Google-fu didn't help too much either :)

The main idea is to be able to provide environment data to a guest
at start time (on the qemu command line), and not have to worry about
connecting back to it (via monitor prompt, qmp, if/when it starts the
guest agent, etc) to pass more information to it later on.

I'm probably misunderstanding what you said, though, so please
clarify...

Thanks much,
--Gabriel

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

[Denis V. Lunev]

On 03/02/15 23:14, Gabriel L. Somlo wrote:
> Hi Denis,
>
> On Tue, Feb 03, 2015 at 10:14:03PM +0300, Denis V. Lunev wrote:
>> On 03/02/15 22:09, Gabriel L. Somlo wrote:
>>>
>>> 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
>>> [...]
>>
>> 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.
>
> Are these supposed to be commands issued from the qemu monitor prompt
> (or qmp) ? My Google-fu didn't help too much either :)
>
> The main idea is to be able to provide environment data to a guest
> at start time (on the qemu command line), and not have to worry about
> connecting back to it (via monitor prompt, qmp, if/when it starts the
> guest agent, etc) to pass more information to it later on.
>
> I'm probably misunderstanding what you said, though, so please
> clarify...
>
> Thanks much,
> --Gabriel
>
QEMU guest agent starts as a service inside the guest. Its startup
is controlled through standard Unix scripts. You can modify these
scrips from the host side and (hopefully) restart agent.

The modification could be made using

##
# @GuestFileRead
#
# Result of guest agent file-read operation
#
# @count: number of bytes read (note: count is *before*
#         base64-encoding is applied)
#
# @buf-b64: base64-encoded bytes read
#
# @eof: whether EOF was encountered during read operation.
#
# Since: 0.15.0
##
{ 'type': 'GuestFileRead',
   'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }

##
# @GuestFileWrite
#
# Result of guest agent file-write operation
#
# @count: number of bytes written (note: count is actual bytes
#         written, after base64-decoding of provided buffer)
#
# @eof: whether EOF was encountered during write operation.
#
# Since: 0.15.0
##
{ 'type': 'GuestFileWrite',
   'data': { 'count': 'int', 'eof': 'bool' } }

Den

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

[Gabriel L. Somlo]

On Tue, Feb 03, 2015 at 12:26:47PM -0700, Eric Blake wrote:
> On 02/03/2015 12:09 PM, 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.
> 
> 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.

It can do piece-wise table types 2, 3, 4, and 17 as well (oops, I
should send a follow-up patch to make that visible on the '--help'
usage output :)

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

OK, I had a hunch about this being probably the cleanest,
least-resistance way to do it; the fact that you also thought "smbios"
gives me some extra confidence :)

> >  
> > 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 :)
> 
> 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?

I'm really interested in startup-only host->guest, but for completenes
(and feature parity with other platforms) I'd like the hybrid
approach. The key-value store of environment data resides on the
guest, but QGA allows subsequent changes to be initiated from either
side.

> > 2. Is anything similar already being worked on (so I could either join
> >    that effort, or back off, as the case may be) ? :)
> > 
> 
> 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 program.

Some guest-side process should be responsible for maintaining a
writeable version of the environment (for the part where we allow
further changes after startup). If that's QGA itself, then arbitrary
process exec is kinda orthogonal.

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

That's something worth thinking about. The semantics get a bit
complicated -- distinguishing between a qga restart and a first start
which finds a left-over environment file from a previous execution
of the guest, in which case how do we resolve any conflicts between
what's in smbios and the leftover environment file :) But definitely
worth pondering...

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

Thanks for the feedback!

--Gabriel

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

[Gabriel L. Somlo]

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.

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.

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

[Denis V. Lunev]

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

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

[Michael Roth]

Quoting Gabriel L. Somlo (2015-02-03 15:38:59)
> 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

Well, I assume by shared a base image you mean using a template image
as the backing image for a COW image allocated for each guest prior
to activation? As long as the editing is done against the COW image rather
than the backing image it should work. Maybe it's not ideal, but it's
feasible.

I hadn't really considered the SMBIOS approach though. That might be
more straightforward to get the initial store to the guest.

> 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 :)

Understandable :)

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

Seems like a reasonable start to me.

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

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

[Gabriel L. Somlo]

On Wed, Feb 04, 2015 at 12:49:22AM +0300, Denis V. Lunev wrote:
> 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.

I'm trying as hard as I can to avoid the bit where I have to "wait
guest agent startup, connect, run a bunch of stuff on the guest
through the agent"... :)

The application I'm trying to port has a bunch of VM templates with
some guestinfo/environment variables in them, many of them sharing
the same disk image (vmdk) file. We start them all, and that's it.
Fire and forget, no further fuss. If a VM hangs during startup, that's
the application USER's problem, they can restart it, or whatever.

With your suggestion, I'd have to write a bunch of additional logic
to monitor each starting VM, connect to it, handle errors and exceptions
(what if the QGA doesn't start, what if it takes a long time to start, etc.)
Now dealing with a failed boot is suddenly the application's problem,
since I'm sitting there waiting to connect to the agent, and have to
do something if the agent isn't coming up.

That's currently not necessary when using "that other hypervisor" from
which I'm trying to migrate, so QEMU is at a bit of a disadvantage. I
think there's value making it easy to port stuff over without imposing
a major redesign of the application being ported...

Thanks,
--Gabriel

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

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

[Daniel P. Berrange]

On Tue, Feb 03, 2015 at 02:09:22PM -0500, 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.

> 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) ? :)

IMHO this is already a solved problem via the cloud-init project which
is the widely used standard for injecting information into guest OS
at boot time. Any OS distro shipping cloud images is already going to
have cloud-init provided.

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

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

[Daniel P. Berrange]

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

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

[Gabriel L. Somlo]

Hi Daniel,

On Wed, Feb 04, 2015 at 09:31:32AM +0000, Daniel P. Berrange wrote:
> 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.

Thanks for the pointer, cloud-init does indeed sound very interesting,
and I'll definitely keep it in mind when creating new content (new VM
images) for the application.

However, looking at this:

https://cloudinit.readthedocs.org/en/latest/topics/capabilities.html

I found the following:

  "Cloud-init's behavior can be configured via user-data [...] which
   can be given by the user at instance launch time. This is done via
   the --user-data or --user-data-file argument to ec2-run instances
   for example.

   * Check your local clients documentation for how to provide a
     user-data string or user-data file for usage by cloud-init on
     instance creation"

I guess what I'm proposing is a low-overhead, flexible way
to pas such a user-data string into qemu, via its command line,
and without adding the non-trivial requirement that whatever I'm
doing must happen within the context of a cloud infrastructure
such as ec2, openstack, etc., which is how user-data is currently
provided to cloud-init on the starting VMs.

Please kick me if I totally missed something obvious! :)

Thanks much,
--Gabriel

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

[Daniel P. Berrange]

On Wed, Feb 04, 2015 at 10:20:14AM -0500, Gabriel L. Somlo wrote:
> Hi Daniel,
> 
> On Wed, Feb 04, 2015 at 09:31:32AM +0000, Daniel P. Berrange wrote:
> > 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.
> 
> Thanks for the pointer, cloud-init does indeed sound very interesting,
> and I'll definitely keep it in mind when creating new content (new VM
> images) for the application.
> 
> However, looking at this:
> 
> https://cloudinit.readthedocs.org/en/latest/topics/capabilities.html
> 
> I found the following:
> 
>   "Cloud-init's behavior can be configured via user-data [...] which
>    can be given by the user at instance launch time. This is done via
>    the --user-data or --user-data-file argument to ec2-run instances
>    for example.
> 
>    * Check your local clients documentation for how to provide a
>      user-data string or user-data file for usage by cloud-init on
>      instance creation"
> 
> I guess what I'm proposing is a low-overhead, flexible way
> to pas such a user-data string into qemu, via its command line,
> and without adding the non-trivial requirement that whatever I'm
> doing must happen within the context of a cloud infrastructure
> such as ec2, openstack, etc., which is how user-data is currently
> provided to cloud-init on the starting VMs.

Yes, there is some overhead in setting up QEMU on the host to provide
the data cloud-init needs, but it isn't all that difficult. For example
Rich Jones describes how to setup a virtual disk for cloud-init

  https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/

Given the prevalence of cloud-init across distros, I think you'll be hard
pressed to get them to support an alternative method, even if it is a bit
simpler at the QEMU setup level.

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

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

[Christopher Covington]

Hi Gabriel,

Summary up top, why I like the approach below.

On 02/03/2015 02:09 PM, Gabriel L. Somlo wrote:
> Hi,

> 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

qemu-system-x86_64 -append "myvars=VAR1=value1;VAR2=value2" -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

eval `sed -nr 's/myvars=(.*)/\1/' /proc/cmdline`
echo $VAR1
echo $VAR2

I have two use cases that I've enabled or would like to enable across a
variety of platforms and architectures:

A) Script workload(s) that should run from a regular "cold" boot.
B) On slow systems, script the workload(s) that should be run immediately
following a checkpoint restore ("warm" boot).

Originally I was using the ARM Angel semihosting command line for both A and
B. But that required a JTAG debugger be attached to hardware devices, so I
switched to appending foo=bar strings to /proc/cmdline, which has the
additional benefit of being portable across architectures. Does QEMU's -append
flag for setting and something like `sed -nr 's/myopts=(.*)/\1/'
/proc/cmdline` for getting work for your use case?

I've wondered about something portable across architectures like QMP or
VirtIO-something for the B use case, but that hasn't really progressed beyond
thought experiment.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Gabriel L. Somlo]

On Wed, Feb 04, 2015 at 03:24:32PM +0000, Daniel P. Berrange wrote:
> Yes, there is some overhead in setting up QEMU on the host to provide
> the data cloud-init needs, but it isn't all that difficult. For example
> Rich Jones describes how to setup a virtual disk for cloud-init
> 
>   https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/
> 
> Given the prevalence of cloud-init across distros, I think you'll be hard
> pressed to get them to support an alternative method, even if it is a bit
> simpler at the QEMU setup level.

Have a look at this:

http://www.vmware.com/pdf/Scripting_API_23.pdf

(page 36, GuestInfo Variables).

It's a rather generic, flexible feature. Some people use it for
early boot, but that's just one of the many use cases, so maybe
focusing on "how to implement early boot configuration" is going
a bit off on a tangent :)

I'd like to add that mechanism (or at least the host->guest bits)
to qemu, for "feature parity". That should be a good thing, making
it easier to port "whatever" to qemu, without having to massively
rearchitect it to work around a missing feature...

Also, it's really non-intrusive. At this point, I could implement it
by passing environment strings in via "-smbios file=./Type11EnvStrBlob",
and read them on the guest side via 'dmidecode -t11', with some grep
and awk magic thrown in for good measure :)

But I'd really love to wrap it in some syntactic sugar, so that
it could eventually be exposed via virsh and virt-manager, so that
people used to VMWare and guestinfo variables can migrate things
over to qemu/kvm in a relatively painless way. And some of them will
use it for early boot, but hey, who am I to argue. I'm all about
"mechanism", and prefer leaving "policy" to the user :)

Thanks much,
--Gabriel

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

[Richard W.M. Jones]

On Tue, Feb 03, 2015 at 02:09:22PM -0500, Gabriel L. Somlo wrote:
>     qemu-system-x86_64 -guest-env="VAR1=value1;VAR2=value 2" -hda image.qcow2

libguestfs does this already by passing a few environment variables on
the kernel command line.  This requires a Linux guest kernel and that
you're using the -kernel and -append options.

For a more general purpose approach, I'd suggest something with
virtio-serial.

What problem is this actually trying to solve?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

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

[Gabriel L. Somlo]

On Wed, Feb 04, 2015 at 04:00:05PM +0000, Richard W.M. Jones wrote:
> On Tue, Feb 03, 2015 at 02:09:22PM -0500, Gabriel L. Somlo wrote:
> >     qemu-system-x86_64 -guest-env="VAR1=value1;VAR2=value 2" -hda image.qcow2
> 
> libguestfs does this already by passing a few environment variables on
> the kernel command line.  This requires a Linux guest kernel and that
> you're using the -kernel and -append options.

Right, lots of the VMs I'm concerned about are Windows, of various
vintages.

> For a more general purpose approach, I'd suggest something with
> virtio-serial.

That requires that either the host or guest actively reach out and
push or pull something to/from the other, respectively, as a separate
step from simply starting the guest.

> What problem is this actually trying to solve?

Feature-parity with vmware's guestinfo variables (see
http://www.vmware.com/pdf/Scripting_API_23.pdf, pp.36)

Think "environment variables" from host to guest, without requiring
one to connect to anything and mount/download/push or otherwise
transfer stuff before the guest can know what it's supposed to do.

Thanks much,
--Gabriel

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

[Daniel P. Berrange]

On Wed, Feb 04, 2015 at 10:59:18AM -0500, Gabriel L. Somlo wrote:
> On Wed, Feb 04, 2015 at 03:24:32PM +0000, Daniel P. Berrange wrote:
> > Yes, there is some overhead in setting up QEMU on the host to provide
> > the data cloud-init needs, but it isn't all that difficult. For example
> > Rich Jones describes how to setup a virtual disk for cloud-init
> > 
> >   https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/
> > 
> > Given the prevalence of cloud-init across distros, I think you'll be hard
> > pressed to get them to support an alternative method, even if it is a bit
> > simpler at the QEMU setup level.
> 
> Have a look at this:
> 
> http://www.vmware.com/pdf/Scripting_API_23.pdf
> 
> (page 36, GuestInfo Variables).
> 
> It's a rather generic, flexible feature. Some people use it for
> early boot, but that's just one of the many use cases, so maybe
> focusing on "how to implement early boot configuration" is going
> a bit off on a tangent :)
> 
> I'd like to add that mechanism (or at least the host->guest bits)
> to qemu, for "feature parity". That should be a good thing, making
> it easier to port "whatever" to qemu, without having to massively
> rearchitect it to work around a missing feature...
> 
> Also, it's really non-intrusive. At this point, I could implement it
> by passing environment strings in via "-smbios file=./Type11EnvStrBlob",
> and read them on the guest side via 'dmidecode -t11', with some grep
> and awk magic thrown in for good measure :)

Perhaps cloud-init project would be interested in using the custom
smbios field as a data source for its needs. It already has the concept
of pluggable data sources, so adding another could be interesting.

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