Commit v4.2.0-104-g4d7384eb9d fixed the race condition when calling *LookUpBy* APIs. Previously, if one did multiple calls of the same *LookUpBy* API it resulted in the resources requested not being found, even though they exist, because the hash table that is used to store the resources was locked. From the libvirt logs one can see: error : virHashSearch:727 : Hash operation not allowed during iteration ... debug : storageVolLookupByKey:1567 : Storage volume not found: no storage vol with matching key ... So the storageVolLookupByKey API fails to find volume although the looked up storage key exists. How reproducible: One need to concurrently run multiple calls of one of StorageVolLookupByKey API for example. Additional info: The bug is already fixed in libvirt v4.3.0 but commit v4.2.0-104-g4d7384eb9d needs to be backported so that it's available in fedora-28, because it blocks libvirt/cockpit integration project from using LookupBy* APIs in libvirt-dbus bindings.
libvirt-4.1.0-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-43b2955a9a
libvirt-4.1.0-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-43b2955a9a
libvirt-4.1.0-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1626680 has been marked as a duplicate of this bug. ***