[Libvir] Virtual networking

[Daniel P. Berrange]

On Mon, Jan 15, 2007 at 08:53:43PM +0000, Mark McLoughlin wrote:
> Hi,
> 	One thing which is relevant to Dan's authentication stuff ...
> 
> On Mon, 2007-01-15 at 20:06 +0000, Mark McLoughlin wrote:
> 
> >       * Since virConnect is supposed to be a connection to a specific
> >         hypervisor, does it make sense to create networks (which should
> >         be hypervisor agnostic) through virConnect? 
> 
> 	Personally, I think virConnect should be little more than a library
> context through which you access all hypervisors at once. In practical
> terms, the XML describing a domain is what chooses which hypervisor to
> connect to - e.g. all apps should pass NULL to virConnectOpen() and all
> drivers should handle NULL.
> 
> 	The one exception to that is for remote connections. In that case apps
> should pass a URI for a remote libvirt daemon which, in turn, would be
> equivalent to calling virConnectOpen(NULL) on the remote host.
> 
> 	So, remotely connecting directly to a hypervisor should be deprecated.

Having been kept away last night thinking about the implications of this
I think you're description above could actually work, with a fairly small
modification. But first, some pretty pictures:

1. The simple (current) usage of using libvirt to connect to a local 
   hypervisor. Showing two examples - first how the current Xen backends
   works, and second how my prototype QEMU backend works:

   http://people.redhat.com/berrange/libvirt/libvirt-arch-local.png

2. The way I was always anticipating remote use of libvirt to work. The
   app uses libvirt locally which opens a connection to the remote machine
   using whatever remote management protocol is relevant for the hypervisor
   in question. eg, HTTP/XML-RPC for Xen, or the TLS secured binary format
   for the prototype QEMU backend.

   http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-1.png

3. The way I think you re suggesting - a libvirt server on every remote
   host which calls into the regular libvirt internal driver model to
   proxy remote calls. So even if the hypervisor in question provides a
   remote network management API, we will always use the local API and
   do *all* remote networking via the libvirt server

   http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-2.png

NB, the local case 1, is basically unchanged regardless of which of the
two remote architectures we consider.

Option 3 has some interesting properties:

 - For QEMU & UML we essentially already have to write a 'libvirt server'
   since those two don't have any existing remote maangement service.

 - The same network transport & authenticate system would be used across
   all hypervisor technologies we support, giving a consistent model.

 - Remote Xen access would be able to bypass XenD in the common case
   just like we do for the local Xen access

On the flip-side:

 - We would be using a different remote managemnent API for Xen compared
   to other apps which might talk Xen-API directly - if people had a mix
   of apps some using libvirt & some native Xen-API they'd have to manage
   remote access for two services.

So, going back to how this would work...

  - We'd supply URIs describing the hypervisor connection to open to the
    virConnectOpen() method as usual

  - If the URI does not contain a hostname, then one (or more) of the 
    regular libvirt drivers would be activated to open a local connection
    to the HV.

  - The the URI does contain a hostname, then the special 'remote' driver
    would be activated. This opens a connection to the remote libvirt
    server on that host, strips the hostname out of the URI, and sends
    this stripped URI to the libvirt server. This then opens the local
    hypervisor connection & does pass-through of all remote calls to
    this connection.

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  -=|