04-14-2015 05:12 AM
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.
Solved! Go to Solution.
04-15-2015 12:21 AM
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
04-14-2015 11:07 AM
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?
04-15-2015 12:05 AM
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.
04-15-2015 12:17 AM
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.
04-15-2015 12:21 AM
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
04-20-2015 06:46 AM
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
04-22-2015 07:33 AM
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