cancel
Showing results for 
Search instead for 
Did you mean: 

one path missing for Drive 0

psb
Level 2

Hi,

There were 2 drives each with 2 drive paths -

Drive 0 had the following drive paths associated with it -
      /dev/rmt/0
      /dev/rmt/7
Drive 1 had -
      /dev/rmt/4
      /dev/rmt/6

Now I can see only 1 (/dev/rmt/7) path for Drive 0.

> /usr/openv/volmgr/bin/tpconfig -d
Id  DriveName           Type   Residence
      Drive Path                                                       Status
****************************************************************************
0   HP.ULTRIUM4-SCSI.000 hcart  TLD(0)  DRIVE=1
      /dev/rmt/7cbn                                                    UP
1   HP.ULTRIUM4-SCSI.001 hcart  TLD(0)  DRIVE=2
      /dev/rmt/4cbn                                                    UP
      /dev/rmt/6cbn                                                    UP

Currently defined robotics are:
  TLD(0)     robotic path = /dev/sg/c0tw5001438016056cabl1

EMM Server = xhkny91006

How can I get the missing path back for Drive 0.
Please help.

1 ACCEPTED SOLUTION

Accepted Solutions

Marianne
Level 6
Partner    VIP    Accredited Certified

Scan will only show device paths that respond to scsi_commands.

See if the OS can use the /dev/rmt/0 path (as the OS does not automatically remove path entries when it loses connectivity):

mt -f /dev/rmt/0 status

Also verify OS visibility with:

cfgadm -al

View solution in original post

6 REPLIES 6

sdo
Moderator
Moderator
Partner    VIP    Certified

Does /usr/openv/volmgr/bin/scan show all paths?

If not then it's an OS issue and not a NetBackup issue.

If no-one has updated the device manager configuration the the altrenate drive path should still be reported by tpconfig (and also probably show as down).

So, either:

1) The path never existed at the OS layer and so device configuration never made a note of it - but you seen to have evidence that it did exist in teh device configuration database (in EMM).  Where does that evidence of four paths come from?  Does it come from previous command output - or from some 'site' documentation?

...or:

2) The path did exist at the OS layer, and NetBackup had configured itself to remember the path - BUT the path has since been lost by the OS... AND someone has updated the device configuration to remove the lost OS path.

Has anyone run the device discovery wizard recently?

psb
Level 2

scan shows the 3 drive paths mentioned above but not the missing one(/dev/rmt/0).

/usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/rmt/4cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cb0l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M11B"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/rmt/7cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cabl0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M12V"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/sg/c0tw5001438016056cabl1"
Passthru Name: "/dev/sg/c0tw5001438016056cabl1"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      MSL G3 Series   8.10"
Vendor ID  : "HP      "
Product ID : "MSL G3 Series   "
Product Rev: "8.10"
Serial Number: "MXA209Z3B9"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "HP      MSL G3 Series   MXA209Z3B9"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-5
Number of Drives : 2
Number of Slots  : 48
Number of Media Access Ports: 0
Drive 1 Serial Number      : "HU1206M12V"
Drive 2 Serial Number      : "HU1206M11B"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/rmt/6cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cb1l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M11B"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0
 

 

Regarding the evdience of the path, we have a customised backup solution for some specific type of server. the logs for it shows the path which is not getting listed into tpconfig

Apart from this when Is for the concern path it gets listed -
> ls /dev/rmt/0
/dev/rmt/0

I doubt if any one has run a device discovery wizard.

psb
Level 2

scan does not list the missing /dev/rmt/0) path
/usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/rmt/4cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cb0l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M11B"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/rmt/7cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cabl0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M12V"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/sg/c0tw5001438016056cabl1"
Passthru Name: "/dev/sg/c0tw5001438016056cabl1"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      MSL G3 Series   8.10"
Vendor ID  : "HP      "
Product ID : "MSL G3 Series   "
Product Rev: "8.10"
Serial Number: "MXA209Z3B9"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "HP      MSL G3 Series   MXA209Z3B9"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-5
Number of Drives : 2
Number of Slots  : 48
Number of Media Access Ports: 0
Drive 1 Serial Number      : "HU1206M12V"
Drive 2 Serial Number      : "HU1206M11B"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/rmt/6cbn"
Passthru Name: "/dev/sg/c0tw5001438016056cb1l0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "HP      Ultrium 4-SCSI  H68W"
Vendor ID  : "HP      "
Product ID : "Ultrium 4-SCSI  "
Product Rev: "H68W"
Serial Number: "HU1206M11B"
WWN          : ""
WWN Id Type  : 0
Device Identifier: ""
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-5
Flags : 0x0
Reason: 0x0

Regarding the evdience for /dev/rmt/0, we have a customised backup solution and I observed the drive paths for both the drives from it's logs.

Apart from this when I list the path it exist -
> ls /dev/rmt/0
/dev/rmt/0

I am almost sure that no one ran device discovery wizard.

Marianne
Level 6
Partner    VIP    Accredited Certified

Scan will only show device paths that respond to scsi_commands.

See if the OS can use the /dev/rmt/0 path (as the OS does not automatically remove path entries when it loses connectivity):

mt -f /dev/rmt/0 status

Also verify OS visibility with:

cfgadm -al

psb
Level 2

can not use the path :
> mt -f /dev/rmt/0 status
/dev/rmt/0: write protected or reserved.


I can observe that the not listed drive path is present in the OS -  

bash-3.2# cfgadm -al
Ap_Id                          Type         Receptacle   Occupant     Condition
c0                             fc-fabric    connected    configured   unknown
c0::5001438016056caa           tape         connected    configured   unknown
c0::5001438016056cb0           tape         connected    configured   unknown
c1                             fc-fabric    connected    configured   unknown
c1::5001438016056cab           tape         connected    configured   unknown
c1::5001438016056cb1           tape         connected    configured   unknown

> ls -rtl /dev/rmt/*cbn
lrwxrwxrwx   1 root     root          87 Nov 25 21:17 /dev/rmt/0cbn -> ../../devices/pci@0,0/pci8086,340e@7/pci103c,3261@0/fp@0,0/tape@w5001438016056caa,0:cbn
lrwxrwxrwx   1 root     root          87 Nov 25 21:17 /dev/rmt/4cbn -> ../../devices/pci@0,0/pci8086,340e@7/pci103c,3261@0/fp@0,0/tape@w5001438016056cb0,0:cbn
lrwxrwxrwx   1 root     root          87 Nov 25 21:17 /dev/rmt/6cbn -> ../../devices/pci@0,0/pci8086,3410@9/pci103c,3261@0/fp@0,0/tape@w5001438016056cb1,0:cbn
lrwxrwxrwx   1 root     root          87 Nov 25 21:17 /dev/rmt/7cbn -> ../../devices/pci@0,0/pci8086,3410@9/pci103c,3261@0/fp@0,0/tape@w5001438016056cab,0:cbn

Marianne
Level 6
Partner    VIP    Accredited Certified

So, something is holding a reservation on the tape drive.

You can try to power-cycle the drive or use 'mt' commands to try and forcereserver and release the reservation.

Try:
mt /dev/rmt/0 forcereserve 

followed by:
mt -f /dev/rmt/0 release

Check /var/adm/messages for errors.

From NBU point of view you could try this:

vmoprcmd -crawlreleasebyname HP.ULTRIUM4-SCSI.000

vmoprcmd -reset 0