Re: [ADSM-L] Library manager/library conundrum

Subject: Re: [ADSM-L] Library manager/library conundrum
Date: 2008-10-03 08:31:12
From: Paul Zarnowski
Permanent Link: http://www.backupinsight.com/openservices/ml/8d4f3fadd

At this point, I think it would be useful to see the following output, just
to make sure we're all seeing the same thing..

from your library manager server:

Q DRIVE F=D
Q PATH F=D
Q LIBRARY F=D

On your library client server:

Q LIBRARY F=D

At 03:26 PM 10/2/2008, Remco Post wrote:
>One other thing comes to mind, have you updated the library to
>shared=yes on the libmgr? I'd think yes from what you told us, but
>just to be sure.
>
>On Oct 2, 2008, at 21:12 , Remco Post wrote:
>
>>On Oct 2, 2008, at 20:59 , Mark Stapleton wrote:
>>
>>>Here's the deal...
>>>
>>>The physical device tape0, as seen by the library manager, has the
>>>devicename mt[phone protected]. The same tape drive on the client, however,
>>>sees
>>>the tape drive as devicename mt[phone protected]. (We can tell this by the tape
>>>drive serial numbers being reported.)
>>>
>>>We've deleted all but one library manager-defined path from the
>>>library
>>>client to the tape drive, and we've tried both mt definitions in the
>>>library manager's path statements--the one from the library manager
>>>and
>>>the one from the library client. In both cases, the manager changes
>>>ownership of the library volume, mounts the volume in the drive, and
>>>then the client waits and waits, and finally times out with the
>>>ANR8779E
>>>error message.
>>>
>>>We're stumped. The only thing that I can think is that the library
>>>client is at[phone protected] and the library server is at[phone protected].
>>
>>hmmm, odd. If there is only one path, then the libmgr will use only
>>that drive. Is there any indication in the systemlog that might
>>indicate anything?
>>
>>Is the drive SAN connected? Could you manually mount an empty tape an
>>dd (or whatever your os provides) and write some zero's to the tape?
>>and read them back? If it's an IBM drive you could use mttest. If that
>>fails, it's the SAN or the drive. Is the path from the libmgr on the
>>same drive port as the client? Since the libmgr is obviously able to
>>read the label, any difference in physical paths is now suspect.
>>
>>I guess this is a process of elimination. Verify basic drive
>>functionality outside TSM first. Secondly, (I guess you've done this a
>>dozen times by now) verify the drive paths. If those are both OK, then
>>it must be a TSM issue.
>>
>>Is the host dual-path connected to the drive? Have you tried
>>disconnecting one path?
>>
>>This is getting really interesting ;-)
>>
>>>
>>>--
>>>Mark Stapleton ([email protected])
>>>CDW Berbee
>>>System engineer
>>>7145 Boone Avenue North, Suite 140
>>>Brooklyn Park MN 55428-1511
>>>[phone protected]
>>>www.berbee.com
>>>
>>>
>>>>-----Original Message-----
>>>>From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
>>>>Behalf
>>>>Of Fred Johanson
>>>>Sent: Thursday, October 02, 2008 12:22 PM
>>>>To: ADSM-L@VM.MARIST.EDU
>>>>Subject: Re: [ADSM-L] Library manager/library conundrum
>>>>
>>>>If you're SAN connected, Q SAN on the client supplies the device
>>>>name
>>>>for each path.
>>>>
>>>>Fred Johanson
>>>>TSM Administrator
>>>>University of Chicago
>>>>
>>>>[phone protected]
>>>>
>>>>-----Original Message-----
>>>>From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
>>>>Behalf
>>>>Of Remco Post
>>>>Sent: Thursday, October 02, 2008 12:04 PM
>>>>To: ADSM-L@VM.MARIST.EDU
>>>>Subject: Re: [ADSM-L] Library manager/library conundrum
>>>>
>>>>On Oct 2, 2008, at 18:33 , Mark Stapleton wrote:
>>>>
>>>>>From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On
>>>Behalf
>>>>>Of Paul Zarnowski
>>>>>>Double check your element numbers and paths to the drives.  Make
>>>>sure
>>>>>you
>>>>>>have a path defined for each drive to each library-client server.
>>>>>
>>>>>There are no drive definitions for the "remote" library in the
>>>>library
>>>>>client, and therefore no element numbers or paths to check. There
>>>>>is
>>>>a
>>>>>path in the library manager that connects each of the tape drives
>>>>>to
>>>>>the
>>>>>library client, and as I mentioned there is obviously some
>>>>>communication
>>>>>going on.
>>>>
>>>>>Here's another question that has been asked...
>>>>>
>>>>>When a library client sends migrated data from disk to a tape drive
>>>>>managed by a library manager, does the data flow on fiber from the
>>>>>client to the tape drive directly, or does it flow across the LAN
>>>>from
>>>>>the client to the manager, and then on fiber from the manager to
>>>>>the
>>>>>tape drive?
>>>>
>>>>This may be a clue, the drive is accessed directly by the library
>>>>client. All the library server does is verify the label. After that,
>>>>the device is opened by the client. This is the reason the paths
>>>>(defined on the library server) must be correct for the library
>>>>client. So if a drive called drive4 is \\.\tape4 on the server and \
>>>>\.
>>>>\tape1 on the client, there must be a path, defined on the server,
>>>>from your client to drive4 via device \\.\tape1
>>>>
>>>>>--
>>>>>Mark Stapleton ([email protected])
>>>>>CDW Berbee
>>>>>System engineer
>>>>>7145 Boone Avenue North, Suite 140
>>>>>Brooklyn Park MN 55428-1511
>>>>>[phone protected]
>>>>>www.berbee.com
>>>>
>>>>--
>>>>Met vriendelijke groeten,
>>>>
>>>>Remco Post
>>>>[email protected]
>>
>>--
>>Met vriendelijke groeten,
>>
>>Remco Post
>>[email protected]
>>[phone protected] 21 622
>
>--
>Met vriendelijke groeten,
>
>Remco Post
>[email protected]


--
Paul Zarnowski                            Ph:[phone protected]
Manager, Storage Services                 Fx:[phone protected]
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: [email protected]