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