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

[Alon Levy]

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

Like I said in the beginning, I should go and read up on virtagent, and come
back..

> 
> Thoughts?
> 

There you go :)

> -- 
> Thanks,
> Adam
> 
Alon