On Thu, Jan 13, 2011 at 01:44:50PM -0600, Adam Litke wrote: > 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). >
Having agents install by default in a guest is great, I guess it would be easier to justify a single agent install then multiple. But it would probably still have to be multiple packages, like your /lib/virtagent/actions.d scheme, where there would be a packages for (talking linux distribution specific for a second) virtagent-spice and virtagent-admin for instance, plus a virtagent which contains the actual agent. But this is getting into the structure of the daemon(s), so I guess better moved there? > > * 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 >
