VPLEX: Error 0x8a2d9050 and Resulting Firmware scsi/162 Events on Default LUN Zero (DL0)
Summary: This article talks to the issue of an invalid Peripheral Qualifier and what to do to address this issue.
Symptoms
Error message:
Callhome event Critical_0x8a2d9050
Seeing scsi/162 events streaming in the firmware.logs:
2019/05/08 17:05:24.39: scsi/162 Peripheral info is set as 0x3f. VPD parameters are outside scope of the VPD standard
2019/05/08 10:50:33.79: scsi/162 Peripheral info is set as 0x20. VPD parameters are outside scope of the VPD standard
In both cases, Peripheral ID codes of 0x20 and 0x3F are sharing invalid Peripheral Qualifier of 001. A device having the specified device type is not connected to this logical unit. However, the device server can support the specified device type on this logical unit.
0x20 Peripheral type is Direct-access block device.
0x3F Peripheral type is Unknown or no device type.
Cause
Steaming scsi/162 events that are noted above are caused by the Design Principle around DL0:
- User zones a new array to VPLEX.
- No storage LUs are provisioned (which is normal practice).
- In the absence of any LUs, SCSI layer adds a LUN0 (and labels it as DL0).
- The LUN0 discovery results in finding the array details (Vendor, Product, and Version).
- This array is now visible in VPLEXCLI.
- User can add new storage LUs and perform array rediscover to sync VPLEX with the array's LUN inventory.
- Some of the VPD INQs (step4) are returning an invalid PERIPHERAL QUALIFIER field.
It should be mentioned that DL0 can also occur when a end user zones additional array ports to the VPLEX which are not included in any storage arrays masking view between the array and the VPLEX. This means DL0 can still be reported even though there is a real LUN0 in all storage-array masking views.
Resolution
Resolution:
This issue was fixed in GeoSynchrony 6.2 Patch 5 and later
Workaround:
Instead of using DL0, provision a real LUN0 for all storage array masking views in all storage arrays behind the VPLEX. Also, all array ports which have been zoned to the VPLEX should be in a storage array masking view or the zoning should be removed if the ports are not in use. Otherwise, this causes DL0 to occur despite having a real LUN0 in all masking views.
Overall, we really should not be processing any device with a non, 0x00, or Peripheral ID code.
More notes regarding LUN0 requirements:
- LUN0 can be an existing LUN on the storage-array. However, it may be easier to create a LUN and assign this as LUN0.
- LUN0 can be of any size (minimum size 1 block or 4 KB).
- LUN0 only must be present in the masking view, but this volume does not have to be claimed by VPLEX.
Note: Depending on the array attached to the VPLEX you may need to reach out to the Array Vendor and/or Support team for instructions for how to setup a LUN0 and present it to the VPLEX.
Additional Information
Note: If an end user is using a storage-array from the "Symmetrix" family (VMAX or PowerMax), they should reference the following KB article 000051855: Unisphere for Powermax: How To assign HLU=0 in the unisphere for PowerMax 9.0 that talks on how to assign a LUN0 within the array Unisphere and ensure that all array masking views contain a LUN address of 0000 which resolves the LUN0 issue.
In some VMAX cases, INQs on a subset of Paths with DL0 were failing. The bad path with VPID VPD83T3:60000970000492600000000000000000 is what is considered a ghost LUN. This is what scsi/162 was designed to catch.