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
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
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
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),
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
