RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1516035 - misleading suggestion from `lvchange` when trying to activate a duplicated logical volume.
Summary: misleading suggestion from `lvchange` when trying to activate a duplicated lo...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-21 21:10 UTC by Federico Sun
Modified: 2021-09-03 12:39 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-15 07:31:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Federico Sun 2017-11-21 21:10:06 UTC 
Description of problem:

If a disk with a duplicated VG/LV is attached to a RHEL 7.4 server, and running `lvchange` trying to activate this duplicated LV, `lvchange` will suggest the usage of `--select|-S vg_uuid` as if specifying the UUID of the desired VG it will activate the LV:
 
 >Multiple VGs found with the same name: skipping vg_test suggest:`  
 >Use --select vg_uuid=<uuid> in place of the VG name. 

This is a misleading message since `lvchange` doesn't support `--select|-S`.


Version-Release number of selected component (if applicable):

Tested on:

rhel 7.4
kernel 3.10.0-693.el7.x86_64
lvm2-libs-2.02.171-8.el7.x86_64
lvm2-2.02.171-8.el7.x86_64


How reproducible:
always.

Steps to Reproduce:
1. install rhel7.4
2. create a VG named vg_test.
3. create a LV named lv_test1.
4. attach a new disk with same VG/LV name created on another server.
5. run `lvchange`.

Actual results:

two VGs with the same name but different UUID:
# vgs -o +vg_uuid
  VG      #PV #LV #SN Attr   VSize    VFree VG UUID
  vg_test   1   1   0 wz--n- 1020.00m    0  fHPQTa-ITQC-iRip-39Qe-Qqdc-rQrv-dPlccB
  vg_test   1   1   0 wz--n-   <2.00g    0  8teRbr-d6y6-OB34-klgG-PucW-dnu6-iOBfg6

same LV name on both VG:
# lvs
  LV       VG      Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_test1 vg_test -wi------- 1020.00m
  lv_test1 vg_test -wi-a-----   <2.00g


# lvchange -ay /dev/mapper/vg_test-lv_test1
  Multiple VGs found with the same name: skipping vg_test
  Use --select vg_uuid=<uuid> in place of the VG name.

The above message suggests that it will activate the LV if the uuid of the desired VG is specified using `--select`:

 # lvchange -ay /dev/mapper/vg_test-lv_test1 --select vg_uuid=fHPQTa-ITQC-iRip-39Qe-Qqdc-rQrv-dPlccB
  Multiple VGs found with the same name: skipping vg_test
  Use --select vg_uuid=<uuid> in place of the VG name.


The output from `lvchange` regarding the usage of `--select` is misleading.


Expected results:

`lvchange` should not suggest --select|-S since this does not work. Or output something useful like using `vgrename` first.
Comment 2 David Teigland 2018-04-03 16:36:12 UTC 
This is also discussed in bug 1378829.  Replacing VG name with --select vg_uuid=<uuid> requires that we create a new reserved symbol+word that the user would need to type in place of the VG name, e.g. a special VG name of "#UUID" could mean that the VG is specified by --select vg_uuid="123".

This is a somewhat confusing and inconsistent use of the --select option, because in this case vg_uuid is the only field that's allowed after --select, and it must match only one VG.  IOW, it's not the normal --select behavior at all.  --select is just being used as a vehicle for passing the uuid.

Say that two VGs have the name "foo".  The first has uuid 123-456-789 and the second has uuid abc-def-ghi.

lvchange -ay foo/test
Error: duplicate VG name foo, specify VG with --select vg_uuid.

lvchange -ay --select vg_uuid=123-456-789 #UUID/test

Or in the case of vgrename,

vgrename foo bar
Error: duplicate VG name foo, specify VG with --select vg_uuid.

vgrename --select vg_uuid=123-456-789 #UUID bar

This seems awkward to use, in addition to being inconsistent with normal --select behavior.  It strikes me that if the user has to type #UUID, why not just type the actual uuid there?, e.g. #123-456-789.  That would mean defining a new rule in which a VG name could be replaced with a VG uuid by typing "#" before it.  The examples above would then be:

lvchange -ay #123-456-789/test

vgrename #123-456-789 bar
Comment 5 RHEL Program Management 2021-02-15 07:31:24 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.