Red Hat Bugzilla – Bug 1314230
libvirt fails with undefined symbol
Last modified: 2016-03-10 11:00:47 EST
Description of problem:
libvirt starts, but the qemu module fails to load. systemctl status gives me:
failed to load module /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so: undefined symbol: virStorageFileCreate
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade libvirt stack to this release
2. restart libvirtd
Failure; virt no work
Lack of failure; virt work
Proposed as a Blocker for 24-beta by Fedora user jdulaney using the blocker tracking app because:
The release must be able host virtual guest instances of the same release.
As the default virt stack is kvm/qemu/libvirt, and the bits between libvirt and qemu are failing due to an undefined symbol, virt doesn't work, thus hitting this criteria.
This looks like bug 1164773 which was solved by a device-mapper update.
Do you see any other errors in the log?
$ journalctl -u libvirtd --since=yesterday -p err
No other errors of note.
With my update this morning, qemu and libvirt were both updated. Device mapper was not changed, and prior to this update, qemu/libvirt was working just fine. The bug you reference points the blame at devicemapper, but I fail to see how that could be the culprit in htis case.
Okay, I downgraded to 1.3.1-2, and the issue went away, strongly suggesting that this is an issue with the latest release of libvirt. I'm going to do a rebuild right quick just to see if something went weird.
Okay, just rebuilding seems to have corrected this issue. Looks like something got weird in the build process. If I reinstall the 'official' build, problem comes back. Would it be possible to get a rebuild of libvirt?
Discussed at today's blocker review meeting . Accepted as a Beta blocker - as described this sounds like a clear violation of Beta criterion "The release must be able host virtual guest instances of the same release." (with footnote describing the supported virt stack, including libvirt)
I can't reproduce this on f24 with libvirt-1.3.2-1, using fully updated f24
John, is your machine fully updated? Can you still reproduce this? What version of device-mapper-libs is installed? Mine is:
# rpm -q device-mapper-libs
Okay, since it seems that the cause of this has gone away, I'm going to go ahead and close this here ticket.
John, does it work for you now? What changed?
Yes, it's working for me now. What changed is I just ran an update, pulled in the new libvirt build.