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 :-) Cheers, Mark.