[Libvir] Virtual networking

[Karel Zak]

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