[Libvir] Virtual networking

[Daniel P. Berrange]

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.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|