[Spice-devel] spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Jan 11

[Adam Litke]

On Thu, 2011-01-13 at 21:18 +0200, Alon Levy wrote:
> On Thu, Jan 13, 2011 at 09:01:34AM -0600, Adam Litke wrote:
> > On Tue, 2011-01-11 at 20:33 +0200, Alon Levy wrote:
> > > > Spice guest agent:
> > > > - virt agent, matahari, spice agent...what is in spice agent?
> > > > - spice char device
> > > >   - mouse, copy 'n paste, screen resolution change
> > > > - could be generic (at least input and copy/paste)
> > > >   - send protocol details of what is being sent
> > > > - need to look at how difficult it is to split it out from spice
> > > >   (how to split out in qemu vs. libspice)
> > > > - goal to converge on common framework
> > > > - more discussion on char device vs. protocol
> > > >   - eg. mouse_set breaks if mouse channel is part pv and part spice specific
> > > > - Alon will send link to protocol and try to propose new interfaces
> > > 
> > > http://spice-space.org/page/Whiteboard/AgentProtocol
> > > 
> > > That's the corrent documentation. Notably the clipboard is a todo there, I'll
> > > try to get that filled in. I'll continue this discussion on a separate thread later.
> > 
> > Thanks for sending this out Alon.  The use cases you have outlined are
> > very similar to the ones we have for virtagent.  The main differences I
> > can see so far are the the data encoding strategy and the spice agent's
> > method for delivery of events (mouse, etc).
> > 
> Let me start by saying I'm not yet familiar with virtagent, I need to read
> up on it (really didn't expect to try to merge with it at this point, not
> that that isn't a good discussion).
> 
> > Virtagent implements an RPC interface and uses xmlrpc-c to encode data
> > in XML.  This approach seems more general-purpose, extensible and easier
> > to manage over the long term than relying on a custom binary
> > representation.
> > 
> 
> Agree with the benefits, but there are other alternatives like I outlined
> in the thread that Gerd started, like a binary representation generated from
> declarative description. Totally agree with using a single definition to
> generate marshalling / demarshalling code. Not saying we can't work with
> xmlrpc for qemu<->guest but for qemu<->client I think it is too wasteful.
> 
> > As for event delivery, virtagent does not yet have an interface to allow
> > external programs to subscribe to events.  I am sure this can be done in
> > a generic way that is backwards-compatible with the current spice
> > architecture.  Such an interface should allow arbitrary programs to
> > subscribe to events but have no dependencies on those programs.  I am
> > not sure if something like D-Bus would be appropriate for Linux guests.
> > We'd need to consider Windows too.  
> > 
> 
> Really not sure what you mean by events here, maybe I missed something.

I was trying to get at the method by which a generic guest agent could
forward things like mouse coordinates to Spice.  Unfortunately, I sent
this out before I noticed the other thread which covered this topic
well.

> > I see no reason why the core qemu use cases (shutdown, exec, copyfile)
> > and the spice use cases (mouse, copy-paste, graphics reconfiguration)
> > cannot (and should not) be satisfied by a single agent.  Going forward,
> > I think we'd need to agree on the wire protocol and guest-side event
> > subscription.
> 
> At first glance, i'd say:
>  * development - how would we develop a shared agent? two forks and a upstream
>   that no one cares about? shared repository? seems easier to me to use
>   a shared protocol and separate agents. Also better bug wise (bug in our
>   code doesn't bring down your agent) to have separate agents. Plugins are
>   not any better bug wise (segfault is a segfault). Also languages become a
>   problem (our agents are in C++/C atm win/lin). So in summary I think it
>   is better to have a shared qemu code (this has to be a single exe) and
>   protocol perhaps.

I think it is critical that we have a single shared agent.  The agent
must be part of the default install of most future guests for any
host->guest API to be useful.  I will defer to discussions in the main
thread regarding the structure of the daemon(s).

>  * security - we don't need our agent to be able to execute or to copy files
>   or to shutdown, so we'd need some mechanism to turn those off. There is
>   another different agent (going over virtio-serial too) used for RHEV
>   which probably does need these kind of features, so maybe need to involve
>   them in this discussion too. (RHEV isn't open source yet but aims to be
>   AFAIK).

One idea that has been discussed is to restrict agent actions to
programs/scripts that exist in an virtagent.d/ directory (similar to how
udev rules are configured).  Virtagent could install a set of scripts
in /lib/virtagent/actions.d/ which can be overridden (or disabled) by
the user in /etc/virtagent/actions.d/.  If the 'shutdown' action is
missing, then the agent will not be able to perform shutdowns.

-- 
Thanks,
Adam