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.