Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1584648

Summary: multipath -ll does not show any warning for invalid multipath device map passed as an argument
Product: Red Hat Enterprise Linux 8 Reporter: Milan P. Gandhi <mgandhi>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED WONTFIX QA Contact: Lin Li <lilin>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: agk, bmarzins, coughlan, heinzm, lilin, msnitzer, prajnoha, rdave, zkabelac
Target Milestone: rcKeywords: EasyFix, Patch
Target Release: 8.1Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-08 15:08:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed Patch v1 none

Description Milan P. Gandhi 2018-05-31 11:37:14 UTC 
Description of problem:
The "multipath -ll" command currently does not show any warning for invalid multipath device map name passed as an argument or if there are no multipath devices present on server.

e.g. In the following "multipath -ll" commands, I am using incorrect multipath device names, none of these devices or WWIDs exist on server, but "multipath -ll" does not show any message or error for such devices:

   # multipath -ll mpath999
   # multipath -ll test
   # multipath -ll test123
   # multipath -ll 123
   # multipath -ll 8737887918978931

Now flush all the existing multipath devices, and run multipath -ll, it would exit without any message:

   # multipath -F
   # multipath -ll 

We could update device-mapper-multipath to print a message informing the users about incorrect map name or if there are no multipath device maps found on the server.

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.9-119.el7

How reproducible:
Always

Steps to Reproduce:
<described above>

Actual results:
- multipath -ll does not show any warning for invalid multipath device maps passed as an argument

Expected results:
- Print a message informing the users about incorrect map name or if there are no multipath device maps found on the server.

Additional info:
Comment 2 Milan P. Gandhi 2018-05-31 11:51:17 UTC 
Created attachment 1446244 [details]
Proposed Patch v1

This patch updates device-mapper-multipath to display a message if there is no match found for the mpath device name/WWID passed with "multipath -ll <dev/wwid>" command or there are no multipathd devices present on server.
Comment 4 Milan P. Gandhi 2018-05-31 12:00:00 UTC 
With this patch applied we get following message in above scenarios:

[root@testhost1 ~]# multipath -ll mpath999
May 31 07:59:04 | No multipath device maps found
[root@testhost1 ~]# multipath -ll test
May 31 07:59:05 | No multipath device maps found
[root@testhost1 ~]# 
[root@testhost1 ~]# multipath -ll test123
May 31 07:59:08 | No multipath device maps found
[root@testhost1 ~]# multipath -ll 123
May 31 07:59:11 | No multipath device maps found
[root@testhost1 ~]# multipath -ll 8737887918978931
May 31 07:59:15 | No multipath device maps found
[root@testhost1 ~]# 
[root@testhost1 ~]# 
[root@testhost1 ~]# 
[root@testhost1 ~]# multipath -F
[root@testhost1 ~]# multipath -ll
May 31 07:59:20 | No multipath device maps found
[root@testhost1 ~]# 
[root@testhost1 ~]# 
[root@testhost1 ~]# multipath -v2
May 31 07:59:23 | No multipath device maps found
May 31 07:59:23 | mpatha: ignoring map
create: mpathb (36001405d0b9a050efa544b58fe8de66f) undef LIO-ORG ,file11          
size=500M features='0' hwhandler='0' wp=undef
`-+- policy='service-time 0' prio=1 status=undef
  `- 4:0:0:0 sdb 8:16 undef ready running
create: mpathc (36001405177ec9678c7441a7b327eeffe) undef LIO-ORG ,file12          
size=500M features='0' hwhandler='0' wp=undef
`-+- policy='service-time 0' prio=1 status=undef
  `- 4:0:0:1 sdc 8:32 undef ready running
create: mpathd (36001405a2f034e541704e6eafca2960e) undef LIO-ORG ,file13          
size=500M features='0' hwhandler='0' wp=undef
`-+- policy='service-time 0' prio=1 status=undef
  `- 4:0:0:2 sdd 8:48 undef ready running
create: mpathe (36001405a43d674083094b69a6a7f310b) undef LIO-ORG ,file14          
size=500M features='0' hwhandler='0' wp=undef
`-+- policy='service-time 0' prio=1 status=undef
  `- 4:0:0:3 sde 8:64 undef ready running
create: mpathf (3600140571c8a14d4d2a49c6b9e7ce41b) undef LIO-ORG ,file15          
size=500M features='0' hwhandler='0' wp=undef
`-+- policy='service-time 0' prio=1 status=undef
  `- 4:0:0:4 sdf 8:80 undef ready running
[root@testhost1 ~]# 
[root@testhost1 ~]# 
[root@testhost1 ~]# multipath -ll
mpathe (36001405a43d674083094b69a6a7f310b) dm-6 LIO-ORG ,file14          
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:3 sde 8:64 active ready running
mpathd (36001405a2f034e541704e6eafca2960e) dm-5 LIO-ORG ,file13          
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:2 sdd 8:48 active ready running
mpathc (36001405177ec9678c7441a7b327eeffe) dm-4 LIO-ORG ,file12          
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
  `- 4:0:0:1 sdc 8:32 active ready running
mpathb (36001405d0b9a050efa544b58fe8de66f) dm-2 LIO-ORG ,file11          
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
  `- 4:0:0:0 sdb 8:16 active ready running
