- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Disk 2 Disk Server Rebooted - Causes Various NO_HW...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 05:46 AM
12-10-2013 05:46 AM
Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
Greetings all...got a bit of a stinker here...i'll try to give the full info...
Basiclly we have eight ia64 hp Integrity BL860c i2 servers in an enclosure running HPUX 11.31. They are connected to two Enterprise FC Switches to a D2D HP StoreOnce 4430 Backup Server.
The D2D HP StoreOnce 4430 Backup Server was rebooted as the time needed changing. After bootup it looks like it has given new device addresses to the fibre channel switch connections and the D2D and tapedrive (I think so anyway).
All disks are online and there are no stale extents.
I've tried sorting the tapedrive out...doing what i'd usually do on a normal HPUX Itanium replacement...but it has not worked.
So...I think if this is the case, the NO-HW entries can be removed with rsmf -H...
Any suggestions Chaps?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 05:51 AM
12-10-2013 05:51 AM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
ioscan -fn
Class I H/W Path Driver S/W State H/W Type Description
=================================================================================
pibldb2 # ioscan -fn | grep fclp
fc 0 0/0/0/5/0/0/0 fclp CLAIMED INTERFACE HP 456972-B21 8Gb PCIe 2-port LPe1205 FC Mezzanine Adapter
/dev/fclp0
fc 1 0/0/0/5/0/0/1 fclp CLAIMED INTERFACE HP 456972-B21 8Gb PCIe 2-port LPe1205 FC Mezzanine Adapter
/dev/fclp1
fc 2 0/0/0/7/0/0/0 fclp CLAIMED INTERFACE HP 456972-B21 8Gb PCIe 2-port LPe1205 FC Mezzanine Adapter
/dev/fclp2
fcp 0 0/0/0/7/0/0/0.1 fclp_fcp NO_HW INTERFACE FCP Domain
ext_bus 3 0/0/0/7/0/0/0.1.17.0.0 fclp_vbus NO_HW INTERFACE FCP Array Interface
ext_bus 2 0/0/0/7/0/0/0.1.17.255.0 fclp_vbus NO_HW INTERFACE FCP Device Interface
ext_bus 7 0/0/0/7/0/0/0.1.18.0.0 fclp_vbus NO_HW INTERFACE FCP Array Interface
ext_bus 6 0/0/0/7/0/0/0.1.18.255.0 fclp_vbus NO_HW INTERFACE FCP Device Interface
ext_bus 12 0/0/0/7/0/0/0.1.19.255.0 fclp_vbus NO_HW INTERFACE FCP Device Interface
fcp 2 0/0/0/7/0/0/0.2 fclp_fcp CLAIMED INTERFACE FCP Domain
ext_bus 14 0/0/0/7/0/0/0.2.0.0.0 fclp_vbus CLAIMED INTERFACE FCP Array Interface
ext_bus 13 0/0/0/7/0/0/0.2.0.255.0 fclp_vbus CLAIMED INTERFACE FCP Device Interface
ext_bus 16 0/0/0/7/0/0/0.2.4.0.0 fclp_vbus CLAIMED INTERFACE FCP Array Interface
ext_bus 15 0/0/0/7/0/0/0.2.4.255.0 fclp_vbus CLAIMED INTERFACE FCP Device Interface
ext_bus 21 0/0/0/7/0/0/0.2.6.255.0 fclp_vbus CLAIMED INTERFACE FCP Device Interface
fc 3 0/0/0/7/0/0/1 fclp CLAIMED INTERFACE HP 456972-B21 8Gb PCIe 2-port LPe1205 FC Mezzanine Adapter
/dev/fclp3
fcp 1 0/0/0/7/0/0/1.1 fclp_fcp NO_HW INTERFACE FCP Domain
ext_bus 5 0/0/0/7/0/0/1.1.17.0.0 fclp_vbus NO_HW INTERFACE FCP Array Interface
ext_bus 4 0/0/0/7/0/0/1.1.17.255.0 fclp_vbus NO_HW INTERFACE FCP Device Interface
ext_bus 9 0/0/0/7/0/0/1.1.18.0.0 fclp_vbus NO_HW INTERFACE FCP Array Interface
ext_bus 8 0/0/0/7/0/0/1.1.18.255.0 fclp_vbus NO_HW INTERFACE FCP Device Interface
fcp 3 0/0/0/7/0/0/1.2 fclp_fcp CLAIMED INTERFACE FCP Domain
ext_bus 18 0/0/0/7/0/0/1.2.0.0.0 fclp_vbus CLAIMED INTERFACE FCP Array Interface
ext_bus 17 0/0/0/7/0/0/1.2.0.255.0 fclp_vbus CLAIMED INTERFACE FCP Device Interface
ext_bus 20 0/0/0/7/0/0/1.2.4.0.0 fclp_vbus CLAIMED INTERFACE FCP Array Interface
ext_bus 19 0/0/0/7/0/0/1.2.4.255.0 fclp_vbus CLAIMED INTERFACE FCP Device Interface
pibldb2 # ioscan -fn | grep -i d2d
autoch 7 0/0/0/7/0/0/0.2.6.255.0.3.0 schgr CLAIMED DEVICE HP D2DBS
autoch 4 0/0/0/7/0/0/0.2.6.255.0.6.0 schgr NO_HW DEVICE HP D2DBS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 05:56 AM
12-10-2013 05:56 AM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
Here's what was done for the tapedrive...
The tapedrive was offline:
ioscan -fnCtape
Class I H/W Path Driver S/W State H/W Type Description
==================================================================
tape 0 0/0/0/7/0/0/0.2.6.255.0.7.0 stape NO_HW DEVICE HP Ultrium 4-SCSI
/dev/rmt/0m /dev/rmt/0mn /dev/rmt/c21t7d0BEST /dev/rmt/c21t7d0BESTn
/dev/rmt/0mb /dev/rmt/0mnb /dev/rmt/c21t7d0BESTb /dev/rmt/c21t7d0BESTnb
An error kept appearing in syslog.log:
Dec 10 12:25:13 pibldb2 vmunix: class : lunpath, instance 28
Dec 10 12:25:13 pibldb2 vmunix: The legacy lun path (b 21 - t 6 - l 0)
Dec 10 12:25:13 pibldb2 vmunix: registration failed because it has been
Dec 10 12:25:13 pibldb2 vmunix: re-mapped from its original LUN (default dev 0xe7153000)
Dec 10 12:25:13 pibldb2 vmunix: to a different LUN (default dev 0xcd157000).
Dec 10 12:25:13 pibldb2 vmunix: The administrator has to close the original LUN and
Dec 10 12:25:13 pibldb2 vmunix: then validate this LUN re-mapping using the scsimgr
Dec 10 12:25:13 pibldb2 vmunix: command:
Dec 10 12:25:13 pibldb2 vmunix: scsimgr [-f] replace_leg_dsf -D /dev/rdsk/cxtydz
I tried to remap the existing tapedrive:
ioscan -fnCtape | grep stape
tape 0 0/0/0/7/0/0/0.2.6.255.0.7.0 stape NO_HW DEVICE HP Ultrium 4-SCSI
scsimgr -p get_attr -C lunpath -I 28 -a hw_path
0/0/0/7/0/0/0.0x5001438024911673.0x0
ioscan -m hwpath -H 0/0/0/7/0/0/0.0x5001438024911673.0x0
Lun H/W Path Lunpath H/W Path Legacy H/W Path
====================================================================
64000/0xfa00/0x19
0/0/0/7/0/0/0.0x5001438024911673.0x0 0/0/0/7/0/0/0.2.6.255.0.7.0
scsimgr -f replace_wwid -H 64000/0xfa00/0x19
scsimgr: Successfully validated binding of LUN paths with new LUN.
Yet the drive is still offline and a notification is being generated:
ioscan -fnCtape | grep stape
tape 0 0/0/0/7/0/0/0.2.6.255.0.7.0 stape NO_HW DEVICE HP Ultrium 4-SCSI
Summary:
The legacy lun path registration failed because it has been re-mapped
from its original LUN. Please refer to Device Id for more details.
Description of Error:
The legacy lun path registration failed because it has been re-mapped
from its original LUN. Please refer to Device Id for more details.
Probable Cause / Recommended Action:
A legacy lun path registration failed because it is incorrectly remapped
from its original LUN to a new LUN.
If the administrator wants to proceed with the legacy lun path
re-mapping, 1) close the original LUN 2) use scsimgr to remap the
legacy lun path to the new LUN : scsimgr [-f] replace_leg_dsf -D [legacy
lun path device special file]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 09:47 AM
12-10-2013 09:47 AM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
When you ran the scsimgr command you specified the agile hardware path, but not the legacy path that you are referring to. The messages you are seeing are giving you a hint towards this as well.
I would try the following:
# scsimgr replace_wwid -H 0/0/0/7/0/0/0.2.6.255.0.7.0
or
# scsimgr replace_leg_dsf -D /dev/rmt/0m
-Bob
Was this helpful? Like this post by giving me a thumbs up below!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 10:20 AM
12-10-2013 10:20 AM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
Thanks for the reply Bob. I tried that but alas no joy:
scsimgr replace_wwid -H 0/0/0/7/0/0/0.2.6.255.0.7.0
scsimgr: ERROR: 0/0/0/7/0/0/0.2.6.255.0.7.0 corresponds to a legacy SCSI object.
scsimgr commands do not accept legacy object hardware paths.
scsimgr replace_leg_dsf -D /dev/rmt/0m
Do you really want to replace? (y/[n])? y
scsimgr: Legacy device file '/dev/rmt/0m' binding to LUN changed successfully
ioscan -fnCtape
Class I H/W Path Driver S/W State H/W Type Description
==================================================================
tape 0 0/0/0/7/0/0/0.2.6.255.0.7.0 stape NO_HW DEVICE HP Ultrium 4-SCSI
/dev/rmt/0m /dev/rmt/0mn /dev/rmt/c21t7d0BEST /dev/rmt/c21t7d0BESTn
/dev/rmt/0mb /dev/rmt/0mnb /dev/rmt/c21t7d0BESTb /dev/rmt/c21t7d0BESTnb
Other relevant info:
ioscan -s
Class I H/W Path Driver
============================
ctl 2 0/0/0/7/0/0/0.1.17.0.0.0.0 sctl
ctl 7 0/0/0/7/0/0/0.1.18.0.0.0.0 sctl
ext_bus 10 0/0/0/7/0/0/0.1.20.255.0 fclp_vbus
autoch 0 0/0/0/7/0/0/0.1.20.255.0.0.0 schgr
ctl 5 0/0/0/7/0/0/1.1.17.0.0.0.0 sctl
ctl 9 0/0/0/7/0/0/1.1.18.0.0.0.0 sctl
ext_bus 11 0/0/0/7/0/0/1.1.20.255.0 fclp_vbus
autoch 2 0/0/0/7/0/0/1.1.20.255.0.0.0 schgr
tgtpath 5 0/0/0/7/0/0/0.0x5001a4bcfbdd4000 estp
lunpath 22 0/0/0/7/0/0/0.0x5001a4bcfbdd4000.0x0 eslpt
lunpath 23 0/0/0/7/0/0/0.0x5001a4bcfbdd4000.0x1000000000000 eslpt
tgtpath 6 0/0/0/7/0/0/1.0x5001a4bcfbdd4010 estp
lunpath 24 0/0/0/7/0/0/1.0x5001a4bcfbdd4010.0x0 eslpt
lunpath 25 0/0/0/7/0/0/1.0x5001a4bcfbdd4010.0x1000000000000 eslpt
autoch 1 64000/0xfa00/0xa eschgr
tape 1 64000/0xfa00/0xb estape
autoch 3 64000/0xfa00/0xf eschgr
tape 3 64000/0xfa00/0x10 estape
ioscan -kfnNC lunpath
Class I H/W Path Driver S/W State H/W Type Description
==================================================================
lunpath 0 0/0/0/2/0/0/0.0x0.0x0 eslpt CLAIMED LUN_PATH LUN path for ctl0
lunpath 1 0/0/0/2/0/0/0.0x0.0x4000000000000000 eslpt CLAIMED LUN_PATH LUN path for disk1
lunpath 2 0/0/0/7/0/0/0.0x5001438004c94258.0x0 eslpt CLAIMED LUN_PATH LUN path for ctl3
lunpath 12 0/0/0/7/0/0/0.0x5001438004c94258.0x4001000000000000 eslpt CLAIMED LUN_PATH LUN path for disk14
lunpath 14 0/0/0/7/0/0/0.0x5001438004c94258.0x4002000000000000 eslpt CLAIMED LUN_PATH LUN path for disk15
lunpath 16 0/0/0/7/0/0/0.0x5001438004c94258.0x4003000000000000 eslpt CLAIMED LUN_PATH LUN path for disk16
lunpath 19 0/0/0/7/0/0/0.0x5001438004c94258.0x4004000000000000 eslpt CLAIMED LUN_PATH LUN path for disk19
lunpath 4 0/0/0/7/0/0/0.0x5001438004c9425c.0x0 eslpt CLAIMED LUN_PATH LUN path for ctl3
lunpath 13 0/0/0/7/0/0/0.0x5001438004c9425c.0x4001000000000000 eslpt CLAIMED LUN_PATH LUN path for disk14
lunpath 15 0/0/0/7/0/0/0.0x5001438004c9425c.0x4002000000000000 eslpt CLAIMED LUN_PATH LUN path for disk15
lunpath 17 0/0/0/7/0/0/0.0x5001438004c9425c.0x4003000000000000 eslpt CLAIMED LUN_PATH LUN path for disk16
lunpath 20 0/0/0/7/0/0/0.0x5001438004c9425c.0x4004000000000000 eslpt CLAIMED LUN_PATH LUN path for disk19
lunpath 29 0/0/0/7/0/0/0.0x50014380249115dd.0x0 eslpt CLAIMED LUN_PATH LUN path for autoch6
lunpath 28 0/0/0/7/0/0/0.0x5001438024911673.0x0 eslpt CLAIMED LUN_PATH LUN path for tape2
lunpath 26 0/0/0/7/0/0/0.0x5001a4bcfbdd4020.0x0 eslpt NO_HW LUN_PATH LUN path for autoch5
lunpath 27 0/0/0/7/0/0/0.0x5001a4bcfbdd4020.0x1000000000000 eslpt NO_HW LUN_PATH LUN path for tape5
lunpath 3 0/0/0/7/0/0/1.0x5001438004c94259.0x0 eslpt CLAIMED LUN_PATH LUN path for ctl3
lunpath 6 0/0/0/7/0/0/1.0x5001438004c94259.0x4001000000000000 eslpt CLAIMED LUN_PATH LUN path for disk14
lunpath 8 0/0/0/7/0/0/1.0x5001438004c94259.0x4002000000000000 eslpt CLAIMED LUN_PATH LUN path for disk15
lunpath 10 0/0/0/7/0/0/1.0x5001438004c94259.0x4003000000000000 eslpt CLAIMED LUN_PATH LUN path for disk16
lunpath 18 0/0/0/7/0/0/1.0x5001438004c94259.0x4004000000000000 eslpt CLAIMED LUN_PATH LUN path for disk19
lunpath 5 0/0/0/7/0/0/1.0x5001438004c9425d.0x0 eslpt CLAIMED LUN_PATH LUN path for ctl3
lunpath 7 0/0/0/7/0/0/1.0x5001438004c9425d.0x4001000000000000 eslpt CLAIMED LUN_PATH LUN path for disk14
lunpath 9 0/0/0/7/0/0/1.0x5001438004c9425d.0x4002000000000000 eslpt CLAIMED LUN_PATH LUN path for disk15
lunpath 11 0/0/0/7/0/0/1.0x5001438004c9425d.0x4003000000000000 eslpt CLAIMED LUN_PATH LUN path for disk16
lunpath 21 0/0/0/7/0/0/1.0x5001438004c9425d.0x4004000000000000 eslpt CLAIMED LUN_PATH LUN path for disk19
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 11:01 AM
12-10-2013 11:01 AM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
scsimgr replace_wwid -H 0/0/0/7/0/0/0.2.6.255.0.7.0
scsimgr: ERROR: 0/0/0/7/0/0/0.2.6.255.0.7.0 corresponds to a legacy SCSI object.
scsimgr commands do not accept legacy object hardware paths.
Sorry, typo on my part; should have been:
# scsimgr replace_leg_dsf -H ...
-Bob
Was this helpful? Like this post by giving me a thumbs up below!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 12:18 PM
12-10-2013 12:18 PM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
I've tried two further combinations...I'll check through the manual again. Thanks anyhow.
scsimgr replace_leg_dsf -H 0/0/0/7/0/0/0.2.6.255.0.7.0
scsimgr: ERROR: 0/0/0/7/0/0/0.2.6.255.0.7.0 corresponds to a legacy SCSI object.
scsimgr commands do not accept legacy object hardware paths.
To view usage, run: scsimgr -h replace_leg_dsf
scsimgr replace_leg_dsf -H /dev/rmt/0m
scsimgr: ERROR: Could not determine the object corresponding to /dev/rmt/0m
Make sure to enter a valid hardware path of a SCSI object
To get valid objects, run : scsimgr -h replace_leg_dsf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2013 01:38 PM
12-10-2013 01:38 PM
Re: Disk 2 Disk Server Rebooted - Causes Various NO_HW Entries in ioscan
If you want to specify the device file name (/dev/rmt/0m), try the following syntax:
scsimgr replace_leg_dsf -D /dev/rmt/0m