ADSM-L

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

2008-04-21 15:30:33
Subject: Re: [ADSM-L] Proper way to handle LTO2 drive replacement
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 21 Apr 2008 15:29:00 -0400
Thanks for all your help.  We don't seem to be running the API
module/driver, qioctlmod, which is probably key.

We do have the other drivers (sans the x64) running:

[root@galaxy lib64]# lsmod | grep -i qla
qla2400               200960  0
qla2xxx               333504  10 qla2400
qla2xxx_conf          303240  1
scsi_mod              144529  7
lin_tape,libata,sg,st,qla2xxx,megaraid_sas,sd_mod




Michael Green <mishagreen AT GMAIL DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/21/2008 01:56 PM
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






Most likely you are not missing the driver because you had had a
working configuration before, right?
Check out driver is loaded by issuing
lsmod | grep -i qla
if you have both
qla2300 (in case of qla23xx family hba)
qla2xxx
 chances are you have Linux kernel stock drivers.
If you also have in addition qla2xxx_conf you probably have the Qlogic
driver installed (the one from Qlogic website)
To get the sandiscovery working you need the API library which comes
along in the Qlogic driver package.
The READMe in Qlogic driver explains the procedure for both Driver and
the API lib installation fairly well.


HTH.

On Mon, Apr 21, 2008 at 8:34 PM, Michael Green <mishagreen AT gmail DOT com>
wrote:
> If the the second file is physically present on your system, just try
>  to add it manually and reboot.
>  If it is not, double check your qla installation. It must include both
>  the driver and the API lib.
>  I don't know your exact hardware configuration, but checkout relevant
>  Linux driver/API lib on Qlogic Downloads/OEM Model/IBM links
>  <http://support.qlogic.com/support/oem_ibm.asp>
>
>
>
>  On Mon, Apr 21, 2008 at 8:12 PM, Zoltan Forray/AC/VCU <zforray AT vcu DOT 
> edu>
wrote:
>  > Yes, it is x64 and no I do not have the second line.
>  >
>  >  So, what am I missing in the configuration process?  How do I tell
it to
>  >  load that module?  Are both needed ?
>  >
>  >
>  >
>  >  Michael Green <mishagreen AT GMAIL DOT COM>
>  >
>  > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>  >  04/21/2008 12:28 PM
>  >
>  >
>  > 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
>  >
>  >
>  >
>  >
>  >
>  >
>  >  Is your Linux x64 one?
>  >
>  >  Mine is and my hba.conf
>  >  [root@tristan ~]# cat /etc/hba.conf
>  >  qla2xxx     /usr/lib/libqlsdm.so
>  >  qla2xxx64  /usr/lib64/libqlsdm.so
>  >
>  >
>  >
>  >
>  >
>  >  On Mon, Apr 21, 2008 at 5:07 PM, Zoltan Forray/AC/VCU
<zforray AT vcu DOT edu>
>  >  wrote:
>  >  > 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)
>  >  >  >
>  >  >
>  >
>  >
>  >
>  >  --
>  >  Warm regards,
>  >  Michael Green
>  >
>
>
>
>  --
>  Warm regards,
>  Michael Green
>



--
Warm regards,
Michael Green