Bug 979121

Another really serious problem seems to be, that already existing symlinks like /dev/disk/by-label/root are OVERWRITTEN with the newer devices/filesystem...

LVM is not designed to support systems with two VGs that have the same name.  One of them should be renamed using vgrename and specifying its uuid.

Given that two such VGs are found, the tools have two choices.  Either they could refuse to do anything until the situation is resolved with a vgrename (or filters), or they could select one of the two VGs according some predefined rules.

They do the second.  Some people are advocating changing to the first because of the confusion it causes in situations like yours.

The rules for choosing between the two VGs have no access to information saying whether or not either of the VGs have active LVs and so this plays no part in the decision.  It would not be easy or cheap to add this and it would in turn add a different level of unpredictability to the decision.

We'll give this some thought.

Well first of all, support for different VGs with the same name should be improved, as this situation can very easily arise nowadays. Just consider you're working with VMs and directly mount their virtual disk in the host (which is quite common)... all of them usually have similar (a.k.a. the same names) like vg01 or vg_system or something like that.

It's even not that unlikely that you stumble across VGs/PVs/LVs with the same UUIDs, given that in VMs you simply often clone from a base image,... again,... support should be improved here... not sure if it's time to open a ticket for that.


I'm fine with the tools doing the second,.. but that means, IMHO, that they should generally _ALWAYS_ use those VG/LV/PVs, that were active (not known) chronologically first.
Because these are already used... and when you suddenly switch now, things may break.

I had the impression that this was more or less the case (at least my system continued to work)... but your text seems to imply that other rules control this?

Anyway... at least in case of stuff like /dev/disk/by-label/ it's definitely not working that the chronologically first one is used... but that's general problem not limited to LVM... is that udev's business.. cause I think one should become active there, too.


Nevertheless... this bug report was primarily about the warning message which seems to have mixed the two UUIDs?!

The messages are accurate: they are nothing do with which VG has active LVs.

They tell you which VG would be processed if you used that particular VG name on the command line.  (When you give no VGs on the command line and the command expects to process a list of VGs, it generates that list internally then processes each item on it.)

But we will reconsider this area like you say: no need to open an additional bugzilla.

A now I understood :)

btw:
One idea to "handle" any collisions could be to use a special namespaces, which would have also been my solution for the genereal /dev/disk/by-[label|uuid] problem.

Like having:
/dev/vg-collisions/
respectively
/dev/disk/by-label/collisions/

and the content's would get a unique ID prefixed (which the system guarantees to be different) so one could have:
/dev/vg-collisions/1_vg_system/
/dev/vg-collisions/2_vg_system/
...
or
/dev/disk/by-label/collisions/1_root
/dev/disk/by-label/collisions/2_root
...

And a similar thing for the links in /dev/mapper/


What happens btw., when I create a VG called "null".. it can't set up /dev/null/ usually ;-)


Well it's up to you whether a new bug is used, I think so that there are three issues:
1) clarification of which duplicate the LVM tools use
I mean I'm not stupid but from that warning message I would not have realised that "what the LVM tools will use" is meant.

2) deciding whether the current choice of which duplicate is used (the first, the last, etc.) is best... or whether, as you said it's better to stop working at all until a rename has happened.

3) How one can handle collision of PV/LV/VG names at the /dev/ level.


Cheers,
Chris.

The duplicate PV warning messages mentioned were recently fixed, improved, expanded, and made functional with lvmetad.  There is more work in progress in this area.  These changes might not make it back into RHEL6 unless lvm is rebased there.  They'll appear in the next RHEL7 update, so moving the bz there.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Duplicate PV/VG warning messages have been improved. 
Also lvmetad cache data are ignored in such situations to prevent other problems.

However, when trying to resolve the vg name duplicate I found that vgrename does not support --select|-S option, although it should.
vgrename can still be used by using uuid directly, but the select option is supposed to work and user gets a hint to use it when vgrename is used in a wrong way. See example below.

