4:06 a.m.
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?
Reported-by: Taowei Luo
Michal
4:23 a.m.
On 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?
It should simply be a matter of changing the order of registration. ie
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 :|
9:23 p.m.
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(a)redhat.com>:
On 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?
It should simply be a matter of changing the order of registration. ie
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
:|
2:28 a.m.
On 19.08.2014 04:23, Taowei Luo wrote:
It seems I can make the vbox driver work by changing the registration
order in daemonInitialze.
This is what I've done when fixing the problem:
commit 65b7d553f39ff958d580df871e90aefd30ea3466
Author: Michal Privoznik <mprivozn(a)redhat.com>
AuthorDate: Fri Aug 15 12:26:09 2014 +0200
Commit: Michal Privoznik <mprivozn(a)redhat.com>
CommitDate: Mon Aug 18 11:49:10 2014 +0200
daemon: Fix driver registration ordering
There are some stateless drivers which implement subdrivers
(typically vbox and its own network and storage subdrivers). However,
as of ba5f3c7c8ecc10 the vbox driver lives in the daemon, not the
client library. This means, in order for vbox (or any stateless domain
driver) to use its subdrivers, it must register before the general
drivers. Later, when the virConnectOpen function goes through the
subdrivers, stateless drivers are searched first. If the connection
request is aiming at stateless driver, it will be opened. Otherwise
the generic subdriver is opened.
The other change done in this commit is moving interface module load a
bit earlier to match the ordering in case libvirt is built without
driver modules.
Reported-by: Taowei Luo <uaedante(a)gmail.com>
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
If you pull the fresh HEAD you'll see it.
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.
The sub-drivers are not necessarily to be used in daemon. Aim of their existence is usage
in client. This is one of the main differences between stateful and stateless drivers.
While for instance QEMU or LXC are stateful drivers (they have to track the state of
domains, prepare host environment for guest execution, etc.) VBOX is on the other end of
the spectrum. It takes care of everything and libvirt merely translate its API into VBOX
ones. So while in QEMU we need to create a guest interface ourselves (and hence we're
calling many network APIs), there's no need to do that in VBOX driver.
Michal
3749
days inactive
3753
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Michal Privoznik -
Taowei Luo