Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere ESXI

Products

• VMware vSphere ESXi

Issue/Introduction

This article discusses a Permanent Device Loss (PDL) and All-Paths-Down (APD) in ESXi and provides information on dealing with each of these scenarios.

Symptoms:

 

Permanent Device Loss (PDL)

• A datastore is shown as unavailable in the Storage view.
• A storage adapter indicates the Operational State of the device as Lost Communication.
• All paths to the device are marked as Dead.
• In the /var/run/log/vmkernel.log file, similar entries are seen:
  
  cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
  cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx".
  cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx has been removed or is permanently inaccessible.
  cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" failed H:0x8 D:0x0 P:0x0
  cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" is blocked. Not starting I/O from device.
  cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
  cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" from Plugin "NMP" failed. I/O error
  cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx has no more open connections. It is now safe to unmount datastores (if any) and delete the device.

All-Paths-Down (APD)

• A datastore is shown as unavailable in the Storage view.
• A storage adapter indicates the Operational State of the device as Dead or Error.
• All paths to the device are marked as Dead.
• Unable to connect directly to the ESXi host using the vSphere Client
• The ESXi host shows as Disconnected in vCenter Server
• In the /var/run/log/vmkernel.log file, similar entries are seen: 
  
  cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" due to Not found
  cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
  cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" is blocked. Not starting I/O from device.
  cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" - issuing command 0x4124007ba7c0
  cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" - failed to issue command due to Not found (APD), try again...
  cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx": awaiting fast path state update...
   
• A restart of the management agents may show these errors:
  
  Not all VMFS volumes were updated; the error encountered was 'No connection'.
  Errors:
  Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
  Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.
   
• The device may show as no longer listed:
  
  cpu17:10107)WARNING: Vol3: 1717: Failed to refresh FS 4beb089b-68037158-2ecc-xxxxxxxxxxxx descriptor: Device is permanently unavailable
  cpu17:10107)ScsiDeviceIO: 2316: Cmd(0x412442939bc0) 0x28, CmdSN 0x367bb6 from world 10107 to dev "eui.xxxxxxxxxxxxxxxx" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
  cpu17:10107)Vol3: 1767: Error refreshing PB resMeta: Device is permanently unavailable
  
  Note: Log excerpts are examples. Date, time, and environmental variables may vary depending on the environment.

Environment

VMware vSphere ESXi 6.x

VMware vSphere ESXi 7.x

VMware vSphere ESXi 8.x

Resolution

All-Paths-Down (APD)

An All-Paths-Down (APD) situation occurs when all paths to a device are down. As there is no indication whether this is a permanent or temporary device loss, the ESXi host keeps reattempting to establish connectivity. APD style situations commonly occur when the LUN is incorrectly unpresented from the ESXi host. The ESXi host, still believing the device is available, retries all SCSI commands indefinitely. This has an impact on the management agents, as their commands are not responded to until the device is again accessible. This causes the ESXi host to become inaccessible or not-responding in the vCenter Server.

If PDL SCSI sense codes are not returned from a device (when unable to contact the storage array, or with a storage array that does not return the supported PDL SCSI codes), then the device is in an All-Paths-Down (APD) state, and the ESXi host continues to send I/O requests until the host receives a response.

As the ESXi host is not able to determine if the device loss is permanent (PDL) or transient (APD), it indefinitely retries SCSI I/O, including:

• Userworld I/O (hostd management agent)
• Virtual machine guest I/O

Notes: 

• If an I/O request is issued from a guest, the operating system should timeout and stop the I/O.
• Due to the nature of an APD situation, there is no clean way to recover.
• The APD situation needs to be resolved at the storage array/fabric layer to restore connectivity to the host.
• All affected ESXi hosts may require a reboot to remove any residual references to the affected devices that are in an APD state.
• Performing a vMotion migration of unaffected virtual machines is not possible, as the management agents may be affected by the APD condition, and the ESXi host may become unmanaged. As a result, a reboot of an affected ESXi host forces an outage to all non-affected virtual machines on that host.
• vSphere 6.x and later have a powerful new feature as part of vSphere HA called VM Component Protection (VMCP). VMCP protects virtual machines from storage related events, specifically Permanent Device Loss (PDL) and All Paths Down (APD) incidents. For more information, see the VM Component Protection section in the vSphere Availability Guide.

