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:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, July 10, 2009 1:12 PM To: ADSM-L@VM.MARIST.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.co...@logica.com> To: ADSM-L@VM.MARIST.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@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Wanda Prather Sent: quinta-feira, 9 de Julho de 2009 18:11 To: ADSM-L@VM.MARIST.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.
