vMotion Operations Fail with "Out of Resources" Error for VMs on VVOL When LUNs Experience Frequent State Changes

Products

• VMware vCenter Server

Issue/Introduction

When attempting to vMotion virtual machines or put hosts into maintenance mode, operations fail with "Out of resources" errors and swap file extension failures. This occurs despite adequate resources being available on both source and destination hosts.

• vMotion operations fail with "Launch failure... Out of resources" errors
• Virtual machines report inability to extend swap files
• VASA provider shows connection exhaustion messages
• Multiple "REPORTED LUNS DATA HAS CHANGED" messages appear in logs
• Issues consistently affect the same subset of virtual machines

 

Environment

• VMware vSphere environments using vVols storage
• vSphere 7.0 or 8.0 environments
• Storage arrays configured with protocol endpoints for vVols
• Virtual machines using vVol storage

Cause

The issue occurs when LUNs being used as protocol endpoints for vVols experience an abnormally high frequency of state changes. While occasional LUN state changes are normal (typically during host reboots or 1-2 times per day), experiencing hundreds of state changes per hour indicates an underlying storage array issue.

These frequent state changes trigger repeated SCSI UNIT ATTENTION responses with the sense code 0x6 0x3f 0xe (REPORTED LUNS DATA HAS CHANGED), which impacts the ability of ESXi to perform storage operations required for vMotion.

Resolution

1. Identify affected LUNs:
   1. Check /var/log/vmkernel.log for messages containing "REPORTED LUNS DATA HAS CHANGED" sense codes:
      Example:
      
              2025-01-30T22:56:23.136Z cpu50:#######)NMP: nmp_ThrottleLogForDevice:3875: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x3f 0xe. Act:NONE. cmdId.initiator=0x############ CmdSN 0x0
      
      
   2. Note the frequency of these messages (normal is 1-2 per day)
   3. Record the LUN identifiers from these messages
      
      
2. Verify the source of state changes:
   1. Look for "H:0x0 D:0x2 P:0x0" in the error messages
   2. This indicates the changes are reported by the array rather than the host
      
      
3. Correlate affected VMs with LUNs:
   1. Check which VMs consistently fail vMotion
   2. Verify these VMs are using the affected LUNs as protocol endpoints
      
      
4. Contact storage vendor support:
   1. Provide list of affected LUNs
   2. Share frequency of state change messages
   3. Request investigation of LUN stability issues

Additional Information

• SCSI sense code 0x6 0x3f 0xe indicates a UNIT ATTENTION condition specifically for LUN data changes
• The issue may initially appear as a VASA provider problem due to connection exhaustion, but this is a symptom rather than the root cause
      Related: Possible Migration failures of virtual machines stored on vVols due to overloaded VASA providers
• Virtual machines on unaffected LUNs should continue to vMotion successfully