mpathf (3600140571c8a14d4d2a49c6b9e7ce41b) dm-7 LIO-ORG ,file15          
size=500M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:4 sdf 8:80 active ready running
[root@testhost1 ~]#
Comment 5 Ben Marzinski 2018-07-11 16:29:46 UTC 
I'm not sure that this needs changing.  Right now, user scripts might rely on a blank return to indicate that a device isn't present, and the only way that you will not see any devices if you don't specify a device, is if there really are none. You may consider posting this patch to dm-devel.  If it is accepted upstream, I will of course pull it back into RHEL.
Comment 6 Milan P. Gandhi 2018-07-11 17:17:08 UTC 
(In reply to Ben Marzinski from comment #5)
> I'm not sure that this needs changing.  Right now, user scripts might rely
> on a blank return to indicate that a device isn't present, and the only way
> that you will not see any devices if you don't specify a device, is if there
> really are none. You may consider posting this patch to dm-devel.
> If it is accepted upstream, I will of course pull it back into RHEL.

Hello Ben, The if/else block used in this patch were first added through the patch https://www.redhat.com/archives/dm-devel/2016-July/msg00536.html which was applied in RHEL provided dm-multipath, but these changes are not in upstream dm-multipath version. So the attached patch does not apply to upstream multipath code.

Thanks,
Milan.
Comment 7 Ben Marzinski 2018-07-12 16:52:23 UTC 
(In reply to Milan P. Gandhi from comment #6)
> (In reply to Ben Marzinski from comment #5)
> > I'm not sure that this needs changing.  Right now, user scripts might rely
> > on a blank return to indicate that a device isn't present, and the only way
> > that you will not see any devices if you don't specify a device, is if there
> > really are none. You may consider posting this patch to dm-devel.
> > If it is accepted upstream, I will of course pull it back into RHEL.
> 
> Hello Ben, The if/else block used in this patch were first added through the
> patch https://www.redhat.com/archives/dm-devel/2016-July/msg00536.html which
> was applied in RHEL provided dm-multipath, but these changes are not in
> upstream dm-multipath version. So the attached patch does not apply to
> upstream multipath code.
> 
> Thanks,
> Milan.

That's fine. Like I said, I don't want to needlessly change the output in RHEL7. If you make a version for upstream that is accepted, I will put it in RHEL8, where nobody has any scripts written yet.
Comment 8 Milan P. Gandhi 2018-07-12 17:45:10 UTC 
(In reply to Ben Marzinski from comment #7)
> (In reply to Milan P. Gandhi from comment #6)
> > (In reply to Ben Marzinski from comment #5)
> > > I'm not sure that this needs changing.  Right now, user scripts might rely
> > > on a blank return to indicate that a device isn't present, and the only way
> > > that you will not see any devices if you don't specify a device, is if there
> > > really are none. You may consider posting this patch to dm-devel.
> > > If it is accepted upstream, I will of course pull it back into RHEL.
> > 
> > Hello Ben, The if/else block used in this patch were first added through the
> > patch https://www.redhat.com/archives/dm-devel/2016-July/msg00536.html which
> > was applied in RHEL provided dm-multipath, but these changes are not in
> > upstream dm-multipath version. So the attached patch does not apply to
> > upstream multipath code.
> > 
> > Thanks,
> > Milan.
> 
> That's fine. Like I said, I don't want to needlessly change the output in
> RHEL7. If you make a version for upstream that is accepted, I will put it in
> RHEL8, where nobody has any scripts written yet.

Thanks for your inputs Ben! let me rework on it.
Comment 9 Tom Coughlan 2019-05-29 18:10:13 UTC 
(In reply to Ben Marzinski from comment #7)

...

> That's fine. Like I said, I don't want to needlessly change the output in
> RHEL7. If you make a version for upstream that is accepted, I will put it in
> RHEL8, where nobody has any scripts written yet.

Just as a caution, I'd suggest that 8.1 is the last chance before "nobody has any scripts written yet" for RHEL 8. 

Even then, we are putting a priority on making upgrades easier (witness all the effort that has gone into Leapp). So we no longer have free reign to break anything we want on an major release update. We should consider each case. 

You guys know the risk/benefit for this change better than I do. Just saying...

Tom
Comment 10 Milan P. Gandhi 2019-05-31 07:11:20 UTC 
Hello,

(In reply to Tom Coughlan from comment #9)
> (In reply to Ben Marzinski from comment #7)
> 
> ...
> 
> > That's fine. Like I said, I don't want to needlessly change the output in
> > RHEL7. If you make a version for upstream that is accepted, I will put it in
> > RHEL8, where nobody has any scripts written yet.
> 
> Just as a caution, I'd suggest that 8.1 is the last chance before "nobody
> has any scripts written yet" for RHEL 8. 
> 
> Even then, we are putting a priority on making upgrades easier (witness all
> the effort that has gone into Leapp). So we no longer have free reign to
> break anything we want on an major release update. We should consider each
> case. 
> 
> You guys know the risk/benefit for this change better than I do. Just
> saying...
> 
> Tom

Thanks for looking into this!

This BZ and patch were primarily to improve the error reporting in dm-multipath instead of silently ignoring an invalid command argument passed to multipath -ll. But if there is a chance of this breaking any custom scripts, then I do not see it as a priority for inclusion. The reason for this improvement was to improve error reporting, if it could affect any custom scripts, then we could definitely consider avoiding this improvement.

Kind regards,

Milan.
Comment 12 Ben Marzinski 2020-10-08 15:08:56 UTC 
The possibility to break scripts outweighs the benefits of this change.