Bug 1314230 - libvirt fails with undefined symbol
libvirt fails with undefined symbol
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
Depends On:
Blocks: F24BetaBlocker
  Show dependency treegraph
Reported: 2016-03-03 04:08 EST by John Dulaney
Modified: 2016-03-10 11:00 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-10 10:11:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Dulaney 2016-03-03 04:08:53 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):

How reproducible:

Steps to Reproduce:
1.  Upgrade libvirt stack to this release
2.  restart libvirtd
3.  failure

Actual results:
Failure; virt no work

Expected results:
Lack of failure; virt work
Comment 1 Fedora Blocker Bugs Application 2016-03-03 04:11:18 EST
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.
Comment 2 Ján Tomko 2016-03-03 11:19:02 EST
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
Comment 3 John Dulaney 2016-03-03 13:21:11 EST
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.
Comment 4 John Dulaney 2016-03-04 15:14:09 EST
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.
Comment 5 John Dulaney 2016-03-04 16:53:55 EST
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?
Comment 6 Kamil Páral 2016-03-07 12:34:37 EST
Discussed at today's blocker review meeting [1]. 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)

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-07/
Comment 7 Cole Robinson 2016-03-09 10:21:40 EST
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
Comment 8 John Dulaney 2016-03-10 10:11:33 EST
Okay, since it seems that the cause of this has gone away, I'm going to go ahead and close this here ticket.
Comment 9 Kamil Páral 2016-03-10 10:24:33 EST
John, does it work for you now? What changed?
Comment 10 John Dulaney 2016-03-10 11:00:47 EST
Yes, it's working for me now.  What changed is I just ran an update, pulled in the new libvirt build.

Note You need to log in before you can comment on or make changes to this bug.