Well  the consensus is to change the serial number of the replaced drive,
which I did.  However, since I had already rebooted the library owning
server, to discover the new serial number, I rebooted it again and it
seems to access the replaced drive, just fine.

However (isn't there always a "however" or "but"), none of the library
client servers can mount a tape on this drive!.  They all fail with a
"Unable to open drive" error.  I have tried updating the paths to this
drive, on the library manager server, telling it to autodetect, which it
does just fine.

Even tried deleting and redefining all the paths to the library client
servers.............nada.........zip...........all library client servers
still fail trying to get to this drive.

More thoughts on how to resolve this?  Do I need to bounce each of the TSM
servers (not the whole machine......just the server)?



From:
"Costa, Justino" <justino.costa AT LOGICA DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
07/09/2009 07:38 PM
Subject:
Re: [ADSM-L] Replacing tape drives (or "there has to be a better way")
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



There must be a reason why sandiscovery defaults to off on non-windows
platforms.

Anyway, I think you're right and that *should* be the correct behavior
of SANDISCOVERY=ON.

However, I prefer to stick with persistent binding and tight control on
SAN changes. This way, I can at least avoid spending time on false
positives like this one described here
http://www-01.ibm.com/support/docview.wss?uid=swg1IC59807, even for the
latest 5.5.x and 6.1.x versions.

jmC


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: quinta-feira, 9 de Julho de 2009 18:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a
better way")

I've been following this thread and have a question about AUTODETECT:

I've seen this message:
ANR8955I Drive drive name in library library name with serial number
serial number is updated with the newly discovered serial number serial
number .

as a result of having the drives defined with AUTODETECT=YES and also
SANDISCOVERY ON with the appropriate HBA library installed.

Can anyone expand on why this does or doesn't always work when changing
a drive serial #?  Or does it only work when the device number changes?

W

> >Subject
> >[ADSM-L] Replacing tape drives (or "there has to be a better way")
> >
> >
> >
> >
> >
> >
> >I need thoughts/suggestions/help on how to deal with SAN attached
> >tape drive replacements when a library is shared amongst 5-servers.
> >
> >We just has a drive replaced, therefore giving us a new serial number

> >(3494ATL - TS1130).  All servers that use these drives/libraries are
> >RedHat Linux and use very current lin_tape drivers.
> >
> >Currently, the method we use is to bounce each server so the system
> >rescans the SAN and gets the new serial number.
> >
> >In the past, just stopping the TSM server and then restarting the
> >lin_tape driver would often be enough. Now with the latest lin_tape
> >drivers, I don't see the lin_taped daemon running any more.
> >
> >Yes, I have tried updating the paths on the library manager server
> >and telling it to autodetect but that didn't help.
> >
> >There has to be a better way!  If you have a similar configuration,
> >how
>
> >do you handle this scenario?
> >