Hide Forgot
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)
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.
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.
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.
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
Note: I've filed bug #1301974 for adding -S|--select support for commands where it's still missing (e.g. lvcreate).
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
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