Bug 709265
| Summary: | empty vg storage pool can break GetVolumeByPath for all pools | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Troels Arvin <troels> |
| Component: | libvirt | Assignee: | Osier Yang <jyang> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | ajia, dallan, dyuan, mzhan, rwu, whuang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0.9.9-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
No documentation needed.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 06:28:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Troels Arvin
2011-05-31 08:38:46 UTC
Note - corresponding to the pause between the step between shot 5 and 6, the following line appears in /var/log/messages: May 31 09:45:35 linvirt2 libvirtd: 09:45:35.731: 14409: error : virStorageBackendStablePath:1320 : cannot read dir '/dev/linvirt2_vg_fc15b': No such file or directory This problem seems to confuse virt-manager so much that it gives up(?). That error from the logs is the root problem. virt-manager is trying to detect if the specified path is libvirt managed storage. It does so by calling virStorageVolumeLookupByPath. The empty VG is causing that call to fail, even though the passed in path is indeed a storage volume. virt-manager then does some more checks, sees that the root of the path /dev/existingvg is an existing storage pool, assumes you want to create a new volume named /dev/existingvg/existingvol, tries to use that name, and libvirt tells us it's taken. I've committed an extra check in upstream virtinst that will make virt-manager check harder event if GetVolumeByPath fails, but libvirt needs to be fixed. Reassigning this bug to libvirt And to clarify, an empty vg pool doesn't break GetVolumeByPath for every lookup, just for those pools who happen to come sequentially after the busted pool in libvirt's internal pool list, so just defining an empty vg pool might not cause the issue to easily reproduce. The root cause is the error: virStorageBackendStablePath:1320 : cannot read dir '/dev/linvirt2_vg_fc15b': No such file or directory Patch posted to upstream. http://www.redhat.com/archives/libvir-list/2011-September/msg00820.html patch commited to upstream.
commit 05e2fc51d1f4ba884a18c23c924d90cfd04384e3
Author: Osier Yang <jyang>
Date: Mon Sep 26 14:30:44 2011 +0800
storage: Do not break the whole vol lookup process in the middle
* src/storage/storage_driver.c: As virStorageVolLookupByPath lookups
all the pool objs of the drivers, breaking when failing on getting
the stable path of the pool will just breaks the whole lookup process,
it can cause the API fails even if the vol exists indeed. It won't get
any benefit. This patch is to fix it.
(In reply to comment #0) > Description of problem: > > Version-Release number of selected component (if applicable): > virt-manager-0.8.6-4.el6.noarch > > How reproducible: > Every time. > > Steps to Reproduce: > 1. Create a volume group, but don't create any logical volumes from it yet. > 2. Use virt-manager to create a new virtual server. (Or add to an existing > one.) > 3. In the storage selection step, choose "Select managed...", "Browse". > 4. Select a storage pool from a VG which already has at least one LV. > 5. Create a volume, and "Choose Volume" I can't reproduce this issue on libvirt-0.9.4-1.el6_x86_64 with virt-manager-0.8.6-4.el6.noarch according to above steps, and could you give me your libvirt version? In addition, IMHO, 0.9.4-1(before Sep 26) is enough to verify this bug, but I indeed can't reproduce it. Osier, I guess you should reproduce the bug, right? if so, please commit it, thanks. # pvdisplay --- Physical volume --- PV Name /dev/sda3 VG Name vg1 PV Size 9.77 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 2499 Free PE 499 Allocated PE 2000 PV UUID mOej86-t93k-t2ai-E2XQ-BOJ1-e3AS-ZbTGbc "/dev/sda2" is a new physical volume of "9.77 GiB" --- NEW Physical volume --- PV Name /dev/sda2 VG Name PV Size 9.77 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 8gWeh1-rl08-yuDR-ZqPJ-sKFj-uQ7b-IRTz6c # vgdisplay --- Volume group --- VG Name vg1 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 9.76 GiB PE Size 4.00 MiB Total PE 2499 Alloc PE / Size 2000 / 7.81 GiB Free PE / Size 499 / 1.95 GiB VG UUID u2HMVM-9xOd-7d8a-yovr-TlTH-rVvV-lyOSW0 # lvdisplay --- Logical volume --- LV Name /dev/vg1/test VG Name vg1 LV UUID UEXCWp-MiN7-efF2-6SFY-913u-Wy1M-iRdBiA LV Write Access read/write LV Status available # open 1 LV Size 7.81 GiB Current LE 2000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 I have changed job, and I don't have access to any RHEL servers with libvirt, currently. (In reply to comment #10) > I have changed job, and I don't have access to any RHEL servers with libvirt, > currently. Hi Troels, Thanks for your reply, no problem, I will check it again. Alex I can reproduce the bug on libvirt-0.9.4-1.el6.x86_64, I think it's helpful to show test steps in here: Create a empty VG such as vg1 according to original bug description, then create a volume such as foo.img in 'default' pool: # virsh pool-list Name State Autostart ----------------------------------------- default active yes vg1 active yes # virsh vol-list vg1 Name Path ----------------------------------------- # virsh vol-list default Name Path ----------------------------------------- foo.img /var/lib/libvirt/images/foo.img # virsh vol-path vg1 /var/lib/libvirt/images/foo.img error: failed to get pool '/var/lib/libvirt/images/foo.img' error: failed to get vol 'vg1' error: cannot read dir '/dev/vg1': No such file or directory The 0.9.9-1 is fine, every lookup hasn't been broken by GetVolumeByPath, and I can also see a new warning in log file, the patch is valid: warning : storageVolumeLookupByPath:1255 : Failed to get stable path for pool 'vg1' But, it exists another issue, I will file a separated bug to trace it. (In reply to comment #12) > But, it exists another issue, I will file a separated bug to trace it. New issue: virsh vol-path can't correctly display which pool a volume belongs to https://bugzilla.redhat.com/show_bug.cgi?id=781515
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.
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 |