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
