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@redhat.com>