LUN creation on an IBM Storage DS8000 can be delayed recognized by the server

Asset ID:	1-72-2019196.1
Update Date:	2018-03-07
Keywords:

Solution Type Problem Resolution Sure

Solution 2019196.1 : LUN creation on an IBM Storage DS8000 can be delayed recognized by the server

Applies to:

SPARC T5-4 - Version All Versions to All Versions [Release All Releases]
Solaris Operating System - Version 8 6/00 U1 and later
Information in this document applies to any platform.
The in depth scsi protocol knowledge is provided from Peter Davies

IBM has acknowledged that their storage does not follow
the spec with regards to sending 'unit attention'/'report
luns has changed', but have now generated a change request
to get this implemented into the future array firmware

Symptoms

When a new lun is mapped, or unmapped, on the storage,
the host is unaware there has been any configuration
change, unless the storage communicates that change

The standard way of 'announcing' this change is for
the storage to raise a 'check condition' for the
very next IO, to any already existing lun for the
affected target.

The host will react to this check condition by
reading associated sense data from the storage
for the check condition.

The sense data returned will be the following:

The sense key will be set to 'Unit Attention'

The ASC/ASCQ ( additional sense code and additional
sense code qualifier ) will be set to "Reported luns
data has changed"

As soon as the host reads this sense data, it issues
a "Report Luns" scsi command to the storage target,
and the target responds with a list of currently
mapped luns.

If this list contains a new lun number, that new
lun will then be configured.

If there is no traffic on any LUN on an IBM DS8000,

the storage will not communicates that change

Cause

If there is no traffic on any LUN on an IBM DS8000,

the storage will not communicates that change

Solution

The dtrace and driver trace logs, collected during
recent tests, show that a Unit Attention was not
generated when a new lun was mapped.

As the DS8000 does not currently implement the
standard described above, the host will not
immediately recognize and configure a newly
mapped lun.

As a workaround, until this functionality is
implemented, a reset ( forcelip ) will need to
be generated on each path the new lun is mapped
to on the host.

This reset is an alternate way to get the host
drivers to issue the 'Report Luns' command needed
to recognize any change in lun mapping.

After the forcelip, the new lun will be configured
in the kernel, and a following devfsadm will then
generated new device paths.

References

<NOTE:1017942.1> - Solaris How to Unconfigure Logical Unit from SAN Storage
<NOTE:1001971.1> - Solaris Cluster Global Path And Device ID (DID) Inconsistent For Instance Resolution Path
<NOTE:1944152.1> - Scsi Error : SYNCHRONIZE CACHE command failed (5)
<NOTE:1542438.1> - Discovery of Fibre Channel (FC) Disk (LUN) and Tape Storage Devices from a Solaris host perspective
<NOTE:1639048.1> - Best Practice Before Removing LUN(s) and/or Target(s) From a Solaris Server
<NOTE:1018716.1> - How to Unconfigure a Single Lun from a Target which has multiple Luns
<NOTE:1639070.1> - Steps For Clearing Devices in Unusable or Failing State From cfgadm After LUNs Have Already Been Removed
<NOTE:1617956.1> - I/O SERD threshold values are set too low and may result in PCIEX-8000-J5, PCIEX-8000-YJ and PCIEX-8000-KP faults.

Attachments

This solution has no attachment