Dell EMC VPLEX: DU post changing the LUN type from thin to thick on BE array

Issue:

DU/High performance impact is seen against an affected volume which is converted from thin to thick LUN on the Back-End array.  

In current release, there is an issue with VPLEX Back-end code where it can erroneously consider a LUN as thin capable if underlying LUN at the back-end array is converted from thin to non-thin capable provisioning.

The thin-capable attribute needs to be updated at both level's i.e.,Virtual-Volume and Storage-Volume automatically when LUN type is changed at the back-end array. Please be informed that thin-capable attribute should get auto-updated at storage-volume level as 'thin-capable' is a read-only attribute at storage-volume level.

If the thin-capable attribute is not manually changed at Virtual-Volume level, VPlex will continue to send UNMAP request to the logical-unit whose LUN type is changed to thick and all those request will be aborted by the back-end LUN.

Resolution:

This issue is addressed in GeoSynchrony 6.2.0.00.00.32 and above releases.

Workaround Steps:

1. Post changing the LUN type from thin to thick on the BE array, make sure that the "Thin-capable" attribute is changed on virtual-volume accordingly.  Changing the attribute to false on virtual-volume will not send anymore UNMAP commands to BE LUN as follows:

1.a) Log into the vplexcli context as follows:
NOTE: VPLEX running GeoSynchrony before 6.x when accessing the vplexcli will require the service account credentials for login.

service@ManagementServer:~> vplexcli
Trying ::1...
Connected to localhost.
Escape character is '^]'.
 
Enter User Name: service
 
Password:
Creating logfile:/var/log/VPlex/cli/session.log_service_localhost_Logfile_T24531_yyyymmddhhmmss

1.b) Get into the concerned virtual-volume context and issue the below command as follows which shows "thin-capable" attribute is set to "true" even after LUN type is changed from thin to thick at the BE array:
 

1.c) Manually disable "thin-capable" attribute to "false" as follows which will disable thin provisioning at virtual volume level as follows:

Example:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> set thin-capable false

1.d) After changing 'thin-capable' attribute to "false" at virtual-volume, the problematic virtual-volume health should be changed to "OK". Run the 'cluster status' command to check the overall health of the VPlex as follows:

Example:
VPlexcli:/clusters/cluster-1/virtual-volumes/device_****_vol> ll
Name Value
-------------------------- ----------------------------------------
block-count 429654016
block-size 4K
cache-mode synchronous
capacity 12G
consistency-group -
expandable true
expandable-capacity 0B
expansion-method storage-volume
expansion-status -
health-indications []
health-state ok
locality distributed
operational-status ok
recoverpoint-protection-at []
recoverpoint-usage -
scsi-release-delay 0
service-status running
storage-array-family clariion
storage-tier -
supporting-device device_****_1
system-id device_**_1_vol
thin-capable false
thin-enabled disabled
volume-type virtual-volume
vpd-id VPD83T3:60001440000****************

VPlexcli:/> cluster status
Cluster cluster-1
        operational-status:            ok
        transitioning-indications:
        transitioning-progress:
        health-state:                  ok
        health-indications:
        local-com:                     ok

Cluster cluster-2
        operational-status:            ok
        transitioning-indications:
        transitioning-progress:
        health-state:                  ok
        health-indications:
        local-com:                     ok

wan-com: ok


2. If virtual-volume health is still reporting "error" or "critical-failure" state post following above step's, then perform array re-discover against the BE array, where the problematic logical-unit belongs to. The array re-discover should automatically refresh the attribute at storage-volume level as follows:

Example:
VPlexcli:/> array re-discover -a /clusters/cluster-1/storage-elements/storage-arrays/EMC-CLARiiON-CKM0018******* -c cluster-1

3. Even after multiple attempts of array re-discover, if the problematic virtual-volume health is still reporting "error" or "critical-failure" then the corresponding logical unit at the back-end array side needs to be removed from array's storage-group/pool and added back to it, and re-run array re-discover command so that a manual discovery gets triggered at VPLEX side. 

4. If none of the above step's helps in resolving the issue, we recommend user to perform upgrade to fixed version mentioned above and then proceed with LUN type change activity.