There must be a reason why sandiscovery defaults to off on non-windows
platforms.
Anyway, I think you're right and that *should* be the correct behavior
of SANDISCOVERY=ON.
However, I prefer to stick with persistent binding and tight control on
SAN changes. This way, I can at least avoid spending time on false
positives like this one described here
http://www-01.ibm.com/support/docview.wss?uid=swg1IC59807, even for the
latest 5.5.x and 6.1.x versions.
jmC
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: quinta-feira, 9 de Julho de 2009 18:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a
better way")
I've been following this thread and have a question about AUTODETECT:
I've seen this message:
ANR8955I Drive drive name in library library name with serial number
serial number is updated with the newly discovered serial number serial
number .
as a result of having the drives defined with AUTODETECT=YES and also
SANDISCOVERY ON with the appropriate HBA library installed.
Can anyone expand on why this does or doesn't always work when changing
a drive serial #? Or does it only work when the device number changes?
W
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.
>
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.
|