Re: qla2xxx/2300 and persistent binding

[Tom Sightler <ttsig tuxyturvy com>]

On Wed, 2006-04-19 at 21:26 +0300, Jussi Silvennoinen wrote:
> Hello,
> 
> how does one do persistent binding from qla2xxx/2300 on RHEL4 
> (2.6.9-34.ELsmp.i686)?

I believe the official stance is to use device-mapper to map the WWID's
of the SAN devices to specific device names.  This actually works great
and then it doesn't matter what order devices on the SAN are discovered
in and they can have nice names that you give them.

Well, actually, this isn't completely true.  This concept works great
for disks, but I've had difficulty with SAN attached tape devices,
mainly because our backup application still access devices via the x,x,x
SCSI format rather than the device name and device mapper cannot help
with that.

Basically, if you just need device name consistency and don't care about
actual SCSI device order, device-mapper is totally sufficient and, in my
opinion, far easier and nicer than the custom method implemented in the
"OEM" version of the Qlogic driver.

> This sort of mutilation which prevents hardware configuration utilities 
> from being used is most annoying and frankly ADOLESCENT behavior.

As far as I know the driver included with Redhat is pretty much the same
one that is in the stock kernel.  I'm not sure it's fair to call it
multilated as I believe Qlogic themselves submitted it for inclusion in
this state.

It is true that the kernel people would not accept the driver as it
exist on the Qlogic web site because it includes non-standard methods
for persistent binding, path rediscovery, and hooks for proprietary
tools that the Qlogic tools.

>From a support perspective this is understandable.  The standard
device-mapper tools work with all fiber channel cards in the same way
whereas every vendor was implementing their own method for doing
persistent bindings.  The Linux kernel maintainers simply wouldn't allow
that level of inconsistency to be integrated into the kernel. 

You can be upset with Redhat for not shipping the OEM version of the
Qlogic driver but rather the kernel version.  I have been a critic of
the decision probably from day one, mainly because it is STILL the only
way to get working "Boot-from-SAN + multipath" easily.

That being said I can at least understand the decision.  The
device-mapper method is the Linux way to handle this issue and it's much
easier to document and support a single method that works with all
adapters rather than trying to document and support the various methods
implemented in the multiple fiber channel drivers now included in RHEL4.

It is supported when you use the standard Linux method for device
mapping.

Later,
Tom