Re: Replacing tape drives (or there has to be a better way)
So, I manage this with a script that reads a config file, with server, sta, libs and drive's characteristics and it outputs all the define, delete, update drive and update path commands (among others). Amen! Preach it. In AIX, I do this with the following snippets: I have a config file [1] to connect the drive name with the serial number. The other fields are comments to assist my discussion with the CEs. Then I run a script [2] in a temp dir to collect the current correlation between rmt devices and serial numbers. This way I can blow away all the RMT devices, and rescan, and not care that they may be helter-skelter all around the town. This is pretty much what I do also. My script is based around a table where I've coded the tape drive model, s/n, wwn, library name and drive name. It then queries AIX to match up rmt devices and generates commands. It's interesting how the same problem gets solved and resolved, which to me indicates a major area where TSM needs enhansements. While I'm glad it's long gone, we used to run HP Omniback. On a node with tape drives (like a StorageAgent or TSM Server proper) you clicked a few buttons, it gurgled for a while, then came back all setup with it's version of drives/paths for the tape drives attached to the server. Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Replacing tape drives (or there has to be a better way)
On Thu, 9 Jul 2009 17:12:10 +0100, Costa, Justino
justino.co...@logica.com said:
As each path must match the machine device, manually redefining a
drive and it's paths (due to serial number change) it's an headache
and, most importantly, a very time consuming task.
So, I manage this with a script that reads a config file, with
server, sta, libs and drive's characteristics and it outputs all the
define, delete, update drive and update path commands (among
others).
Amen! Preach it.
In AIX, I do this with the following snippets:
I have a config file [1] to connect the drive name with the serial
number. The other fields are comments to assist my discussion with the
CEs.
Then I run a script [2] in a temp dir to collect the current
correlation between rmt devices and serial numbers. This way I can
blow away all the RMT devices, and rescan, and not care that they may
be helter-skelter all around the town.
Then I run another script, which does the moral equivalent (full of
local conventions, so I'm not quoting it here)
foreach (server on this library manager)
foreach (drive)
print update path ... [ or define, or whatever].
- Allen S. Rout
-[1]--
DRIVE0,07892730,460,new
DRIVE1,07892835,470,new
DRIVE2,07892870,480,new
--
-[2]---
#!/usr/local/bin/perl
use FileHandle;
use Data::Dumper;
my $verbose =1;
my $in = new FileHandle;
my $drives = {};
my $out = {};
$in-open(/var/tsm/system/device-correspondence.csv);
while ($in)
{
#print;
chomp;
my ($tsm,$sn) = split(/,/);
$drives-{$sn} = $tsm;
}
# print Dumper($drives);
$in-open(/usr/sbin/lscfg | grep rmt |);
while ($in)
{
my ($junk,$rmt,@junk) = split;
#print $rmt,\n;
my (@tape) = `/usr/sbin/lscfg -vl $rmt`;
my ($snline) = grep{/Serial Number\.+(\d+)$/} @tape;
#print $snline;
my ($sn) = $snline =~ /Serial Number\.+(\d+)$/;
my $drive = $drives-{$sn};
$verbose print $rmt:\tNew entry for '$drive'\n;
$out-{$sn} = new FileHandle(./serial-$sn-$drive) unless
defined($out-{$sn});
$out-{$sn}-print(@tape);
$out-{$sn}-print( `/usr/sbin/lsdev -l $rmt` );
}
---
Re: 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 ble...@winnebagoind.com To: ADSM-L@VM.MARIST.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@VM.MARIST.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: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
Re: 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 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 13, 2009 9:13 AM To: ADSM-L@VM.MARIST.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 ble...@winnebagoind.com To: ADSM-L@VM.MARIST.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@VM.MARIST.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: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
Re: Replacing tape drives (or there has to be a better way)
Well, that didn't do it. Completely deleted and redefined the paths to this drive and the drive itself. None of the library-client TSM servers can access the replacement drive eventhough its serial-number is now the same as the original. The server that owns the drive (and was rebooted) can access it just fine, so it isn't a drive/hardware problem. In the messages file on one of the clients, I get these errors: lin_tape: IBMtape7-57569 tape_inquiry_page() unable to get page 83 and if I try to run IBMtapeutil from this same server, I get the error: Enter device name (enter for /dev/IBMtape0): /dev/IBMtape7 Select mode (enter or 1=Read/Write, 2=Read Only, 3=Write Only, 4=Append): 2 Opening device... Operation failed with errno 5: Input/output error From: Bob Levad ble...@winnebagoind.com To: ADSM-L@VM.MARIST.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@VM.MARIST.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: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
Re: Replacing tape drives (or there has to be a better way)
That is right, of course, you don't NEED to work with anything except the problem drive. The only reason we drop the whole library and re-define it is that it is easy once the script is written and you don't need to be concerned with what was changed. Everything will re-detect just fine if all is well with the hardware and drivers. The only caveat is that the library needs to be quiet, which will probably be an issue for busier shops. Bob. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tchuise, Bertaut Sent: Monday, July 13, 2009 8:37 AM To: ADSM-L@VM.MARIST.EDU Subject: 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 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 13, 2009 9:13 AM To: ADSM-L@VM.MARIST.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 ble...@winnebagoind.com To: ADSM-L@VM.MARIST.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@VM.MARIST.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: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
Re: Replacing tape drives (or there has to be a better way)
Well then I must have some other problem or am missing something. Even deleting and redefining did not make it work on the non-libraryowning servers. All of the paths are defined with autodetect. I tested with my 6.1 test server. Even stopping and restarting both lin_taped and the TSM server would not make it work, eventhough the serial-number is now the same as before. After rebooting the test server, it works fine. So, I am scheduling to reboot the other 4-servers. My guess is it has something to do with the SAN/wwn that still senses the change irregardless of the serial-number being the same. From: Tchuise, Bertaut btchu...@lmus.leggmason.com To: ADSM-L@VM.MARIST.EDU Date: 07/13/2009 10:56 AM 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 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 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, July 13, 2009 9:13 AM To: ADSM-L@VM.MARIST.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 ble...@winnebagoind.com To: ADSM-L@VM.MARIST.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@VM.MARIST.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: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
Re: 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?
Re: Replacing tape drives (or there has to be a better way)
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
Re: Replacing tape drives (or there has to be a better way)
We use LTO2 LTO3 in a 3584 and the CE always sets the serial number to match the old one so that we don't have this problem, same as Sean. Regards, Jane. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: 08 July 2009 18:30 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? Please check that this email is addressed to you. If not, you should delete it immediately as its contents may be confidential and its disclosure, copying or distribution unlawful. C. J. Clark International Limited takes steps to prevent the transmission of electronic viruses but responsibility for screening incoming messages and the risk of such transmission lies with the recipient. C. J. Clark International Limited Trading as Clarks Registered in England number 141015. Registered office 40 High Street, Street, Somerset. BA16 0EQ. England. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Re: Replacing tape drives (or there has to be a better way)
Dumb ? - But I was under the impression that the TS3500 (3584)'s drive Serial Numbers were tied to the Drive Cage (rail) so the SN and WWN were static... Maybe I'm thinking 3494 w/ 3592 Drives. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Baker, Jane Sent: Thursday, July 09, 2009 2:52 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) We use LTO2 LTO3 in a 3584 and the CE always sets the serial number to match the old one so that we don't have this problem, same as Sean. Regards, Jane. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: 08 July 2009 18:30 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? Please check that this email is addressed to you. If not, you should delete it immediately as its contents may be confidential and its disclosure, copying or distribution unlawful. C. J. Clark International Limited takes steps to prevent the transmission of electronic viruses but responsibility for screening incoming messages and the risk of such transmission lies with the recipient. C. J. Clark International Limited Trading as Clarks Registered in England number 141015. Registered office 40 High Street, Street, Somerset. BA16 0EQ. England. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
Re: Replacing tape drives (or there has to be a better way)
You are correct in that the TS3500 (3584)'s drive WWN are tied to the Drive Cage. But the serial number goes with the drive. But the FE are supposed to move the old drive's serial number into the replacement drives for LT03 and higher. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Hart, Charles A Sent: Thursday, July 09, 2009 9:14 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Dumb ? - But I was under the impression that the TS3500 (3584)'s drive Serial Numbers were tied to the Drive Cage (rail) so the SN and WWN were static... Maybe I'm thinking 3494 w/ 3592 Drives. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Baker, Jane Sent: Thursday, July 09, 2009 2:52 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) We use LTO2 LTO3 in a 3584 and the CE always sets the serial number to match the old one so that we don't have this problem, same as Sean. Regards, Jane. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: 08 July 2009 18:30 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? Please check that this email is addressed to you. If not, you should delete it immediately as its contents may be confidential and its disclosure, copying or distribution unlawful. C. J. Clark International Limited takes steps to prevent the transmission of electronic viruses but responsibility for screening incoming messages and the risk of such transmission lies with the recipient. C. J. Clark International Limited Trading as Clarks Registered in England number 141015. Registered office 40 High Street, Street, Somerset. BA16 0EQ. England. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
Re: Replacing tape drives (or there has to be a better way)
Sean, Not much help to offer here but, I have been involved in many LTO drive replacements in 3584s and have never changed any hardware serial number. The only serial number that needs to change is the one TSM is using in its drive definition which should automatically get picked up on the TSM drive redefine if your hardware firmware is operating properly. I would have CE run a full calibrate on your library and check your firmware levels on library and drives for currency. Regards, Nicholas ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 07/09/2009 08:14:28 AM: [image removed] Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Hart, Charles A to: ADSM-L 07/09/2009 08:16 AM Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Please respond to ADSM: Dist Stor Manager Dumb ? - But I was under the impression that the TS3500 (3584)'s drive Serial Numbers were tied to the Drive Cage (rail) so the SN and WWN were static... Maybe I'm thinking 3494 w/ 3592 Drives. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Baker, Jane Sent: Thursday, July 09, 2009 2:52 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) We use LTO2 LTO3 in a 3584 and the CE always sets the serial number to match the old one so that we don't have this problem, same as Sean. Regards, Jane. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: 08 July 2009 18:30 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? Please check that this email is addressed to you. If not, you should delete it immediately as its contents may be confidential and its disclosure, copying or distribution unlawful. C. J. Clark International Limited takes steps to prevent the transmission of electronic viruses but responsibility for screening incoming messages and the risk of such transmission lies with the recipient. C. J. Clark International Limited Trading as Clarks Registered in England number 141015. Registered office 40 High Street, Street, Somerset. BA16 0EQ. England. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error,
Re: Replacing tape drives (or there has to be a better way)
NOW you tell me. I just went through a terrible time replacing a HP LTO-4 drive in a library. After futzing around for several hours, I wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't sympathetic to requests to change the drive serial number. I don't think serial number changing is a realistic solution to this issue. It kinda takes away the whole point of serial numbers in the first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE DRIVE, etc to deal with a drive swap and serial number change. (AIX 5.5.1 TSM server) Roger Deschner University of Illinois at Chicago rog...@uic.edu Academic Computing Communications Center On Wed, 8 Jul 2009, Len Boyle wrote: In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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?
Re: Replacing tape drives (or there has to be a better way)
I don't care if the serial number changes. In one of the sites I manage, I have 47 drives in use by 1 library manager, sharing them with 4 servers and 60 storage agents. This results on more than 1400 paths defined on the library manager. As each path must match the machine device, manually redefining a drive and it's paths (due to serial number change) it's an headache and, most importantly, a very time consuming task. So, I manage this with a script that reads a config file, with server, sta, libs and drive's characteristics and it outputs all the define, delete, update drive and update path commands (among others). As such, when I need to replace a drive or update the device special file of a drive instance, I simply run the script, grep the output and pipe it directly to another script. Replacing a drive in this way turns out to be as simple and as fast as (for example): If I need to replace drive 23, the procedure is more or less like this: Remove drive: 1) run the script greping for delete path of drive 23 = seconds 2) run the script greping for delete drive drive 23 = seconds 3) prepare acsls for drive change = couple of minutes Change HW: 4) Do the manual work of replacing the failed drive for a new one = support task, don't care how long it takes (sort of ;-) 5) Update operating systems device drivers if needed = It depends... Add drive: 6) update acsls config for the new drive = couple of minutes 7) run the script greping for define drive 23 but leave it offline = seconds 8) run the script greping for define path for drive 23 = seconds 9) put drive nline and audit the library when possible (no activity on the other drives) = a couple of minutes Total time spent = minutes ! jmC -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Roger Deschner Sent: quinta-feira, 9 de Julho de 2009 16:07 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) NOW you tell me. I just went through a terrible time replacing a HP LTO-4 drive in a library. After futzing around for several hours, I wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't sympathetic to requests to change the drive serial number. I don't think serial number changing is a realistic solution to this issue. It kinda takes away the whole point of serial numbers in the first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE DRIVE, etc to deal with a drive swap and serial number change. (AIX 5.5.1 TSM server) Roger Deschner University of Illinois at Chicago rog...@uic.edu Academic Computing Communications Center On Wed, 8 Jul 2009, Len Boyle wrote: In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? Please help Logica to respect the environment by not printing
Re: 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 On Thu, Jul 9, 2009 at 12:12 PM, Costa, Justino justino.co...@logica.comwrote: I don't care if the serial number changes. In one of the sites I manage, I have 47 drives in use by 1 library manager, sharing them with 4 servers and 60 storage agents. This results on more than 1400 paths defined on the library manager. As each path must match the machine device, manually redefining a drive and it's paths (due to serial number change) it's an headache and, most importantly, a very time consuming task. So, I manage this with a script that reads a config file, with server, sta, libs and drive's characteristics and it outputs all the define, delete, update drive and update path commands (among others). As such, when I need to replace a drive or update the device special file of a drive instance, I simply run the script, grep the output and pipe it directly to another script. Replacing a drive in this way turns out to be as simple and as fast as (for example): If I need to replace drive 23, the procedure is more or less like this: Remove drive: 1) run the script greping for delete path of drive 23 = seconds 2) run the script greping for delete drive drive 23 = seconds 3) prepare acsls for drive change = couple of minutes Change HW: 4) Do the manual work of replacing the failed drive for a new one = support task, don't care how long it takes (sort of ;-) 5) Update operating systems device drivers if needed = It depends... Add drive: 6) update acsls config for the new drive = couple of minutes 7) run the script greping for define drive 23 but leave it offline = seconds 8) run the script greping for define path for drive 23 = seconds 9) put drive nline and audit the library when possible (no activity on the other drives) = a couple of minutes Total time spent = minutes ! jmC -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Roger Deschner Sent: quinta-feira, 9 de Julho de 2009 16:07 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) NOW you tell me. I just went through a terrible time replacing a HP LTO-4 drive in a library. After futzing around for several hours, I wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't sympathetic to requests to change the drive serial number. I don't think serial number changing is a realistic solution to this issue. It kinda takes away the whole point of serial numbers in the first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE DRIVE, etc to deal with a drive swap and serial number change. (AIX 5.5.1 TSM server) Roger Deschner University of Illinois at Chicago rog...@uic.edu Academic Computing Communications Center On Wed, 8 Jul 2009, Len Boyle wrote: In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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).
Re: Replacing tape drives (or there has to be a better way)
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 On Thu, Jul 9, 2009 at 12:12 PM, Costa, Justino justino.co...@logica.comwrote: I don't care if the serial number changes. In one of the sites I manage, I have 47 drives in use by 1 library manager, sharing them with 4 servers and 60 storage agents. This results on more than 1400 paths defined on the library manager. As each path must match the machine device, manually redefining a drive and it's paths (due to serial number change) it's an headache and, most importantly, a very time consuming task. So, I manage this with a script that reads a config file, with server, sta, libs and drive's characteristics and it outputs all the define, delete, update drive and update path commands (among others). As such, when I need to replace a drive or update the device special file of a drive instance, I simply run the script, grep the output and pipe it directly to another script. Replacing a drive in this way turns out to be as simple and as fast as (for example): If I need to replace drive 23, the procedure is more or less like this: Remove drive: 1) run the script greping for delete path of drive 23 = seconds 2) run the script greping for delete drive drive 23 = seconds 3) prepare acsls for drive change = couple of minutes Change HW: 4) Do the manual work of replacing the failed drive for a new one = support task, don't care how long it takes (sort of ;-) 5) Update operating systems device drivers if needed = It depends... Add drive: 6) update acsls config for the new drive = couple of minutes 7) run the script greping for define drive 23 but leave it offline = seconds 8) run the script greping for define path for drive 23 = seconds 9) put drive nline and audit the library when possible (no activity on the other drives) = a couple of minutes Total time spent = minutes ! jmC -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Roger Deschner Sent: quinta-feira, 9 de Julho de 2009 16:07 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) NOW you tell me. I just went through a terrible time replacing a HP LTO-4 drive in a library. After futzing around for several hours, I wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't sympathetic to requests to change the drive serial number. I don't think serial number changing is a realistic solution to this issue. It kinda takes away the whole point of serial numbers in the first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE DRIVE, etc to deal with a drive swap and serial number change. (AIX 5.5.1 TSM server) Roger Deschner University of Illinois at Chicago rog...@uic.edu Academic Computing Communications Center On Wed, 8 Jul 2009, Len Boyle wrote: In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM
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?
Re: Replacing tape drives (or there has to be a better way)
Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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?
Re: Replacing tape drives (or there has to be a better way)
Thanks for the duh suggestion. I know how to get into the CE mode to change the serial number and it would make life simpler. For this drive, since it was an upgrade, this will work. However, for new drives with maintenance, I think they would frown on changing the serial #. I still would like to know how other folks handle it if they can't change the serial #. From: Sean English sean.engl...@wachovia.com To: ADSM-L@VM.MARIST.EDU Date: 07/08/2009 11:48 AM 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 Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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?
Re: Replacing tape drives (or there has to be a better way)
Well, to speak on that as well, we just had 8 new drives put into one of the libraries managed by this library manager. We were told by TSM that you are not able to just define new drives and paths to TSM because TSM is not going to recognize the element numbers. We had to recycle the library manager so that TSM would run an IOCTL and rescan the library and pick up the new drives. Thanks, Sean English Data Protection Services - Production Control Wachovia Bank, A Wells Fargo Company Office: 704.590.7146 Cell: 704.281.0318 sean.engl...@wachovia.com TSM Sharepoint Teamsite Wells Fargo Confidential: The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 12:03 PM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Thanks for the duh suggestion. I know how to get into the CE mode to change the serial number and it would make life simpler. For this drive, since it was an upgrade, this will work. However, for new drives with maintenance, I think they would frown on changing the serial #. I still would like to know how other folks handle it if they can't change the serial #. From: Sean English sean.engl...@wachovia.com To: ADSM-L@VM.MARIST.EDU Date: 07/08/2009 11:48 AM 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 Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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? image/gif
Re: Replacing tape drives (or there has to be a better way)
When IBM replace my drives on maintenance (3592-J1A and LTO4), they unloaded the VPD from the old drive and downloaded the VPD to the new drive. They also place a sticky label indicating the original serial number. IBM also has to keep their records correct for field maintenance. Our maintenance contracts specifies the SN of all the drives and what a nightmare it would be if the drives SN changes every time IBM replaces one. We just can't change the contracts every time a SN changes on a drive. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Wednesday, July 08, 2009 8:31 AM To: ADSM-L@VM.MARIST.EDU Subject: 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?
Re: Replacing tape drives (or there has to be a better way)
In fact we found out that for lto-3 and lto-4 tape drives in an IBM 3584 library, it is required that they change the serial number to match the old tape drive. Because IBM tracks the drives by serial number for maint contracts. This we found when the serial numbers that we send in for a maint contract renewal were kicked out as field engineering had not been updating the serial numbers. But not for lto-2 tape drives. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sean English Sent: Wednesday, July 08, 2009 11:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Replacing tape drives (or there has to be a better way) Zoltan, The majority of our TSM servers are AIX and we do have a setup where we share multiple library clients with one library. When we have IBM CEs come out and replace drives, they just change the serial number on the new drive to match the old drive they are replacing. Apparently there is a way to do that on the drive itself. Thanks, Sean Zoltan Forray/AC/VCU zfor...@vcu.edu Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 07/08/2009 11:30 AM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc 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?
