Daniel P. Berrange wrote:
On Sun, Dec 14, 2008 at 01:15:42PM -0600, Anthony Liguori wrote:
One non-QEMU backend I can see being implemented is a DBus daemon,
providing a simple bus for RPC calls between guests & host.
The main problem with "external" backends is that they cannot easily
participate in save/restore or live migration. If you want to have an
RPC mechanism, I would suggest implementing the backend in QEMU and
hooking QEMU up to dbus. Then you can implement proper save/restore.
Or on
a similar theme, perhaps a QPid message broker in the host OS. Yet
another backend is a clustering service providing a virtual fence
device to VMs.
Why not use virtual networking for a clustering service (as you would in
real machines).
All of these would live outside QEMU, and as such
exposing the backend using the character device infrastructure
is a natural fit.
If you don't have QEMU as a broker, it makes it very hard for QEMU to
virtualization all of the resources exposed to the guest. This
complicates things like save/restore and complicates security policies
since you now have things being done on behalf of a guest originating
from another process. It generally breaks the model of guest-as-a-process.
What's the argument to do these things external to QEMU?
Regards,
Anthony Liguori
Daniel
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
