Re: [Qemu-devel] [PATCH 0/2] [RFC] qemu-ga: add support for guest command execution

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 12/06/2011 08:44 AM, Daniel P. Berrange wrote:
> On Tue, Dec 06, 2011 at 08:34:06AM -0600, Michael Roth wrote:
>> The code is still in rough shape, but while we're on the topic of guest agents
>> I wanted to put out a working example of how exec functionality can be added
>> to qemu-ga to provide a mechansim for building arbitrarilly high-level
>> interfaces.
>>
>> The hope is that by allowing qemu-ga to execute commands in the guest, paired
>> with file read/write access, we can instrument a guest "on the fly" to support
>> any type of hyperviser functionality, and do so without dramatically enlarging
>> the role qemu-ga plays as a small, QEMU-specific agent that is tightly
>> integrated with QEMU/QMP/libvirt.
>>
>> These patches add the following interfaces:
>>
>> guest-file-open-pipe
>> guest-exec
>> guest-exec-status
>>
>> The guest-file-open-pipe interface is analagous to the existing guest-file-open
>> interface (it might be best to roll it into it actually): it returns a handle
>> that can be handled via the existing guest-file-{read,write,flush,close}
>> interface. Internally it creates a FIFO pair that we can use to associate
>> handles to the stdin/stdout/stderr of a guest-exec spawned process. We can also
>> also use them to redirect output into other processes, giving us the basic
>> tools to build a basic shell (or a full-blown one if we add TTY support) using
>> a single qemu-ga.
>>
>> Theoretically we can even deploy other agents, including session-level agents,
>> and communicate with them via these same handles. Thus, ovirt could deploy and
>> run an agent via qemu-ga, Spice could deploy vdagent, etc. Since the interface
>> is somewhat tedious, I'm working on a wrapper script to try out some of
>> these scenarios, but a basic use case using the raw QMP interface is included
>> below.
>>
>> Any thoughts/comments on this approach are appreciated.
>>
>> EXAMPLE USAGE (execute `top -b -n1`):
>>
>> {'execute': 'guest-file-open-pipe'}
>> {'return': 6}
>>
>> {'execute': 'guest-exec',                    \
>>   'arguments': {'detach': True,               \
>>                 'handle_stdout': 6,           \
>>                 'params': [{'param': '-b'},   \
>>                            {'param': '-n1'}], \
>>                 'path': 'top'}}
>
> This feels like a rather verbose way of specifying
> the ARGV. Why not just allow
>
>    {'execute': 'guest-exec',                    \
>     'arguments': {'detach': True,               \
>                   'handle_stdout': 6,           \
>                   'params': ['-b', '-n1'],      \
>                   'path': 'top'}}
>
> Or even
>
>
>    {'execute': 'guest-exec',                    \
>     'arguments': {'detach': True,               \
>                   'handle_stdout': 6,           \
>                   'argv': ['top', '-b', '-n1']}} \
>

Agreed, this would look way nicer and is what I was shooting for 
initially. Unfortunately, the QAPI-generated QMP marshalling code, and 
the visitor interfaces it uses, expects lists to be of structured types. 
We might be able to special-case it for int and char* arrays though and 
open-code it though...

The problem I ran into when I looked at it though is that the QMP 
request is a QObject at that point that's contained inside a Visitor. So 
to manipulate it we'd have to extract the QList and manipulate it 
outside the visitor, which would be difficult since the Visitor is using 
a stack to manage it's traversal of the QObject based on the visitor 
calls we make, so it's difficult to pull it out of there...

Although, maybe we could just add a qmp_input_vistor_stack_top() that 
gives us the top of the stack, then call it at the appropriate point in 
the marshalling code and key into it to get qobj{'argv'} and whatnot. 
It's kinda hacky, but it's QMP-specific, and useful, so it might be 
worth it.

Alternatively, we could introduce another Visitor interface for handling 
lists of int64_t and char*.

So maybe it's not so bad, I'll look into it more.

> and just use the first element of argv as the binary to
> execute. Also you might need to set env variables for
> some tools, so we'd want
>
>    {'execute': 'guest-exec',                    \
>     'arguments': {'detach': True,               \
>                   'handle_stdout': 6,           \
>                   'argv': ['top', '-b', '-n1'], \
>                   'env' : ['TMPDIR=/wibble']}}
>
> and perhaps also you might want to run as a non-root
> user, so allow a username/groupname ?
>

Good idea, this would open up a lot of potential use cases (X 
session/display management, copy/paste, etc).

> Regards,
> Daniel