0% found this document useful (0 votes)
61 views6 pages

SOP - Removing Disabled Paths From Solaris-Veritas

Uploaded by

fast2win2029
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views6 pages

SOP - Removing Disabled Paths From Solaris-Veritas

Uploaded by

fast2win2029
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Vodafone Internal

SOP – How to remove disabled paths from Solaris/Veritas

Date : 29-Dec-2015 Vodafone-C2


Vodafone internal

Contents
................................................................................................................................................................................................................................ 0
INTRODUCTION – HOW TO REMOVE DISABLED PATHS FROM SOLARIS/VERITAS...................................................................... 2
PROCEDURE - TO REMOVE DISABLED PATHS ......................................................................................................................................... 2

Version History

Version Date Author Change Description


1.0 29-12-2015 Sumit Tiwari Initial Draft

Date : 29-Dec-2015 Vodafone- C2


Vodafone internal

Introduction – How to remove disabled paths from Solaris/Veritas


When storage luns have been removed or made unavailable prior to the clean-up of luns
from Veritas/OS level, Solaris device entries will still exist for those luns. In such scenario,
you will see disabled paths in Veritas and “drive not available” in the format output. Once
you are sure, that those disabled path are no longer in use, we can remove/clean from OS.

Procedure - To remove disabled paths


The following output shows the system where few luns have been removed:

root@adedwh12s# echo |format |grep -i "drive not available"


316. c2t500009740833D520d187 <drive not available>
317. c2t500009740833D520d188 <drive not available>
318. c2t500009740833D520d189 <drive not available>
319. c2t500009740833D520d190 <drive not available>
1064. c3t500009740833D51Cd142 <drive not available>
1065. c3t500009740833D51Cd178 <drive not available>
1066. c3t500009740833D51Cd187 <drive not available>
1067. c3t500009740833D51Cd188 <drive not available>
1068. c3t500009740833D51Cd189 <drive not available>
1069. c3t500009740833D51Cd190 <drive not available>
root@adedwh12s#

root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i failing


c2::500009740833d520,187 disk connected configured failing
c2::500009740833d520,188 disk connected configured failing
c2::500009740833d520,189 disk connected configured failing
c2::500009740833d520,190 disk connected configured failing
c3::500009740833d51c,142 disk connected configured failing
c3::500009740833d51c,178 disk connected configured failing
c3::500009740833d51c,187 disk connected configured failing
c3::500009740833d51c,188 disk connected configured failing
c3::500009740833d51c,189 disk connected configured failing
c3::500009740833d51c,190 disk connected configured failing
root@adedwh12s#

root@adedwh12s# vxdmpadm getdmpnode enclosure=apevmx06 |grep DISABLED


apevmx06_236d DISABLED EMC 1 -1 2 apevmx06
apevmx06_239a DISABLED EMC 2 -1 3 apevmx06
apevmx06_239b DISABLED EMC 2 -1 3 apevmx06
apevmx06_239c DISABLED EMC 2 0 2 apevmx06
apevmx06_239d DISABLED EMC 2 -1 3 apevmx06
apevmx06_2391 DISABLED EMC 1 0 1 apevmx06
root@adedwh12s#

Date : 29-Dec-2015 Vodafone- C2


Vodafone internal

root@adedwh12s# vxdisk -e list |egrep


"apevmx06_236d|apevmx06_239a|apevmx06_239b|apevmx06_239c|apevmx06_239d|apevmx06_2
391"
apevmx06_236d auto - - error c3t500009740833D51Cd142s2 -
apevmx06_239a auto - - error c2t500009740833D520d187s2 -
apevmx06_239b auto - - error c2t500009740833D520d188s2 -
apevmx06_239c auto - - error c2t500009740833D520d189s2 -
apevmx06_239d auto - - error c2t500009740833D520d190s2 -
apevmx06_2391 auto - - error c3t500009740833D51Cd178s2 –
root@adedwh12s#

Prerequisite for Veritas: Remove device from VxFS/VxVM first (Optional, in case if the
related volume/FS exists)

If devices are under Veritas control:


First unmount the affected underlying VxFS filesystems, if any. Remove the related volume
and remove the disk from dg (If required):
Then remove associated disk from VxVM volume manager: "vxdisk rm" on the device:

root@adedwh12s# vxdisk rm apevmx06_236d


root@adedwh12s# vxdisk rm apevmx06_239a
root@adedwh12s# vxdisk rm apevmx06_239b
root@adedwh12s# vxdisk rm apevmx06_239c
root@adedwh12s# vxdisk rm apevmx06_239d
root@adedwh12s# vxdisk rm apevmx06_2391
root@adedwh12s#

root@adedwh12s# vxdisk -e list |egrep


