On Wed, Jan 17, 2007 at 06:50:47AM -0500, Daniel Veillard wrote: > 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 Do you talk about multi-user OS? :-) It's practical for desktop workstation only. > > 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. I'm not sure if the idea is completely wrong. I think possible advantage is that the libvirt will be pretty simple library and almost all development (on drivers) will be happen in the libvirtd. Karel -- Karel Zak <kzak@xxxxxxxxxx>
