Re: Virtual box storage and network sub-drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
AuthorDate: Fri Aug 15 12:26:09 2014 +0200
Commit:     Michal Privoznik <mprivozn@xxxxxxxxxx>
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@xxxxxxxxx>
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]