Bug 782261 - Empty volume group pool on F16 breaks most storageVolLookupByPath
Empty volume group pool on F16 breaks most storageVolLookupByPath
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
: 714431 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-16 19:56 EST by Cole Robinson
Modified: 2012-03-17 19:45 EDT (History)
13 users (show)

See Also:
Fixed In Version: libvirt-0.9.6-5.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-17 19:45:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2012-01-16 19:56:11 EST
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.
Comment 1 Cole Robinson 2012-01-24 20:40:51 EST
*** Bug 714431 has been marked as a duplicate of this bug. ***
Comment 2 Eric Blake 2012-01-25 13:56:52 EST
We need to backport this to F16:

commit 275155f664614fd32bcf5e963488e6f97b66dae4
Author: Cole Robinson <crobinso@redhat.com>
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.
Comment 3 Fedora Update System 2012-03-04 11:21:44 EST
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
Comment 4 Fedora Update System 2012-03-06 14:34:11 EST
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).
Comment 5 Fedora Update System 2012-03-17 19:45:24 EDT
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.

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