It seems I can make the vbox driver work by changing the registration order in daemonInitialze. So, I can do test with it for now.
But I still don't understand why libvirt keep the vbox network and storage driver. I don't find anyway else than libvirtd that uses vbox driver.
Meanwhile, the daemonInitialize registers general driver prior to vbox driver, which makes the vbox driver actually unused.
2014-08-15 17:23 GMT+08:00 Daniel P. Berrange <berrange@xxxxxxxxxx>:
It should simply be a matter of changing the order of registration. ieOn Fri, Aug 15, 2014 at 11:06:18AM +0200, Michal Privoznik wrote:
> Dear list,
>
> Virtualbox driver has its own implementation of storage and network
> sub-drivers. But as of commit ba5f3c7c8ecc1037e44904916989a1c65777a9d5
> (contained in the 1.0.6 release) when the VBox moved from client to daemon,
> the storage and network sub-drivers are indeed registered but in fact never
> called. It's due to our virConnectOpen function where the general network
> and storage drivers take precedence. So I guess my question is: should we
> drop the VBox sub-drivers or perhaps fix the virConnectOpen function?
we want to call vboxRegister before storageRegister, so that the vbox
storage driver is first in the list. The vbox storage driver is written
so it is a no-op unless the primary virt driver is vbox.
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