Mapping new Luns Solaris host fails - cfgadm present LUN as Unusable - cannot remove unusable entries
Last updated on SEPTEMBER 15, 2016
Applies to:Sun Storage SAN Foundation Software - Version 4.4 and later
Solaris SPARC Operating System - Version 8.0 and later
Information in this document applies to any platform.
Checked for relevance 13-April-2015
Customer has a Solaris 10 sparc server, and customer is mapping some new vdisk from an SVC IBM storage array.
We found that if you map from the storage array a new vdisk/volume with a new LUN number (no used before) you can see directly the disk on solaris (with format command), no problem here.
The problem comes when a new vdisk/volume was mapped with an existing old LUN number (seen as unusable), at that point the LUN is not recognized:
We have added the following lun to reproduce the problem (SCSI_id on this case is 9, that is the LUN number)
Q. How can I remove these unusable entries? With the LUN 9, they disappeared when we mapped the LUN 9 again to the system but we can not do this for all these old LUNs.
Customer unmapped some vdisk from the storage, at that point the LUNs associated to these vdisk become as unusable (cfgadm -al -o show_FCP_dev),
but customer did not run on the server the cfgadm command "cfgadm -c unconfigure -o unusable_FCP_dev cX::WWN" to remove the unusable entries.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms