Hi George,
The udev config files used by Lin_tape allow for tieing specific device names
to attributes of the tape drives like their serial number, or perhaps LUN
number.
I was a bit surprised to see that all EMC EDL devices assigned to a given path
are presented all on the same WWNN, differing only by LUN.
Multiple connections to a VTL is common. From what I've seen, only one control
path is typically enabled, and this takes LUN 0. LUN 0 is not reserved on any
other paths. So moving a control device from one path to another causes all the
LUNS to change.
I don't know what incentive Tivoli has to make Lin_tape behave better with EDL
pretending (badly) to be a 3584, but it does look like they've at least left a
breadcrumb trail to allow us to do it ourselves.
Does you mechanism for resolving the SCSI reserve problem cover the case where
the TSM instances are running on different machines?
Thanks,
[RC]
On Oct 18, 2010, at 11:26 AM, giblackwood <tsm-forum AT BACKUPCENTRAL DOT COM>
wrote:
Mr Forray,
I know a lot about this problem you are dealing with. My name is George
Blackwood. I was a Systems Engineer with IBM for 30 years. Among other things,
I was a SAN, tape, and TSM specialist. I have been retired for 2 years, 1
month. I have my own consulting business doing what I did when I was an IBMer.
When Linux is rebooted (RedHat, SLES, whatever), it will scan and re-discover
its SCSI and FCP (Fibre Channel Protocol) tape resources without regard of what
it knew about those same devices before the reboot (this is not the case with
some UNIX systems).
So, unless you have one changer and one tape drive, you have no guarantee that
the Linux device numbers will be the same after reboot. So, chances are
IBMtape0 will be IBMtape20 the next time you reboot.
IBM's answer is to set "SANDISCOVERY ON". This works sometimes for a small number of
drives (under 20), and will sometimes work for more. But after 18 months of being in and out of IBM
PMRs and "CritSits", I have given up on sandiscovery to fix this issue.
I wrote a BASH script to fix this issue. A current customer of mine has 8
RedHat Linux servers sharing 12 TSM instances (we can move them around as need
be). Two instances are Library Managers. All instances have access to 4 EMC
EDLs. Each EDL has 80 drives. So that comes to 3890 drives paths, plus 4
Library paths to maintain.
The script I wrote discovers what TSM instances (Library Servers and Clients)
are running on a given Linux server that has just been rebooted. It compensates
for any drives that may be mounted, or any Libraries that are in use, and
re-defines all the Library and drive paths for any TSM instance on a given
Linux server.
So if one of the 8 servers needs to be rebooted, the script is run on that server after
reboot. There is no need to unmount and quiesce Libraries. The only requirement is the
Library Managers must be up. The script will also find what drives are in a SCSI reserve
"lock out". And, it is safe to be run during full production time.
I can give you a few pointers to write a similar script (for free), or for a
fee, write it for you. I guarantee my work.
George Blackwood
Blackwood Data Protection Consulting, LLC
785-218-9961
georgeblackwood AT sunflower DOT com
+----------------------------------------------------------------------
|This was sent by georgeblackwood AT sunflower DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
|
