Re: [Libvir] Virtual networking

On Tue, Jan 16, 2007 at 07:35:37PM +0000, Daniel P. Berrange wrote: > On Tue, Jan 16, 2007 at 07:09:30PM +0000, Daniel P. Berrange wrote: > > On Tue, Jan 16, 2007 at 05:21:15PM +0000, Mark McLoughlin wrote: > > > - Or perhaps, libvirt would *always* talk to a daemon ... whether > > > local or remote. That way you don't have the race condition where > > > multiple apps can create a guest of the same name or uuid at once. > > > > Possibly :-) I think I'll draw another diagram... > > One way is to move the entire driver model out of libvirt and into a daemon, > so that libvirt itself is just a very thin layer which marshalls APIs calls > onto the wire. So whether local or remote the diagram looks the same: > > http://people.redhat.com/berrange/libvirt/libvirt-arch-local-1.png > http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-3.png > > Now you might say this will make the Xen stack inefficient, because there > will be yet another daemon in the stack. This could certainly be true if > the libvirt daemon only ever talked to XenD, but all our performance > critical calls go straight to the HV. So when talking to a remote daemon > I think libvirt -> libvirt daemon -> HV ought to be faster than libvirt -> > XenD -> HV, simply by virtue of not involving python. It would also make > it practical to run virt-manager as an unprivileged app even when managing

> the local Xen instance. So we could remove the need to su to root for > the local instance.

Hum, honnestly I would *really* prefer to avoid systematically going though an RPC. No I don't like this idea, I prefer to keep the driver in libvirt linked in the user's space. Thibgs which were dirt cheap become way more expensive when they don't need to, this is a severe regression from a library user standpoint.