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

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

book

Article ID: 317492

calendar_today

Updated On:

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

This issue is currently under investigation by both DellEMC and VMware engineering teams. Please refer to the following DellEMC article for more information:

 https://www.dell.com/support/kbdoc/en-us/000210352 

Resolution

There is no resolution at this time. Please review the workaround section to mitigate this issue.


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)

For details to disable XCOPY on the array please reference the dell article:  https://www.dell.com/support/kbdoc/en-us/000210352

 

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.