[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