Bug 476117 - vgrename on UUID renames wrong /dev node
vgrename on UUID renames wrong /dev node
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Peter Rajnoha
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-11 18:50 EST by Tom Lanyon
Modified: 2012-01-19 18:04 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:57:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Lanyon 2008-12-11 18:50:37 EST
Description of problem:
Having two LVM volume groups with the same name is a common scenario with virtualisation. To solve conflicts, the vgrename util can rename one of these by referring to its UUID rather than its name; however, it also renames the VG's directory in /dev but bases this on name rather than UUID.


Version-Release number of selected component (if applicable):
lvm2-2.02.32-4.el5


How reproducible:
Every time, in the case of duplicate VG names.


Steps to Reproduce:
1. Have two VGs with the same name (in this scenario, the second VG with 20 #LVs is "active" and has devices in /dev/vg:

# vgs
  VG    #PV #LV #SN Attr   VSize   VFree  
  vg      1   1   0 wz--n- 193.25G  32.00M
  vg      1  20   0 wz--n- 467.06G 104.94G

2. Rename the 'other' VG by its UUID:

# vgrename 4tns75-wbTQ-mtB0-DXBY-IQZY-9PaE-zTBuYM non_dom0_vg
  WARNING: Duplicate VG name vg: Existing wRVn2V-IGLW-1evz-iNR3-C2DJ-6iy6-LDU9B1 (created here) takes precedence over 4tns75-wbTQ-mtB0-DXBY-IQZY-9PaE-zTBuYM
  Volume group "vg" successfully renamed to "non_dom0_vg"

3. Check for /dev/vg and find that it's missing and has been renamed to /dev/non_dom0_vg
  
Actual results:
The /dev directory of the VG we're *not* renaming has been moved.

Expected results:
The /dev directory of the VG we're *not* renaming should not be moved.


Additional info:
I don't believe there's any ties between the VG and the /dev symlinks so I am not suggesting the LVM utils "know" which directory to move or not.

Perhaps the best solution is to either not rename the /dev directory when renaming based on UUID and just print a "Please make sure your /dev links are updated" message (assuming that if you are renaming based on UUID then you know what you're doing)?

Alternatively, perhaps a flag could be added to vgrename to prevent the /dev directory from being renamed, so users could explicitly avoid this when renaming based on UUID if they believe it to be necessary?
Comment 1 Alasdair Kergon 2008-12-11 20:50:51 EST
LVM should have all the info it needs to handle this correctly - it's just a straightforward bug.

See also fedora bug 449128
Comment 2 Jaroslav Stava 2008-12-11 21:49:05 EST
Reproduced in cvs.

What is the point in renaming /dev/VG when no active LVs are allowed 
during rename?
Comment 3 Peter Rajnoha 2008-12-12 02:46:19 EST
It's true that it is not allowed these days. But there's a plan for rename-while-active to work in the future.
Comment 4 Peter Rajnoha 2008-12-17 09:45:46 EST
This bug is caused by not taking into account the possibility of such situation (same name for VGs), so the vgrename code just renames the directory in a simple  and direct way by its name.

Talked with Alasdair about this, it could be solved quite easily by incorporating the "lvchange --refresh" logic in vgrename code, so the links would be recreated correctly (the /dev/VGNAME directory won't be renamed directly, but we will process each symlink one by one to move it into another directory /dev/VGNAME_NEW).
Comment 5 Peter Rajnoha 2008-12-19 10:38:49 EST
The fix has been uploaded to upstream CVS.
Comment 6 Milan Broz 2009-05-21 05:22:12 EDT
Fix in version lvm2-2.02.46-1.el5.
Comment 8 Corey Marthaler 2009-07-07 15:14:27 EDT
I'm not exactly sure what the fix is supposed to be here since you can't vgrename an active VG, but I verified that you're able to rename one of the same named VGs using the uuid and that the /dev nodes match accordingly.

[root@grant-01 ~]# pvscan
  WARNING: Duplicate VG name VG: Existing abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG (created here) takes precedence over vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk
  PV /dev/sdc1   VG VG           lvm2 [38.92 GB / 38.82 GB free]
  PV /dev/sdb1   VG VG           lvm2 [38.92 GB / 38.82 GB free]

[root@grant-01 ~]# vgs -o +vg_uuid
  VG         #PV #LV #SN Attr   VSize  VFree  VG UUID                               
  VG           1   1   0 wz--n- 38.92G 38.82G vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk
  VG           1   1   0 wz--n- 38.92G 38.82G abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG

[root@grant-01 ~]# vgrename abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG VG2
  WARNING: Duplicate VG name VG: Existing abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG (created here) takes precedence over vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk
  WARNING: Duplicate VG name VG: abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG (created here) takes precedence over vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk
  WARNING: Duplicate VG name VG: Existing abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG (created here) takes precedence over vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk
  Volume group "VG" successfully renamed to "VG2"

[root@grant-01 ~]# vgchange -ay
  1 logical volume(s) in volume group "VG" now active
  1 logical volume(s) in volume group "VG2" now active
  2 logical volume(s) in volume group "VolGroup00" now active

/dev/VG:
total 0
lrwxrwxrwx 1 root root 17 Jul  7 14:10 LV -> /dev/mapper/VG-LV

/dev/VG2:
total 0
lrwxrwxrwx 1 root root 18 Jul  7 14:12 LV -> /dev/mapper/VG2-LV
Comment 9 Tom Lanyon 2009-07-09 20:05:27 EDT
Corey,

The truest test would be having the VG that you're not renaming active whilst you rename the other. In your example, VG (vkno3t-srzL-M1ov-853I-fEkm-Liav-QAEeSk) should be active with its /dev nodes available, then you should rename the other VG (abplYR-lrkr-9MmX-Wf18-1eRS-Z81f-jDdujG) and ensure the /dev/VG nodes of the active VG do not change.
Comment 11 errata-xmlrpc 2009-09-02 07:57:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1393.html

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