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

Zoltan,

You don't need to delete and redefine all connections to the drive being
replaced. All you need to do before a drive change is to make sure that
the drive is not used and that you take the path to the drive offline.
Once IBM replaces the drive (using the same S/N as the replaced drive),
you should take the path to the drive back online - that's all I ever
needed to do during our drive replacements - btw our drives are defined
with the element=autodetect parameter.

I hope all works out.

BERTAUT TCHUISE
Storage Support Administrator
Legg Mason Technology Services
*410-580-7032
BTchuise AT leggmason DOT com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Monday, July 13, 2009 9:13 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: 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.

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.