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

[Alon Levy]

On Tue, Dec 06, 2011 at 10:43:42AM -0600, Michael Roth wrote:
> 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.

Is there a seperate transport (another virtio channel) for the launched
guest process? I'm thinking as usual on the copy/paste functionallity,
when passing a large buffer, I would not want to block any other future
qemu-ga command. Also I would like to avoid having to uuencode/decode
the traffic.

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