If I have a volume group names 'vgvirt' with no logical volumes, there doesn't seem to be a directory under /dev whether the VG is marked 'available' or not. This might be different than behavior in older fedoras. Unfortunately this can break storageVolLookupByPath for an unrelated storage volume (depends on how libvirt orders pools internally): $ cat footest.py import os import sys import libvirt if os.getuid() != 0: print "run as sudo" sys.exit(0) conn = libvirt.open("qemu:///system") print conn.storageVolLookupByPath("/mnt/data/devel/media/win_xp_32_auto.iso") $ sudo python footest.py libvir: Storage error : cannot read dir '/dev/vgvirt': No such file or directory Traceback (most recent call last): File "footest.py", line 11, in <module> print conn.storageVolLookupByPath("/mnt/data/devel/media/win_xp_32_auto.iso") File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2801, in storageVolLookupByPath if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', conn=self) libvirt.libvirtError: cannot read dir '/dev/vgvirt': No such file or directory libvirt probably needs to be resilient to an empty vg and the lack of directory under dev that comes with it.
*** Bug 714431 has been marked as a duplicate of this bug. ***
We need to backport this to F16: commit 275155f664614fd32bcf5e963488e6f97b66dae4 Author: Cole Robinson <crobinso> Date: Wed Jan 25 12:07:14 2012 -0500 storage: Fix any VolLookupByPath if we have an empty logical pool On F16 at least, empty volume groups don't have a directory under /dev. The directory only appears once a logical volume is created. This tickles some behavior in BackendStablePath which ends with libvirt sleeping for 5 seconds while waiting for the directory to appear. This causes all sorts of problems for the virStorageVolLookupByPath API which virtinst uses, even if trying to resolve a path that is independent of the logical pool. In reality we don't even need to do that checking since logical pools always have a stable target path. Short circuit the polling in that case.
libvirt-0.9.6-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libvirt-0.9.6-5.fc16
Package libvirt-0.9.6-5.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-0.9.6-5.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3067/libvirt-0.9.6-5.fc16 then log in and leave karma (feedback).
libvirt-0.9.6-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.