Bug 155546

Summary:	multipath-tools could benefit from more cmdline options
Product:	[Fedora] Fedora	Reporter:	Lars Marowsky-Bree <lmb>
Component:	device-mapper-multipath	Assignee:	Ben Marzinski <bmarzins>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	agk, christophe.varoqui, dmo, dwysocha, lmb, mbroz, poelstra, terescik_john, tranlan
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-02-14 21:42:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lars Marowsky-Bree 2005-04-21 11:25:17 UTC

As an enhancement suggestion for the next versions, I think that multipath-tools
could benefit from more manageability options; "-l" for displaying what is
happening is already good, but I think commandline interfaces to the other
multipath features would be good:

multipath --switch-group <multipath device identifier> <group identifier>
for example would switch the multipath device identified (either by it's name or
by one of it's components, like -l already accepts) to the group identified
(either by number or by one of it's components).

--(enable|disable)-group, --(fail|reinstate)-path would work in similar manners,
and --(queue|fail)_if_no_path would send the appropriate message.

Also an option to affect all groups at once (to enable them all again, for
example) for all or a selected device would be helpful.

multipath(d) already uses some of these messages internally, and it'd be good
for useability of they were exported, so that users don't have to construct the
dmsetup message command themselves.

Comment 1 Christophe Varoqui 2005-04-22 22:25:19 UTC

I don't really follow you on this : the current design forces the admin to setup
a config file suited to its env, then forget about it. Why would it want to care
about direct map manipulations, that multipathd will reverse at the first occasion.

As an example, force a fail_path on a valid path and you'll see it instantly
reinstateed. Force a switch_pg to a pg with a lower weight, and you'll see a
switch back to the highest prio pg.

I think this is sane.

Not to say an admin is not allowed to reap off the daemon to mess with maps, but
it this case I don't see why multipath-tools would have to give assistance ...
dmsetup is the right tool for that.

Comment 2 Lars Marowsky-Bree 2005-04-25 12:11:34 UTC

I disagree partially. 

Ok, failing the paths might not be the best example, but switching PGs (or
temporarily disabling one) does have it's merits.

Use case 1: The admin wants to temporarily move load from one overloaded switch
to another one. Of course, if that one fails, it should switchback to the other,
because slow service is better than none - so disabling the switch ports isn't a
good idea.

Use case 2: Consider 2 nodes; one of them loses access to parts of the fabric
and switches over. The other node constantly switches back. The ping-pong effect
is going to cause problems. Of course, the real fix is to fix the first node,
but the immediate workaround is to tell the second node to switch PGs.

The option to set/disable the queue path option for testing is also useful.

Sure, these are non-persistent and will be reset the next time the daemon is
restarted and reloads its configuration file; that's just fine; having a
volatile and non-volatile configuration is pretty standard.

To summarize my position: I agree that the goal is to have the admin setup the
configfile once, or even better, not require any configuration at all but just
do the right thing out of the box. This is a great goal for user-friendliness
and indeed very sane.

However, almost every piece of logic should have an easily accessible admin
override to cater to situations where the automated logic doesn't do the right
thing. (And there's a substantial chance these will be high stress situations
where things don't work as planned; exactly NOT the situation in which you'd
want the admin to start learning dmsetup manually, or having support staff
dictate the commands over the phone...)

I think this too is part of being user-friendly.

Comment 3 John Poelstra 2008-07-08 03:41:17 UTC

Hi,

I'm assuming several versions have been released since the "next version"
mentioned in comment #1.  Is this bug still relevant?

Thanks,
John

Comment 4 Alasdair Kergon 2011-02-11 20:29:44 UTC

Ben, how much of this, if any, do you think we still need?

Comment 5 Ben Marzinski 2011-02-14 21:42:36 UTC

We already have equivalents to all the commands initially mentioned.