Veritas-bu

Re: [Veritas-bu] robtest

2008-07-11 14:53:23
Subject: Re: [Veritas-bu] robtest
From: "Jim Horalek" <jimh AT federaledge DOT com>
To: "'JC Cheney'" <joseph_cheney AT symantec DOT com>, <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Fri, 11 Jul 2008 11:36:14 -0700
You might want to compare the output of tpconfig -d and scan. Make sure the robotic paths are the same. Scan will show the current path. tpconfig will show whats in the database.
 
Jim
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of JC Cheney
Sent: Friday, July 11, 2008 12:05 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] robtest

Paul,

 

The acsd is a process used by nbu when dealing with robots under ACS/LS control – in this case you don’t need it as you’ve got tld type robots.

 

What your describing here sounds like an issue with your vtl in terms of its ability to emulate a physical library. What is the appliance (make, model, firmware revision, etc.) and what type of library is it attempting to emulate?

 

Regards

JC

 

From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Esson, Paul
Sent: 11 July 2008 06:46
To: Scott Jacobson; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] robtest

 

Scott,

 

The sgscan is finding the library at the correct target port/device path.  What is the acsd process?

 

Regards,

 

Paul Esson

 

 


From: Scott Jacobson [mailto:sjacobso AT novell DOT com]
Sent: 11 July 2008 06:42
To: veritas-bu AT mailman.eng.auburn DOT edu; Esson, Paul
Subject: Re: [Veritas-bu] robtest

 

Paul,

 

Make sure you have a persistent "acsd" process running from your primary device controller and/or the master server that's NOW controlling the robotic devices when you run robtest.  If you've changed the control path's as you've indicated, it might be similar to an issue I had in which was resolved when I simply removed and then added the device back into "Devices".

 

If a continuing sgscan gives you the same problem, I'm suspecting a HBA/Zoning problem.

 

However, if you run "robtest", then "inquiry" and have the same problem, it could be

mapping issues etc..... as was indicated by Paul.

 

-sj

>>> "Esson, Paul" <Paul.Esson AT Redstor DOT com> 7/10/2008 10:26 PM >>>

Folks,

 

NetBackup 6.5.2 Solaris 10 Master Server, Solaris 10 Medias, EMC Disk Library + Quantum Scalar i2000 Tape Library

 

Anybody out there know robtest well? 

 

I have an issue with a robot where I can't inventory it.  I don't get an error, just no information on slots at all - it's as if the library thinks it has no media.  This all stems from when I had to change the robotic control path on two VTLs. I made the same change on both, in terms of changing the HBA target ports used for robotic control, one has been fine and one has had the above error ever since.

 

When I run sgscan the problem VTL is detected and NetBackup seems to identify it correctly in terms of serial number etc.  I can use robtest to show drives, move media from slots to drives and check drive status at the OS level with the Solaris mt command and see media loaded in drives.  However, when I try to show slots I get the following error:

 

################################################################

Robot Selection
---------------
  1)  TLD 1
  2)  TLD 2
  3)  TLD 3
  4)  TLD 4
  5)  TLD 5
  6)  TLD 6
  7)  none/quit
Enter choice: 2

Robot selected: TLD(2)   robotic path = /dev/sg/c0tw203908001b903926l0

Invoking robotic test utility:
/usr/openv/volmgr/bin/tldtest -rn 2 -r /dev/sg/c0tw203908001b903926l0

Opening /dev/sg/c0tw203908001b903926l0
MODE_SENSE complete
Enter tld commands (? returns help information)
s s
user command failed, may be timeout, scsi_pkt.us_reason = 3
read_element_status ioctl() failed: Error 0

##################################################################

From what I can ascertain this error is a transport error:  #define CMD_TRAN_ERR 3 /* unspecified transport error */ which suggests I may have gotten something wrong with the robotic path re-configuration and yet I am able to move media between slots and drives.  What I wanted to ask the group was this.  When I run commands like s d or m s# d# in robtest, am I using the robotic path /dev/sg/c0tw203908001b903926l0 or is robtest using information held in NetBackup somewhere?  Is it only when I query slot information with s s that I use the robotic path?
 
I was thinking that as robtest selects the above path successfully and can do s d, m s# d#, etc it must be using the robotic path and therefore the problem is not in the device re-configuration?  I can actually run backups with this VTL and have media loaded, written to and unloaded successfully.  

 

Regards,

Paul Esson
Redstor Limited

Direct:               +44 (0) 1224 595381
Mobile:          +44 (0) 7766 906514
E-Mail:          paul.esson AT redstor DOT com
Web:            www.redstor.com

REDSTOR LIMITED
Torridon House
73-75 Regent Quay
Aberdeen
UK
AB11 5AR

Disclaimer:
The information included in this e-mail is of a confidential nature and is intended only for the addressee.  If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful.  Disclosure to any party other than the addressee, whether inadvertent or otherwise is not intended to waive privilege or confidentiality.

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>