Red Hat Bugzilla – Bug 1316911
'libvirt_driver_storage.so' fails to load due to "undefined symbol: rbd_diff_iterate2"
Last modified: 2016-03-11 08:49:17 EST
Description of problem
Post update to libvirt-1.3.2-2.fc25 (or libvirt-1.3.2-1.fc24), and
restarting the libvirt daemon, (a) previously existing VMs are not
enumerated; (b) explict attempt to define a guest fails with:
$ virsh define /etc/libvirt/qemu/devstack1.xml
error: Failed to define domain from devstack1.xml
error: invalid argument: could not find capabilities for arch=x86_64
While we're at it, I tried to explictly get capabilities this way, sure
enough it fails:
$ virsh cpu-models x86_64
error: failed to get CPU model names
error: this function is not supported by the connection driver: virConnectGetCPUModelNames
Okay, this error gives us a hint to check the `virsh uri`. Let's do
$ virsh uri
Whoops! Upgrading packages has reset the URI to "lxc:///", while we're
expecting it to be "qemu:///system".
Okay, let's try to explicitly set the URI, and try:
$ virsh -c qemu:///system list
error: failed to connect to the hypervisor
error: no connection driver available for qemu:///system
Why is it so? Let's quickly check if we have
'libvirt-daemon-driver-qemu' package is installed. Sure, we have it:
$ rpm -q libvirt-daemon-driver-qemu
But is 'libvirt_driver_storage.so' loaded for sure? Let's check
`journalctl` [I manually wrapped the error message]:
$ journalctl --since=today | grep libvirt_driver_storage.so Mar 11
06:04:04 foohost libvirtd: failed to load module
undefined symbol: rbd_diff_iterate2
Ah-ha! So, indeed, it failed to load due to "undefined symbol:
* * *
Downgrading the packages (`dnf downgrade libvirt\* qemu\*
--allowerasing`) and restarting the libvirtd restores the correct
behavior (for both defining guests, and getting CPU model info) -- as it
sets the URI back to "qemu:///system").
Maybe these are the perils of selective testing from Rawhide (or F24),
while on F23.
Tested with libvirt/QEMU packages updated to Rawhide
This is also reproducible with F24 (branched) with:
How reproducible: Consistently
Steps to reproduce
(1) If testing with packages Rawhide, update libvirt & QEMU packages :
$ sudo dnf install fedora-repos-rawhide
$ sudo dnf --releasever=24 update libvirt\* qemu\*
If you're on F24:
$ sudo dnf --releasever=rawhide update libvirt\* qemu\*
(2) Restart the libvirt daemon:
$ sudo systemctl restart libvirtd
(3) Enumerate instances (assuming you already had a few instances
defined before doing the package update):
$ virsh list --all
Nothing comes up.
So, try to explicitly define a VM:
$ virsh define devstack1.xml
Post libvirt/QEMU package update, the libvirt storage driver fails to
load, which results in the libvirt URI to changed to to "lxc:///" (while
we're expecting it to be "qemu:///system"). Which further leads to the
two commands from step (3) in the previous section fail (as expected?)
-- no instances are listed, and explicit attempt to define a guest fails
with errors mentioned in the description.
Libvirt storage driver should be loaded successfully.
As expected, updating the librbrd1* packages resolves the issue.
Update the librbd1* packages:
$ dnf --releasever=24 update librbrd1 librbd1-devel libsolv
[NB: 'libsolv' because, DNF itself breaks with the version in F23
(libsolv-0.6.14-7), so update to libsolv-0.6.19-2 on F24.)
$ systemctl restart libvirtd
_Now_ the URI is set correctly:
$ virsh uri
Closing it as NOTABG, as it's a dependency issue, and not libvirt bug per se. But, still wanted to report, in case others who hit this don't have to go through this.