"apevmx06_236d|apevmx06_239a|apevmx06_239b|apevmx06_239c|apevmx06_239d|apevmx06_2
391"
root@adedwh12s#

We can now see above, that "cfgadm -al -o show_FCP_dev" shows the "failing" state and
format shows the device as "<drive type unknown>".

The first step in removing these devices is to change the state shown in the cfgadm output
from "failing" to "unusable". This is done with the following command:

root@adedwh12s# cfgadm -c configure c2 c3

root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i failing


c2::500009740833d520,187 disk connected configured failing
c2::500009740833d520,188 disk connected configured failing
c2::500009740833d520,189 disk connected configured failing
c2::500009740833d520,190 disk connected configured failing
c3::500009740833d51c,142 disk connected configured failing

Date : 29-Dec-2015 Vodafone- C2


Vodafone internal

c3::500009740833d51c,178 disk connected configured failing


c3::500009740833d51c,187 disk connected configured failing
c3::500009740833d51c,188 disk connected configured failing
c3::500009740833d51c,189 disk connected configured failing
c3::500009740833d51c,190 disk connected configured failing
root@adedwh12s#

If the devices remaining in a "failing" state according to the above output from cfgadm, and
they do not move to an "unusable" state after running "cfgadm -c configure" as shown
above, then the following command can also be tried, otherwise this step is not needed:

(Option step, in case if luns is still in failing state)

root@adedwh12s# luxadm -e offline /dev/dsk/c2t500009740833D520d187s2


root@adedwh12s# luxadm -e offline /dev/dsk/c2t500009740833D520d188s2
root@adedwh12s# luxadm -e offline /dev/dsk/c2t500009740833D520d189s2
root@adedwh12s# luxadm -e offline /dev/dsk/c2t500009740833D520d190s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd142s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd178s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd187s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd188s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd189s2
root@adedwh12s# luxadm -e offline /dev/dsk/c3t500009740833D51Cd190s2
root@adedwh12s#

root@adedwh12s# echo |format |grep -i "drive not available"


root@adedwh12s#
root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i failing
root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i unusable
c2::500009740833d520,187 disk connected configured unusable
c2::500009740833d520,188 disk connected configured unusable
c2::500009740833d520,189 disk connected configured unusable
c2::500009740833d520,190 disk connected configured unusable
c3::500009740833d51c,142 disk connected configured unusable
c3::500009740833d51c,178 disk connected configured unusable
c3::500009740833d51c,187 disk connected configured unusable
c3::500009740833d51c,188 disk connected configured unusable
c3::500009740833d51c,189 disk connected configured unusable
c3::500009740833d51c,190 disk connected configured unusable
root@adedwh12s#

Now that the state of the inaccessible luns has been changed to "unusable" in the output
from cfgadm, we can remove those entries from the list with the following command:

root@adedwh12s# cfgadm -o unusable_FCP_dev -c unconfigure c2::500009740833d520


root@adedwh12s# cfgadm -o unusable_FCP_dev -c unconfigure c3::500009740833d51c
root@adedwh12s#

If you tried remove device and you got some errors below, you'll use this:

Date : 29-Dec-2015 Vodafone- C2


Vodafone internal

# cfgadm -o unusable_FCP_dev -c unconfigure c2::500009740833d520


cfgadm: Library error: failed to offline: /devices/scsi_vhci/ssd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Resource Information
------------------------------------------------ -------------------------
/dev/dsk/c2t500009740833d52s2 Device being used by VxVM

# cfgadm -f -o unusable_FCP_dev -c unconfigure c2::500009740833d520

root@adedwh12s# cfgadm -al |egrep -i "500009740833D520|500009740833D51C"


c2::500009740833d520 disk connected configured unknown
c3::500009740833d51c disk connected configured unknown
root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i unusable
root@adedwh12s# cfgadm -al -o show_FCP_dev |grep -i failing
root@adedwh12s#
root@adedwh12s# vxdctl enable
root@adedwh12s# vxdisk -e list |egrep
"apevmx06_236d|apevmx06_239a|apevmx06_239b|apevmx06_239c|apevmx06_239d|apevmx06_2
391"
root@adedwh12s# vxdmpadm getdmpnode enclosure=apevmx06 |grep DISABLED

Now we see that the luns are no longer displayed in the format listing. Even though the
output of the format command looks good, there are still entries for the removed devices in
/dev/disk and /dev/rdsk. These can be removed by using the devfsadm command.

root@adedwh12s# devfsadm -C
root@adedwh12s#

Approval History

Serial
Role
Number Date Reviewer Comments
1 29-12-2015 Vaibhav Pansare

Date : 29-Dec-2015 Vodafone- C2

You might also like