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']}} \
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 ?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
