[Top][All Lists]

[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: Wed, 4 Feb 2015 00:49:22 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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:


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

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,

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.

reply via email to

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