# pvs 
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already found on /dev/sda.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda because device was seen first.
  PV         VG            Fmt  Attr PSize   PFree  
  /dev/sda   vg_clone      lvm2 a--   40.00g  40.00g
  /dev/sdk   vg_clone      lvm2 a--  972.00m 972.00m
  ...

# systemctl is-active lvm2-lvmetad.service
active

======================================================

Here we try to resolve the conflict:

(Wrong arguments here on purpose, we get a hint to use select option)
# vgrename vg_clone vg_new
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already found on /dev/sda.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda because device was seen first.
  Multiple VGs found with the same name: skipping vg_clone
  Use --select vg_uuid=<uuid> in place of the VG name.

# vgs -o +vg_uuid
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already found on /dev/sda.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda because device was seen first.
  VG            #PV #LV #SN Attr   VSize   VFree   VG UUID                               
  rhel_virt-283   1   2   0 wz--n-   7.79g  40.00m TrH3Io-2XLs-omfO-J1K9-ZRoq-T2QG-TzwmuZ
  vg_clone        1   0   0 wz--n- 972.00m 972.00m 6Hwtsh-tkgf-oV2G-CqZs-0Kgr-QBgj-tL3EoN
  vg_clone        1   0   0 wz--n-  40.00g  40.00g xjv8tG-XDO0-PGZZ-4wGK-whMq-KOa3-5PUtMv

# vgrename --select vg_uuid=6Hwtsh-tkgf-oV2G-CqZs-0Kgr-QBgj-tL3EoN vg_clone vg_renamed
vgrename: unrecognized option '--select'
  Error during parsing of command line.



3.10.0-505.el7.x86_64

lvm2-2.02.165-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
lvm2-libs-2.02.165-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
lvm2-cluster-2.02.165-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
device-mapper-1.02.134-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
device-mapper-libs-1.02.134-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
device-mapper-event-1.02.134-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
device-mapper-event-libs-1.02.134-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016
device-mapper-persistent-data-0.6.3-1.el7    BUILT: Fri Jul 22 12:29:13 CEST 2016
cmirror-2.02.165-2.el7    BUILT: Wed Sep 14 16:01:43 CEST 2016

(In reply to Roman Bednář from comment #15)
> Here we try to resolve the conflict:
> 
> (Wrong arguments here on purpose, we get a hint to use select option)
> # vgrename vg_clone vg_new
>   WARNING: Not using lvmetad because duplicate PVs were found.
>   WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
>   WARNING: After duplicates are resolved, run "pvscan --cache" to enable
> lvmetad.
>   WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already
> found on /dev/sda.
>   WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda
> because device was seen first.
>   Multiple VGs found with the same name: skipping vg_clone
>   Use --select vg_uuid=<uuid> in place of the VG name.
> 
...
> # vgrename --select vg_uuid=6Hwtsh-tkgf-oV2G-CqZs-0Kgr-QBgj-tL3EoN vg_clone
> vg_renamed
> vgrename: unrecognized option '--select'
>   Error during parsing of command line.

The vgrename uses process_each_vg so it uses common code which also includes support for "-S|--select". The only issue here is that vgrename doesn't have that argument registered with the vgrenamen command (which is easy to add). However, in this case, we need to be sure that the select always selects one VG, not more (...and the command should fail if the result of selection gives us more items - I'm not sure now if we have this check or not within the process_each_* code if used together with -S|--select, but if yes, it should be easy to switch vgrenamen into using -S now.)

Separate BZ open to track the "vgrename -S|--select": bug #1378829.

Marking verified with latest rpms.

3.10.0-505.el7.x86_64

lvm2-2.02.166-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
lvm2-libs-2.02.166-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
lvm2-cluster-2.02.166-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
device-mapper-1.02.135-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
device-mapper-libs-1.02.135-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
device-mapper-event-1.02.135-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
device-mapper-event-libs-1.02.135-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 2016
device-mapper-persistent-data-0.6.3-1.el7    BUILT: Fri Jul 22 12:29:13 CEST 2016
cmirror-2.02.166-1.el7    BUILT: Wed Sep 28 09:26:52 CEST 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-1445.html