Re: qla2xxx/2300 and persistent binding

[Jussi Silvennoinen <jussi_nahant silvennoinen net>]

> > 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.

Oh, have to look into that.

> > 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.

Well I suppose their alternative was to have no support for their gear in 
nahant.

> 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.

Granted my frustration comes comes from wasting time trying to get stuff 
to work which has been deliberately disabled without any clues left behind 
to indicate this. Or then I just didn't see it.

As usual, nahant-list archives infused me with a clue so I can move on 
to either udev suggested by Arjan or dm. I do need to do multipathing at 
the same time so I think dm is the way to go for me. For me moment, I'm 
working with active/passive CX700's but we've already ordered a nice 
little DMX-3. Needed to reserve 11 meters of rack space for that cute 
thing...

-- 

  Jussi