Daniel P. Berrange wrote:
quoted text
> 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.

quoted text
>  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).

quoted text
>  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

quoted text
> Daniel
>   

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html