In-Guest VM Corruption occurs after Storage VMotion within the same array on DellEMC PowerMAX V4 Arrays

Products

• VMware vSphere ESXi

Issue/Introduction

Symptoms:

Upon completion of Storage vMotion within the same array (leveraging the XCOPY VAAI primitive), the virtual machine may:

1. Throw immediate file system errors
2. Fail to load the OS upon next boot/reboot citing file system corruption
3. Crash (BSOD, etc) followed by an automatic a file system check on next boot/reboot
4. Other unspecified application or database issues 

Cause

Dell engineering has isolated this issue to be due to a bug in their target block versioning feature that was implemented in PowerMax V4 to improve XCOPY performance. It has been verified that when the target block versioning feature is turned off, the issue is not reproduced.

Resolution

Dell has released a DTA for this issue to provide guidance to their customers: https://www.dell.com/support/kbdoc/en-us/000210352

Workaround:

At this time, the only known workaround is to disable the XCOPY VAAI feature either on the ESXi host or at the PowerMAX V4 array level. To disable XCOPY on ESXi, please see the following KB article: Disabling Hardware Accelerated Move (XCOPY) in ESXi (2146567)

 

The XCOPY primitive is not the source of the issue, but has been found to trigger the issue.

Disabling XCOPY is a global setting on ESXi hosts so if other array make and models are in the environment and XCOPY is still desired to be used for operations on the other arrays then the recommended solution is to disable XCOPY at the PowerMAX V4 level. To do this, please contact DellEMC support for their assistance.