Re: [ADSM-L] Replacing tape drives (or "there has to be a better way")

So, are you saying that I always need to delete and redefine all
connections to the drive being replaced?

I have just tried this and will see if it works.



From:
Bob Levad <blevad AT WINNEBAGOIND DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
07/10/2009 04:56 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>



Zoltan,

In playing with various DR scenarios and working through occasional
hardware
problems, I found it difficult to get all the right commands entered
correctly and in the correct sequence and with the library/drives in the
correct states so I created scripts that delete and re-define everything.

If things are healthy as far as the hardware is concerned, they work
flawlessly and everything gets redefined and if there is a problem,
looking
for the first failure usually tells me where the problem lies.

Bob.

/* define ltolib2 */
del_path:
delete path tsmsrvb mt0.0.0.1 srctype=server desttype=drive
library=ltolib2
etc...

del_drive:
delete drive ltolib2 mt0.0.0.1
Etc...

drop_library_path:
delete path tsmsrvb ltolib2 srctype=server desttype=library

drop_library:
delete library ltolib2

create_library:
define library ltolib2 libtype=scsi

create_library_path:
define path tsmsrvb ltolib2 srctype=server desttype=library
device=lb0.1.0.1
online=yes

def_drive:
define drive ltolib2 mt0.0.0.1 element=autodetect serial=autodetect
online=yes
Etc...

def_path:
define path tsmsrvb mt0.0.0.1 srctype=server desttype=drive
library=ltolib2
device=mt0.0.0.1 online=yes
Etc...

Checkin_scratch:
checkin libv ltolib2 search=yes checklabel=barcode
status=scratchCheckin_scratch:

Checkin_private:
checkin libv ltolib2 search=yes checklabel=barcode status=private

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, July 10, 2009 1:12 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a better
way")

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

This electronic transmission and any documents accompanying this
electronic transmission contain confidential information belonging to the
sender.  This information may be legally privileged.  The information is
intended only for the use of the individual or entity named above.  If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or the taking of any action in reliance
on or regarding the contents of this electronically transmitted
information is strictly prohibited.