On Thu, Jan 25, 2007 at 04:07:57PM +0000, Mark McLoughlin wrote: > On Thu, 2007-01-25 at 16:02 +0000, Daniel P. Berrange wrote: > > > That's an interesting idea - your description.. > > > > "a virConnectPtr is a connection to a specific hypervisor > > *and* the virtual network supervisor" > > > > ..makes me thing of a slightly alternative impl. We currently have > > a single internal driver API 'virDriverPtr' which is just a list of > > function pointers for all the HV related calls. Rather than making that > > struct bigger to add in networking calls, how about we define two separate > > internal driver APIs > > > > virHypervisorDriver > > virNetworkDriver > > > > It strikes me that most of the different hypervisor backends will simply > > want to re-use the same network driver backend, so why not properly > > de-couple them. The virConnectOpen function would thus first lookup > > a hypervisor driver, and then lookup a networking driver. This avoids > > the somewhat nasty issue of having to figure out how to activate > > multiple non-conficting drivers to get the correct combo of HV & network > > stuff. > > Yep, that'd be the best way to do it. > > > The only small complication would be ensuring that the HV driver and > > network driver didn't need to open 2 separate TCP connections to the > > same place, but I'm sure we'd be able to figure that out. > > Yep. > > (Also, if we go with this approach, we should probably also do > s/qemud/libvirtd/ or something ... but we need to figure out what to do > wrt. the "other libvirtd" first :-) Indeed - since Rich Jones is looking at a more general purpose libvirtd, we can adapt QEMU impl to play nicely with the generic daemon. I figure separate out the QEMU bits from qemud and turn them into a regular libvirt driver. Then set it up so that this driver is only used when invoked by the libvirtd, and not ever directly by the client lib - that way we still ensure a single daemon managing QEMU per node, without coupling the QEMU impl to the daemon itself. 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 -=|