On 10/21/2010 02:45 AM, Paolo Bonzini wrote:
On 10/21/2010 03:14 AM, Alexander Graf wrote:
I agree that some agent code for basic stuff like live snapshot
sync with the filesystem is small enough and worth to host within
qemu. Maybe we do need more than one project?
No, please. That's exactly what I don't want to see. The
libvirt/qemu/virt-man split is killing us already. How is this going
to become with 20 driver packs for the guest?
Agreed. Not relying on Mata Hari and reinventing a dbus/WMI interface
would be yet another case of QEMU NIH.
I think we're about 10 steps ahead of where we should be right now.
The first step is just identifying what interfaces we need in a guest
agent. So far, I think we can get away with a very small number of
interfaces (mainly read/write files, execute command).
The same argument also works on the backend BTW, it can be virtio
serial but also a Xen pvconsole and that wheel should not be
reinvented either.
The guest agent should be a pluggable architecture, and QEMU can
provide plugins for sync, spice, "info balloon" and everything else it
needs.
virtio-serial is essentially our plugin interface. The core QEMU agent
would use org.qemu.guest-agent and a spice against could use
org.spice-space.guest-agent.
The QEMU agent should have an interface that terminates in QEMU itself.
Regards,
Anthony Liguori
Paolo
