RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 673499 - Some virsh vol-* commands require the pool option, but don't indicate this when they fail
Summary: Some virsh vol-* commands require the pool option, but don't indicate this wh...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-28 13:37 UTC by Justin Clift
Modified: 2015-07-13 04:35 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
No documentation needed.
Clone Of:
Environment:
Last Closed: 2012-06-20 06:25:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0748 0 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2012-06-19 19:31:38 UTC

Description Justin Clift 2011-01-28 13:37:17 UTC
Description of problem:

  We received a report from a RHEL 6 user, that some virsh vol-* commands are _failing_
  without a useful error message when the "--pool <name>" option isn't specified.

  For example:

    virsh # vol-list guests
    Nom                  Chemin                                  
    -----------------------------------------
    myrh6                /dev/vg_guests/myrh6                    
    myrh6-2              /dev/vg_guests/myrh6-2

    virsh # vol-path myrh6
    erreur :impossible de récupérer le volume 'myrh6'
    erreur :Storage volume not found: no storage vol with matching path

  If the vol-path command is given the "--pool guests" option (for this example),
  then the correct information is returned.

  The problem here is the vol-path seems to actually require the pool name, but
  isn't communicating this when it errors out.


Version-Release number of selected component (if applicable):

  libvirt 0.8.1-27.el6


How reproducible:

  Every time.


Steps to Reproduce:
  1. Create a persistent LVM storage pool in libvirt, then add a storage volume to it (refresh if needed)
  2. Run "vol-path" on the storage volume, leaving off the "--pool" option

  Error occurs here.

  
Actual results:

  As described in the problem description.


Expected results:

  A more informative error message should occur, indicating the requirement for the pool name


Additional info:

  This problem was reported to occur in both the vol-path command, and vol-dumpxml commands.

  It may also occur on others (untested).

  Also note, the pool type being used was LVM.  Other pool types were untested.

Comment 1 Justin Clift 2011-01-28 13:45:07 UTC
Ugh.  Typo in the "Description of problem".  Where is says "If the vol-path IS given... " it should be "ISN'T given". :(

Comment 7 Osier Yang 2011-09-20 08:33:45 UTC
This is NOTABUG, as there are multiple ways to lookup a volume, 1) virStorageVolLookupByName, 2) virStorageVolLookupByPath, 3) virStorageVolLookupByKey, only 1) needs a pool as argument, the other 2 only just need a connection to hypervisor, as another argument of them is global uniq (key/path).

So if no "--pool" is specified,  "vol-path" and "vol-dumpxml" will try to get the volume with methods 2) or 3).  Means "--pool" is not necessary.

Comment 8 Justin Clift 2011-09-20 12:06:25 UTC
Hey Osier,

When did it start checking for a volume in the available pools, before returning an error?

For example, with the version I'd filed the bug against, doing "vol-path myrh6" would give an error, as there wasn't enough info available for it to figure out where to check.

I guess by "So if no "--pool" is specified,  "vol-path" and "vol-dumpxml" will try to get the volume with methods 2) or 3)." you're meaning it will now check for "myrh6" in all of the available pools, then provide info for first match or something.

Is that correct?

Comment 9 Eric Blake 2011-09-20 19:31:06 UTC
(In reply to comment #8)
> Hey Osier,
> 
> When did it start checking for a volume in the available pools, before
> returning an error?
> 
> For example, with the version I'd filed the bug against, doing "vol-path myrh6"
> would give an error, as there wasn't enough info available for it to figure out
> where to check.

That's because 'myrh6' is neither a path nor a key, but a name relative to a pool.

> 
> I guess by "So if no "--pool" is specified,  "vol-path" and "vol-dumpxml" will
> try to get the volume with methods 2) or 3)." you're meaning it will now check
> for "myrh6" in all of the available pools, then provide info for first match or
> something.

No, to date, we've never had virsh look for myrh6 in all the available pools (although that might be a nice feature enhancement, if we can find a single volume named myrh6 among all the pools; while still failing if myrh6 is ambiguous between multiple pools).

Comment 10 Dave Allan 2011-09-20 20:43:33 UTC
IMO we should just add a suggestion to the failure message as we do for some others:

"perhaps you need to specify --pool?"

Comment 11 Justin Clift 2011-09-21 02:02:12 UTC
Yeah, adjusting the failure message seems like the simplest option.

Eric's sounds more user friendly though, as it lets people "type less" and still get the result they want (when it's deterministic). ;)

Comment 12 Osier Yang 2011-09-21 02:18:23 UTC
<snip>
No, to date, we've never had virsh look for myrh6 in all the available pools
(although that might be a nice feature enhancement, if we can find a single
volume named myrh6 among all the pools; while still failing if myrh6 is
ambiguous between multiple pools).
</snip>

@Eric, Am I missed something? It looks to me it looks up all pools indeed. See
storageVolumeLookupByPath and storageVolumeLookupByKey.

Comment 13 Osier Yang 2011-09-21 10:14:54 UTC
Patch posted to upstream

http://www.redhat.com/archives/libvir-list/2011-September/msg00803.html

Comment 14 Osier Yang 2011-09-22 00:20:47 UTC
patch committed to upstream.

Comment 20 Huang Wenlong 2012-01-06 07:08:37 UTC
Verify this bug with libvirt-0.9.9-0rc1.el6.x86_64


# virsh vol-list default
Name                 Path                                    
-----------------------------------------
q2.img               /var/lib/libvirt/images/q2.img          

# virsh vol-path q2.img
error: failed to get vol 'q2.img', specifying --pool might help
error: Storage volume not found: no storage vol with matching path

# virsh vol-path q2.img --pool default
/var/lib/libvirt/images/q2.img




# rpm -q libvirt
libvirt-0.9.9-0rc1.el6.x86_64

Comment 21 Osier Yang 2012-05-04 09:45:57 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed.

Comment 23 errata-xmlrpc 2012-06-20 06:25:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html


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