On Fri, Oct 24, 2014 at 02:40:27PM -0400, Laine Stump wrote: > On 10/23/2014 11:14 AM, Daniel P. Berrange wrote: > > Currently we have a bit of a craz setup for activating > > drivers for virConnectPtr. We iterate over the primary > > hypervisor drivers until one matches and activates. This > > bit is fine. > > > > Then we do the same for the network, storage, interface, > > etc secondary drivers. This is where the fun starts. > > > > In the case of the stateless drivers that run outside > > of libvirtd, they always want the secondary drivers to > > match the primary driver. Unfortunately if they don't > > register any dummy secondary driver they'll get given > > the reomte driver instead. The probing of secondary > > drivers is really unhelpful here. > > > > In the case of stateful drivers that run inside of > > libvirtd, there is (almost) always only one driver instance > > that they want to work with. So at best the probing of > > secondary drivers is a waste of time. With the increasing > > feature set though we're getting tight dependancies from > > the hypervisor driver to the secondary driver. eg QEMU > > depends on the specific network driver we have because it > > calls various internal APIs it exposes. > > I have never liked the sneakiness of those backdoor private APIs into > the network driver, but didn't see a reasonable way around it at the > time I added them in, and they worked, and nobody NACKed them... I think > they should maybe be replaced by full fledged public APIs, but they need > to be defined in a much more complete and future-proof fashion. Of > course calling them would then require the ability to call a public > libvirt API from within another public libvirt API (actually, I guess we > already do this when we call virNetworkLookupByName() and > virNetworkGetBridgeName() from qemuNetworkIfaceConnect(), but I think > it's slightly accidental that that works). Yeah, at some point we should figure out a less hacky way to achieve this all, but I dont have good ideas right now either. > > > > > We also have circular dependancy problems during libvirtd > > startup: > > > > https://www.redhat.com/archives/libvir-list/2014-January/msg01143.html > > > > There the storage driver needs a virConnectPtr instance in > > order to talk to the secret driver. At the same time the > > storage driver must run before the hypervisor driver because > > the hypervisor driver needs to use it for autostart of VMs. > > This is a horrible mess. > > > > The solution I think is to remove the concept of probing for > > secondary drivers entirely. Instead I suggest creating a > > > > struct virDriver { > > ... > > } > > > > which contains a pointer to virHypervisorDriver, > > virNetworkDriver, virInterfaceDriver, etc. now virConnectPtr > > will only reference the single virDriverPtr and when we open > > a hypervisor driver, we immediately get a full set of APIs > > for everything. This way all the hypervisor drivers will > > always know exactly what secondary driver they are working > > with. > > The one thing this will obstruct is the ability to use two different > secondary drivers at the same time; I don't know if this will be an > issue. An example of what could lead to this - we might decide to > implement a separate network driver that uses Open vSwitch as the > backend rather than the Linux host bridge, but want to allow use of both > on the same system. Or perhaps we might decide we want to have a > separate backend for nwfilter that uses the OVS version of flow > management (or whatever they call it) instead of iptables. (Well, those > are actually probably not very good examples, because (for the network > case) we already demonstrate how both could be supported by the same > driver in our parallel support of "unmanaged" networks that can point to > either a host bridge or and OVS bridge, and (for the nwfilter case) it > isn't apparent how or by whom the choice of which driver to use would be > made.) > > So maybe that isn't a problem at all :-) The two places we have multiple impls are - node devices - HAL vs udev. We figure out the impl at time libvirtd starts up, so not a problem - interfaces - netcf vs udev. Again we figure out ipl at startup So I don't think we need to care about multiple drivers for the same APIs, at virConnectOpen() time. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list