Permanent Device Loss (PDL)

A clear distinction has been made between a device that is permanently lost (PDL) and a transient issue where all paths are down (APD) for an unknown reason.

For example, in the vmkernel logs, if a SCSI sense code of H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 or Logical Unit Not Supported is logged by the storage device to the ESXi host, this indicates that the device is permanently inaccessible to the ESXi host or is in a Permanent Device Loss (PDL) state. The ESXi host no longer attempts to re-establish connectivity or issue commands to the device.

Devices that suffer a non-recoverable hardware error are also recognized as being in a Permanent Device Loss (PDL) state.

This table outlines possible SCSI sense codes that determine if a device is in a PDL state:
 

SCSI Sense Code	Description
H:0x0 D:0x2 P:0x0 Valid sense data: 0x__ /0x25/0x0	*LOGICAL UNIT NOT SUPPORTED
H:0x0 D:0x2 P:0x0 Valid sense data: 0x__/0x68/0x0	*LOGICAL UNIT NOT CONFIGURED
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4/0x4c/0x0	HARDWARE ERROR/LOGICAL UNIT FAILED SELF-CONFIGURATION
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4/0x3e/0x3	HARDWARE ERROR/LOGICAL UNIT FAILED SELF-TEST
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4/0x3e/0x1	HARDWARE ERROR/LOGICAL UNIT FAILURE
H:0x0 D:0x2 P:0x0 Valid sense data: 0x2/0x4c/0x0	NOT READY/LOGICAL UNIT FAILED SELF-CONFIGURATION
H:0x0 D:0x2 P:0x0 Valid sense data: 0x2/0x3e/0x3	NOT READY/LOGICAL UNIT FAILED SELF-TEST
H:0x0 D:0x2 P:0x0 Valid sense data: 0x2/0x3e/0x1	NOT READY/LOGICAL UNIT FAILURE

*ESXi only checks ASC/ASCQ and if it happens to be 0x25/0x0 or 0x68/0x0, it marks device as PDL.

Note: Some iSCSI arrays map LUN-to-Target as a one-to-one relationship. That is, there is only ever a single LUN per Target. In this case, the iSCSI arrays do not return the appropriate SCSI sense code, so a PDL on these array types cannot be detected.

Planned versus unplanned PDL

A planned PDL occurs when there is an intent to remove a device presented to the ESXi host. The datastore must first be unmounted, then the device detached before the storage device can be unpresented at the storage array. For more information, see How to detach a LUN device from ESXi hosts .

An unplanned PDL occurs when the storage device is unexpectedly unpresented from the storage array without the unmount and detach being executed on the ESXi host.

VMware provides a feature called Auto-remove for automatic removal of devices during an unplanned PDL. For more information, please check Disabling PDL AutoRemove feature vSphere ESXI.

To clean up an unplanned PDL:

1. All running virtual machines from the datastore must be powered off and unregistered from the vCenter Server.
2. From the vSphere Client, navigate to the Configuration tab of the ESXi host, and click Storage.
3. Right-click the datastore being removed and click Unmount. The Confirm Datastore Unmount window displays.
4. When the prerequisite criteria have been passed, the OK button appears.
   
   Note: If this error is seen when unmounting the LUN:
   
   Call datastore refresh for object <name_of_LUN> on vCenter server <name_of_vCenter> failed.
   
   There may be a  a snapshot LUN presented. To resolve this issue, remove that snapshot LUN on the array side. For more information, contact the storage vendor.
    
5. Perform a rescan on all of the ESXi hosts that had visibility to the LUN.
   
   Note: If there are active references to the device or pending I/O, the ESXi host still lists the device after the rescan. Check for virtual machines, templates, ISO images, floppy images, and raw device mappings which may still have an active reference to the device or datastore.
    
6. If the LUN is still being used and available again, go to each host, right-click the LUN, and click Mount.
   
   Note: One possible cause for an unplanned PDL is that the LUN ran out space causing it to become inaccessible.