VM disks report 0 MB capacity: Some of the disks failed to load

Products

VMware vSphere ESXi

Issue/Introduction

A Virtual Machine (VM) - often one used as a backup proxy - reports one or more hard disks with a capacity of 0 MB in the vSphere Client.
The VM Summary tab displays the warning: "Some of the disks of the virtual machine [VM_NAME] on host [HOSTNAME] failed to load. The information present for them in the virtual machine configuration may be incomplete".
In the ESXi /var/run/log/vobd.log, the following entries are observed:
Waiting for timed out HB
Lost access to volume [DATASTORE_NAME] due to connectivity issues.
ESXi /var/run/log/vmkernel.log may show SCSI errors such as H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x1d 0x0 indicating an ATS miscompare or a storage inaccessibility.
Storage array performance charts show high I/O latency or queue depth saturation prior to the event.

Environment

VMware vSphere ESXi

Cause

This issue occurs when high-intensity I/O operations saturate the storage array's processing queue. This saturation prevents the ESXi host from completing the Atomic Test and Set (ATS) heartbeat operations within the required timeout period. When the heartbeat fails, the host drops the path to the storage to prevent metadata corruption. Consequently, the virtual machine configuration becomes incomplete because the host's management agent (hostd) cannot parse the .vmx or perform a READ CAPACITY operation on the .vmdk files, leading to the 0 MB reporting error.

This can also occur when a 3rd-party backup operation using "hot-add" backup mechanisms is interrupted—for example, due to a partial network outage or host connectivity loss. In these scenarios, the backup proxy VM retains a "stale" or "orphaned" VMDK attachment. Because the backup process failed to cleanly detach the hot-added disk, the descriptor remains in the configuration, but the pointer to the underlying storage is invalid or unreachable. The management layer defaults the disk size to 0 MB to maintain configuration integrity.

Resolution

Step 1: Restore Storage Connectivity

Identify and terminate the high I/O tasks on the storage array causing the saturation.
Log in to the ESXi host via SSH or the vSphere Client.
Rescan the storage adapters to restore the dropped paths:
1. To rescan the storage adapters via vSphere Client: Navigate to the Host, select Configure, click Storage Adapters under Storage, and click Rescan Storage.
2. To rescan the storage adapters via CLI: esxcli storage core adapter rescan --all
Verify that the datastore status returns to Online and paths are active.

If the VM disk capacity still reports 0 MB after the storage rescan:

Step 2: Refresh VM Configuration

To safely reload the VM configuration without altering its Managed Object Reference (MoRef) ID, use the CLI.

Retrieve the Virtual Machine ID (VMID) of the affected VM: vim-cmd vmsvc/getallvms | grep -i "[VM_NAME]"
Reload the VM configuration using the VMID from the previous step: vim-cmd vmsvc/reload [VM_ID]

Step 3: Prevent Recurrence (Optional)

If timeouts persist during peak I/O on supported arrays, consider reverting the heartbeat mechanism to the legacy SCSI method by temporarily disabling ATS heartbeat on all hosts sharing the datastore: esxcli system settings advanced set -i 0 -o /VMFS3/UseATSForHBOnVMFS5
To verify the setting has been successfully changed to 0, execute: esxcli system settings advanced list -o /VMFS3/UseATSForHBOnVMFS5

Note: Do not disable ATS heartbeat if the host is part of a vSAN cluster, as this negatively impacts data accessibility.