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.