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.costa AT logica DOT
com>wrote:
>
>
> 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Roger Deschner
> Sent: quinta-feira, 9 de Julho de 2009 16:07
> To: ADSM-L AT VM.MARIST DOT 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 rogerd AT uic DOT
> 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> >Of Sean English
> >Sent: Wednesday, July 08, 2009 11:47 AM
> >To: ADSM-L AT VM.MARIST DOT 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 <zforray AT VCU DOT EDU>
> >Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >07/08/2009 11:30 AM
> >Please respond to
> >"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> >
> >To
> >ADSM-L AT VM.MARIST DOT 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 this email /
> Pour contribuer comme Logica au respect de l'environnement, merci de ne pas
> imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen
> Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a
> respeitar o ambiente nao imprimindo este correio electronico.
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
|
