Thanks for the suggestions.

I checked and SANDISCOVERY ON is set for the server that owns the drives.

However, when I try to set the path to AUTODETECT YES, I get the error:

ANR1792W  HBAAPI vendor library failed to load or is missing.

Explanation: The HBAAPI vendor library failed to load or is missing. This
HBAAPI library is provided by the Host Bus Adapter (HBA) vendor. It is
required for Tivoli Storage Manager server to discover devices on the SAN.

Further info on IBM's site says to check the /etc/hba/conf file to see
what library/location it points to.  My system confirms the library is
where it is supposed to be.....

[root@galaxy lib]# cat /etc/hba.conf
qla2xxx          /usr/lib/libqlsdm.so
[root@galaxy lib]# ls -ltr /usr/lib/libqlsdm.so
-r-x------  1 root root 511892 Jun 26  2007 /usr/lib/libqlsdm.so

So, can someone with experience with SANs/qlogic and Linux give me a clue
as to why I get this error message, when all seems to be as it is supposed
to be?



Wanda Prather <wprather AT JASI DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/21/2008 09:49 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Proper way to handle LTO2 drive replacement






Zoltan,

I haven't tried this on Linux.

But for a Windows or AIX TSM server you can add SANDISCOVERY ON in the
dsmserv.opt file.  You should also have the drives defined with AUTODETECT
YES.
(Check to see if it is working by entering:  Q SAN)

Then TSM SHOULD update the path/serial # automatically when there is a
change.

(FWIW, this isn't an LTO2 issue; can occur with any type drive.)



On Mon, Apr 21, 2008 at 9:19 AM, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu>
wrote:

> I seem to always have issues when replacing LTO2 drives (3583-L72
library)
> that fail and would like to know what folks do out there, to handle it
> better than we do.
>
> I currently have two dead/failing LTO2 drives.
>
> When I pull one out and replace it with a spare, TSM wont use it and TSM
> complains about the serial # and not being able to find the correct
drive.
>
> 4/19/2008 9:01:58 AM ANR8963E Unable to find path to match the serial
> number defined for drive LTO-DRIVE5 in library IBM3583-2 .
>
> In the past, I have had to shut down all TSM servers and bounce the
> lin_taped/IBMtaped process and/or bounce the server to rediscover the
SAN
> attached devices and reassign the new serial numbered drive and remove
the
> old one.   If there is a SAN path order shuffle and any drive gets a new
> /dev/IBMtapenn, I have to reconfigure the paths for every drive effected
> by the "musical chairs" reorg.
>
> Your suggestions on how to better handle this (besides just chucking
these
> !@#$%^&*() LTO2 drives, which I hope to do within the next 1-2 years)!
>
> All servers are Linux  RH4. The library owning servers are 5.5 lin_tape
> drivers at at the latest level for the kernel (2.6.9.55 kernel - 1.10
> driver)
>