On 10/21/2010 03:02 PM, Anthony Liguori wrote:
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.
I agree that for some think with semi-transaction oriented actions like
the fs-freeze on live snapshot, we need a small, self confined code base.
Regards,
Anthony Liguori
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
