On Mon, Dec 05, 2011 at 03:36:59PM -0600, Michael Roth wrote:
> On 12/05/2011 01:21 PM, Chris Wright wrote:
> >* Chris Wright (chr...@redhat.com) wrote:
> >>* Anthony Liguori (aligu...@us.ibm.com) wrote:
> >>>1. A short introduction to each of the guest agents, what guests they
> >>>support, and what verbs they support.
> >>
> >>I think we did this once before w/ Matahari. Can we please capture
> >>these things in email before the call, so people actually have time
> >>to ponder the details.
> >>
> >>>2. A short description of key requirements from each party (oVirt, libvirt,
> >>>QEMU) for a guest agent
> >>
> >>Same here...call this the abstract/intro of the above detailed list of
> >>verbs and guest support, and send it by Friday this week.
> >>
> >>I know there's plenty of details buried in the current thread and old
> >>discussions of Matahari. But that's just it...buried...
> >
> >It's past Friday. Barak's links are all we have so far...
>
> Sorry this slipped by me. However, Barak's link to the guest agent
> proposals:
>
> http://www.ovirt.org/wiki/Guest_agent_proposals
>
> is a summary of the recent discussion on guest agents for oVirt from
> the following thread:
>
> http://thread.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/93/focus=93
>
> Requirements were posted there for oVirt (ovirt-guest-agent), QEMU
> (qemu-ga), and Spice (vdagent) and pulled into wiki, so as far as
> requirements go that is probably the best summary available at the
> moment. There is also summary of the current proposals for how to go
> about leveraging ovirt-guest-agent or qemu-ga for oVirt/QEMU
> requirements.
>
> Matahari was mentioned only in brief since it didn't come up much in
> that particular discussion, but feel free to add as a response to
> this email and I can add it to the wiki so we can start getting all
> this stuff in one place.
>
> But for brevity, a (slightly) higher-level summary would be:
>
> A. oVirt (currently using ovirt-guest-agent)
>
> 1) supported functionality:
> - protocol: JSON RPC over virtio-serial
> - verbs: lock screen, login/logoff (automatic/SSO on
> RHEL/Windows with plugins installed), shutdown
> - guest info: machine name, OS, packages, avail. RAM, logged
> in users, disk usage, networks interfaces
> - notifications: guest/agent up, heartbeat, user info, session
> lock/unlock/logoff/logon, agent uninstalled
>
> 2) key requirements:
> - first-class support for oVirt guest extensions
> - VM life-cycle assistance
> - single sign-on support for spice desktop sessions
> - monitoring and inventory
> - make VDSM management more robust/guest-aware
>
> 3) additional info:
> - http://www.ovirt.org/w/images/2/20/Ovirt-guest-agent.pdf
> - http://www.ovirt.org/wiki/Ovirt_guest_agent
>
>
> B. QEMU (currently using qemu-ga):
>
> 1) supported functionality:
> - protocol: JSON RPC (QMP) over virtio-serial/"isa"-serial
> - verbs: ping, agent info, shutdown, file
> open/read/write/seek/flush/close, filesystem freeze, command exec
> (experimental, RFC this week)
> - guest info: arbitrary (via file read/command exec)
> - notifications: on hold till QMP/QAPI integration completed
> 2) key requirements:
> - first-class support for QEMU guest extensions (usable by
> device model, integrated into QMP, same repo (for lock-step
> versioning and hypervisor deployability via ISO or other
> host-initiated mechanism rather than guest distro support)
> - implement low-level primitives that QEMU can use,
> higher-level functionality built on top of the QMP interfaces it
> exposes.
> 3) additional info:
> - http://wiki.qemu.org/Features/QAPI/GuestAgent (might be down
> atm =/)
>
>
> C. Spice (vdagent):
>
> 1) supported functionality:
> - protocol: binary RPC over virtio-serial
> - verbs: set mouse state, monitor/display config, copy/paste
> 2) key requirements:
> - first-class support for Spice extensions (managing QXL
> devices/displays remotely, desktop integration (copy/paste, etc)
> - session-level guest agent
> 3) additional info:
> - http://spice-space.org/page/Whiteboard/AgentProtocol
>
4) binary data passthrough for copy-paste.
Any large file would otherwise go through uuencode / uudecode
needlessy (it cannot be verified in anyway with any schema since
it's by definition opaque).
Sorry for the late reply.
> Please feel free to add to this, and I'll roll it back into the wiki.
>
> >
> >thanks,
> >-chris
> >
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
