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