Bug 1019328 - When using lvmetad, lvm commands do not warn about duplicate VG names
When using lvmetad, lvm commands do not warn about duplicate VG names
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.6
All Linux
unspecified Severity low
: rc
: ---
Assigned To: David Teigland
cluster-qe@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-15 09:47 EDT by Peter Rajnoha
Modified: 2016-05-10 21:14 EDT (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.140-3.el6
Doc Type: Bug Fix
Doc Text:
Cause: Multiple Volume Groups with the same name were not handled consistently. Consequence: Warnings about the duplicate VGs were not printed when lvmetad was used. The VG name specified by a command would not always translate to the intended VG. Fix: LVM always checks if the VG name specified by a command refers to more than one actual VG. Result: Copied from lvm(8): When VGs with the same name exist, commands operating on all VGs will include all of the VGs with the same name. If the ambiguous VG name is specified on the command line, the command will produce an error. The error states that multiple VGs exist with the specified name. To process one of the VGs specifically, the --select option should be used with the UUID of the intended VG: '--select vg_uuid=<uuid>'.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 21:14:55 EDT
Type: Bug
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 Peter Rajnoha 2013-10-15 09:47:25 EDT
When lvmetad is used and there appear to be two VGs with the same name in the system, the lvm commands do not show a warning message about this state. This  comes handy for users so they can see that LVM command processing choses one VG.

For example:

without lvmetad:

[2] raw/~ # vgs -o+vg_uuid
  WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  WARNING: Duplicate VG name vg: Existing qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP (created here) takes precedence over Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa
  WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  WARNING: Duplicate VG name vg: Existing qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP (created here) takes precedence over Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa
  VG         #PV #LV #SN Attr   VSize   VFree   VG UUID                               
  vg           1   1   0 wz--n- 124.00m 120.00m qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  vg           1   1   0 wz--n- 124.00m 120.00m Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa


[2] raw/~ # lvs -o+vg_uuid
  WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  WARNING: Duplicate VG name vg: Existing qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP (created here) takes precedence over Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa
  WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  WARNING: Duplicate VG name vg: Existing qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP (created here) takes precedence over Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa
  LV    VG         Attr       LSize  Pool Origin Data%  Move Log Cpy%Sync Convert VG UUID                               
  lvol0 vg         -wi-------  4.00m                                              qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP


with lvmetad:

[2] raw/~ # vgs -o+vg_uuid 
  VG         #PV #LV #SN Attr   VSize   VFree   VG UUID                               
  vg           1   1   0 wz--n- 124.00m 120.00m qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP
  vg           1   1   0 wz--n- 124.00m 120.00m Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa
[2] raw/~ # lvs -o+lv_uuid
  LV    VG         Attr       LSize  Pool Origin Data%  Move Log Cpy%Sync Convert LV UUID                               
  root  fedora_raw -wi-ao---- 17.54g                                              OhVTmn-Dbfi-Y0Wx-jiSN-gYVH-bxJK-B4K8c3
  swap  fedora_raw -wi-ao----  1.97g                                              B9ZtZr-feUF-P8zW-tdIS-W61t-Scu5-o0bivZ
  lvol0 vg         -wi-------  4.00m                                              5gdk73-NHX2-bfoX-D528-CbFR-VoZ8-fCSZIB


(there is lvol0 in both VGs, but only one is shown as LVM takes only one VG in lvs output... so it's good for the user to know that there are duplicate VG names and the lvm command processing is affected)
Comment 1 Peter Rajnoha 2015-10-14 04:16:50 EDT
With recent code (I'm testing 2.02.133, but it may have been even sooner), we can display duplicate LVs with lvmetad too:

$ lvs -o lv_name,vg_name,vg_uuid -S 'vg_name=vg'
  LV     VG   VG UUID                               
  first  vg   CcjjbI-wdWn-1BcZ-vNVV-oG1f-hSFl-xuvJRQ
  first  vg   UWMB7p-o5H3-LgkU-D8nG-86Tw-efmh-ZyuDs3
  second vg   UWMB7p-o5H3-LgkU-D8nG-86Tw-efmh-ZyuDs3

Together with the -S|--select support, we can also address individual VGs/LVs based on their UUIDs easily.

The only thing that remains is to add some warning possibly about these duplicates if we really want to make it equal to the way it works without lvmetad - maybe this is not necessary anymore if we can display duplicates.

I'll take this for the backport/rebase of the existing patch to make this working.

There's also some work done by David Teigland to deal with duplicates better so let's see how much of that will get into the release.

This is not such a huge issue as lvmetad is not used by default in RHEL6 anyway.
Comment 2 Peter Rajnoha 2016-01-22 09:46:24 EST
We've done rebase in RHEL-6.8 so we display even duplicate VG names with lvmetad now.

David, I'm handing this one over to you - I'm not sure if we plan to add a warning here in addition or not even if lvmetad is used. I mean something like the "WARNING: Duplicate VG name vg: Existing Tdq09g-RJiG-z3Sa-QbCE-0Oih-D0fR-R6oiZa (created here) takes precedence over qDi0t5-L5xt-r0Cz-I7v2-gn3U-LehX-j9bQtP" that's there when lvmetad is not used. You're the expert for duplicates now.
Comment 3 David Teigland 2016-01-22 10:00:26 EST
We don't pick one of the duplicates any longer, but report an error, suggesting that -S be used to select one by UUID.  Here's the lvm(8) section about it:

UNIQUE NAMES
       VG names should be unique.  vgcreate will produce an error if the spec‐
       ified VG name matches an existing VG name.  However,  there  are  cases
       where  different  VGs  with the same name can appear to LVM, e.g. after
       moving disks or changing filters.

       When VGs with the same name exist, commands operating on all  VGs  will
       include all of the VGs with the same name.  If the ambiguous VG name is
       specified on the command line, the command will produce an error.   The
       error  states  that  multiple  VGs  exist  with the specified name.  To
       process one of the VGs specifically, the --select option should be used
       with the UUID of the intended VG: '--select vg_uuid=<uuid>'.

       An  exception is if all but one of the VGs with the shared name is for‐
       eign (see lvmsystemid(7).)  In this case, the one VG that is  not  for‐
       eign is assumed to be the intended VG and is processed.
Comment 4 Peter Rajnoha 2016-01-26 07:57:29 EST
OK, let's use this bz then to track change in behaviour here. The behaviour is now consistent in both lvmetad and non-lvmetad case. The vgs displays both VGs with the same name (but with different UUIDs). When trying to process such VGs, there's the message suggesting -S|--select.

[root@rhel6-a ~]# vgs -o+uuid
  VG       #PV #LV #SN Attr   VSize VFree VG UUID
  vg         1   1   0 wz--n- 4.00g 3.99g eHZp2F-7Qdk-p6br-Z8cI-iEwi-LWIl-ScaCr4
  vg         1   1   0 wz--n- 4.00g 3.99g GhDzAe-LAav-yhCu-WF4e-G1zn-FtrQ-yh15OP

[root@rhel6-a ~]# lvs vg
  Multiple VGs found with the same name: skipping vg
  Use the VG UUID with --select vg_uuid=<uuid>

[root@rhel6-a ~]# lvs -S vg_uuid=eHZp2F-7Qdk-p6br-Z8cI-iEwi-LWIl-ScaCr4
  LV   VG   Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  one  vg   -wi------- 4.00m
Comment 6 Peter Rajnoha 2016-01-26 09:52:22 EST
Note: I've filed bug #1301974 for adding -S|--select support for commands where it's still missing (e.g. lvcreate).
Comment 8 Roman Bednář 2016-02-26 06:02:29 EST
Verified. LVM commands now warn about duplicate VG names when using lvmetad.

============================================================================
With lvmetad:

# ps -ef | grep lvmetad | grep -v grep
root     27997     1  0 11:39 ?        00:00:00 lvmetad

# lvs vg
  Multiple VGs found with the same name: skipping vg
  Use the VG UUID with --select vg_uuid=<uuid>

# vgs -o +vg_uuid
  VG         #PV #LV #SN Attr   VSize  VFree  VG UUID                               
  vg           1   0   0 wz--n- 10.00g 10.00g Huzpgx-Xl67-1tcP-uPCe-WW7B-PHYS-ZXY3qz
  vg           1   0   0 wz--n- 10.00g 10.00g 1KPonI-xn0n-kYGP-LHS1-F4mB-u6bu-8ZX1rh
  vg_virt269   1   2   0 wz--n-  7.71g     0  4bllWI-XP9x-hph7-QVJW-Qarl-r597-e5ybrH

# lvs --select vg_uuid=Huzpgx-Xl67-1tcP-uPCe-WW7B-PHYS-ZXY3qz

# echo $?
0


Without lvmetad:

# ps -ef | grep lvmetad | grep -v grep

# lvs vg
  Multiple VGs found with the same name: skipping vg
  Use the VG UUID with --select vg_uuid=<uuid>

# vgs -o +vg_uuid
  VG         #PV #LV #SN Attr   VSize  VFree  VG UUID                               
  vg           1   0   0 wz--n- 10.00g 10.00g Huzpgx-Xl67-1tcP-uPCe-WW7B-PHYS-ZXY3qz
  vg           1   0   0 wz--n- 10.00g 10.00g 1KPonI-xn0n-kYGP-LHS1-F4mB-u6bu-8ZX1rh
  vg_virt270   1   2   0 wz--n-  7.71g     0  ITwaiF-TtP6-TpCn-CeB5-Vfxr-cb1j-pMSYrZ

# lvs --select vg_uuid=Huzpgx-Xl67-1tcP-uPCe-WW7B-PHYS-ZXY3qz

# echo $?
0
============================================================================


Tested on:
2.6.32-616.el6.x86_64

lvm2-2.02.141-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
lvm2-libs-2.02.141-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
lvm2-cluster-2.02.141-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
udev-147-2.71.el6    BUILT: Wed Feb 10 14:07:17 CET 2016
device-mapper-1.02.115-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
device-mapper-libs-1.02.115-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
device-mapper-event-1.02.115-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
device-mapper-event-libs-1.02.115-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
device-mapper-persistent-data-0.6.2-0.1.rc1.el6    BUILT: Wed Feb 10 16:52:15 CET 2016
cmirror-2.02.141-2.el6    BUILT: Wed Feb 10 14:49:03 CET 2016
Comment 10 errata-xmlrpc 2016-05-10 21:14:55 EDT
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.

https://rhn.redhat.com/errata/RHBA-2016-0964.html

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