[Libvir] Virtual networking

Hugh Brock hbrock at redhat.com
Tue Jan 16 16:21:07 UTC 2007


Daniel P. Berrange wrote:
> 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.

This strikes me as *much* easier to manage, and the most consistent thus 
far with the idea that libvirt should remain as hypervisor-neutral as 
possible.

--H




More information about the libvir-list mailing list