Error: tag timing out command waited 180s when booting Linux VM with RDM disks

Products

• VMware vSphere ESXi

Issue/Introduction

A Linux virtual machine (VM) remains inaccessible and fails to load the Guest OS following a reboot. The VM console hangs at the Plymouth boot screen or after reaching basic system targets. This condition occurs when the ESXi host loses connectivity to a Physical Raw Device Mapping (RDM).

Symptoms:

• The VM console displays: sd 0:0:62:0: [tag#831] timing out command, waited 180s
• The console logs show:
  • Started Show Plymouth Boot Screen.
  • Reached target Basic System.
• VMkernel logs report SCSI connectivity failures: Cmd(...) failed H:0x1 D:0x0 P:0x0
• Running esxcli storage core device list shows the device status as dead timeout.

Environment

• VMware vSphere ESXi 8.x
• VMware vSphere ESXi 9.x

Cause

The ESXi host has lost connectivity to the underlying storage LUN backed by the RDM. The VMkernel error code H:0x1 (NO_CONNECT) indicates that the LUN is no longer visible to the host’s Host Bus Adapter (HBA). This is frequently caused by 3rd-party environmental factors such as storage array port failures, incorrect LUN masking/zoning, or physical hardware faults (cabling/SFPs).

• VMkernel logs report SCSI command failures: ScsiDeviceIO: 4697: Cmd(<hex_code>) 0x1a, CmdSN <hex_code> from world <id> to dev "naa.<id>" failed H:0x1 D:0x0 P:0x0

Resolution

Perform the following troubleshooting steps:

1. Rescan storage adapters on the ESXi host to re-establish pathing.
   • Via vSphere Client: Navigate to Host > Configure > Storage > Storage Adapters > Rescan Storage.
   • Via CLI: esxcli storage core adapter rescan --all
2. Verify device status by running esxcli storage core device list -d <naa_id>. If status returns "dead timeout", proceed to physical and array-side inspections.
3. Engage the storage vendor to verify LUN masking, mapping, and FC switch zoning configurations.
4. Inspect physical FC cabling and check for SFP/transceiver faults on the host HBA and switch ports.

Workaround

If the RDM is not critical for the boot process of the Guest OS, temporarily detach the RDM disk from the VM settings to allow the VM to boot using its virtual disks.

Note: This results in the loss of access to the data on that RDM until connectivity is restored.