VPLEX: Unable to Remove Decommissioned Storage Array from VPLEX UI or CLI

Multiple arrays of identical model were configured for a VPLEX cluster, then one or more arrays were decommissioned and removed from VPLEX. If at least one identical array is still configured for the VPLEX cluster, it may be triggering the condition described in this knowledge article.

End user has decommissioned one or more, storage arrays from VPLEX (but not all arrays of a common model) and one or more of the old arrays still appear in the UI and CLI.

To see what arrays still appear as phantom arrays, run the following command at the VPlexcli prompt:     

VPlexcli:/> ll /clusters/cluster-1/storage-elements/storage-arrays
/clusters/cluster-1/storage-elements/storage-arrays:
Name                             Connectivity  Auto    Ports                Logical
-------------------------------  Status        Switch  -------------------  Unit
-------------------------------  ------------  ------  -------------------  Count
-------------------------------  ------------  ------  -------------------  -------
EMC-SYMMETRIX-111111111          ok            -       0x500009xxxxxxxxx1,  28
                                      0x500009xxxxxxxxx2,
                                      0x500009xxxxxxxxx3,
                                      0x500009xxxxxxxxx4
XtremIO-XtremApp-                error         -                            0
XtremIO-XtremApp-FNM11111111111  ok            -       0x514xxxxxxxxxxxx0,  9
                                      0x514xxxxxxxxxxxx1,
                                      0x514xxxxxxxxxxxx4,
                                      0x514xxxxxxxxxxxx5

If no LUN0 is provisioned, the storage arrays respond with a nonunique LU ID to INQ VPD83. Because of this, multiple arrays of identical model which have the Initiator-Target (ITs) with no provisioned LUNs end up having the same LU ID for the default LUN0. This causes issues when attempting to decommission one of the arrays from the VPLEX.

This issue is experienced if the remaining storage arrays do not have a real LUN0.

Check the logical-units (in VPlexcli) for all remaining arrays of identical model and check the "LUNs" column. If there is no 0x0000000000000000 entry, then this means that there is no real LUN0 provisioned from that array:     

Example without a LUN0:

VPlexcli:/cluster-1/storage-elements/storage-arrays/XtremIO-XtremApp-FNM11111111111/logical-units> ll

/clusters/cluster-1/storage-elements/storage-arrays/XtremIO-XtremApp-FNM11111111111/logical-units:
Name                                              Connectivity    Active/AAO      Passive/AAN  Visibility  LUNs                ALUA
------------------------------------------  Status             Controllers     Controllers  ----------  ------------------  Support
------------------------------------------  ----------------   --------------------  -----------  ----------  ------------------  -------
VPD83T3:514xxxxxxxxxxxx1          ok                    FNM11111111111               active      0x0001000000000000  none
VPD83T3:514xxxxxxxxxxxx2          ok                    FNM11111111111               active      0x0002000000000000  none
VPD83T3:514xxxxxxxxxxxx3          ok                    FNM11111111111               active      0x0003000000000000  none

Example having a LUN0:

VPlexcli:/cluster-1/storage-elements/storage-arrays/XtremIO-XtremApp-FNM11111111111/logical-units> ll

/clusters/cluster-1/storage-elements/storage-arrays/XtremIO-XtremApp-FNM11111111111/logical-units:
Name                               Connectivity  Active/AAO      Passive/AAN  Visibility  LUNs                ALUA
                                         Status        Controllers     Controllers  ----------  ------------------  Support

VPD83T3:514xxxxxxxxxxxx0  ok            FNM11111111111               active      0x0000000000000000  none
VPD83T3:514xxxxxxxxxxxx1  ok            FNM11111111111               active      0x0001000000000000  none
VPD83T3:514xxxxxxxxxxxx2  ok            FNM11111111111               active      0x0002000000000000  none
VPD83T3:514xxxxxxxxxxxx3  ok            FNM11111111111               active      0x0003000000000000  none

For all remaining identical arrays not being decommissioned, the user must go into the arrays and present a LUN0 to the VPLEX. Once done, rediscover the arrays in VPLEX, one at a time if multiple arrays are still configured on the VPLEX. If multiple storage-groups or masking-views are configured on the underlying array, each requires its own unique LUN0. The goal is that each zoned path between VPLEX and the storage array has a LUN0 provisioned. Once this is performed for all remaining arrays, the older or decommissioned array should automatically be removed from the VPLEX CLI or UI.

If, after following the instructions in this article, the issue persists, contact Dell Support and mention this article.

It is worth noting that this is a cosmetic alert and does not impact the functionality of the VPLEX. It is acceptable to leave the issue as-is without consequence.

This issue often self-resolves during:      

• VPLEX Nondisruptive upgrade (NDU) or Upgrade
• Rolling restart of VPLEX director firmware
• Planned power maintenance that turns the director firmware off then turns it back on

Ensure that all target ports that are zoned to VPLEX are also masked on the array. This ensures that all ITs can be provisioned with, at minimum, a real LUN0. If no LUN0 is provisioned, the array can respond with a nonunique LU ID to INQ VPD83. Because of this, multiple identical arrays which have ITs with no provisioned LUNs, end up having the same LU ID for the default LUN0. This causes issues when attempting to decommission one of the arrays from the VPLEX. This behavior has been seen (but not limited to) XtremIO, Symmetrix, or VMAX arrays provisioned to VPLEX.