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

["Denis V. Lunev" <den-lists@parallels.com>]

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