Redo Log of VMDK Is Corrupt on ESXi: Recovery

“The redo log of VM-000001.vmdk is corrupt. If the problem persists, discard the redo log.” appears when ESXi opens a snapshot delta disk and finds its metadata inconsistent with the chain it belongs to. On a standard VM that means a broken snapshot chain; on a Horizon pool built from linked clones it is frequently a storage-side problem exposed after a datastore migration. This guide covers ESXi 7.0, 8.0 U3 and 9.x, and Horizon 8 pools that still use linked clones or instant clones with delta disks.

Applies to ESXi 7.0, 8.0 U3 and 9.x; Horizon 8 linked-clone and instant-clone pools

Short answer: For a single VM, power it off, inspect the descriptor files with cat and vmkfstools -e to find where the parent chain breaks, and either recreate the missing descriptor or revert to the last good snapshot. For Horizon linked clones after a storage migration, the cause is usually VAAI hardware acceleration behaving badly on the array: set DataMover.HardwareAcceleratedMove, DataMover.HardwareAcceleratedInit and VMFS3.HardwareAcceleratedLocking to 0 on every host, then recompose or rebuild the pool so the replica and clones are regenerated.

Understand the delta chain

A snapshot disk (redo log) records only the blocks changed since its parent. Each delta’s descriptor file names its parent with a parentFileNameHint and a content ID that must match the parent’s CID. If the parent was moved, deleted, or its CID changed because it was written to directly, the child cannot be opened and ESXi reports the redo log as corrupt. Common ways this happens:

• A backup product removed or failed to remove its temporary snapshot, leaving an orphaned delta that the VM still references.
• Someone deleted a delta file from the datastore to “free space”.
• A Storage vMotion or array-side copy of a linked-clone pool used VAAI offload primitives that the array implemented incorrectly, corrupting the copied redo logs.
• A host crash while a delta was being committed.

Diagnose a single VM

Power off the VM and read the descriptors from the host shell:

cd /vmfs/volumes/datastore1/VM
cat VM.vmx | grep -i vmdk
cat VM-000002.vmdk
vmkfstools -e VM-000002.vmdk

vmkfstools -e walks the chain and reports “Disk chain is consistent” or names the link that fails. Compare the CID and parentCID values across each descriptor from the newest delta back to the base disk. If a descriptor is missing but its -delta.vmdk data file exists, recreate the descriptor by copying a sibling’s descriptor and correcting the extent line and parent hint. If the delta data file itself is gone, the changes it held are lost; the only options are to point the .vmx at the last intact parent (losing later writes) or restore from backup.

Check vmware.log in the VM folder for the precise file name the error refers to; the message in the client is sometimes one level above the real break.

Horizon linked clones and VAAI

Horizon linked-clone pools consist of a replica disk plus a small delta per desktop. When an administrator moves the pool’s datastore, or the array performs a clone operation with VAAI XCOPY, some storage firmware returns success while producing deltas whose metadata does not match the replica. Every desktop in the pool then fails to power on with the redo-log error, and Horizon marks them “Error” or “Agent Unreachable”. The workaround is to disable the VAAI primitives on each host in the cluster:

esxcli system settings advanced set -o /DataMover/HardwareAcceleratedMove -i 0
esxcli system settings advanced set -o /DataMover/HardwareAcceleratedInit -i 0
esxcli system settings advanced set -o /VMFS3/HardwareAcceleratedLocking -i 0
esxcli system settings advanced list -o /DataMover/HardwareAcceleratedMove

The same settings are in the vSphere Client under host » Configure » System » Advanced System Settings. Apply to every host that can run the pool. Then, in the Horizon console, rebalance or recompose the pool so a fresh replica is created and the clones are rebuilt against it. For instant-clone pools, push a new image, which regenerates the parent VMs and clones. Once the array vendor confirms a firmware fix, re-enable the primitives and test a pool clone before relying on it.

Verify

For a standalone VM, vmkfstools -e on the topmost delta should report a consistent chain, and the VM should power on with no snapshot warnings in Snapshot Manager. For Horizon, the pool’s desktops should reach “Available” after the recompose and a test login should succeed; a broken chain reappears immediately as another redo-log error at power-on.

Common pitfall

Clicking “discard the redo log” as the error suggests deletes the changes stored in that delta. On a linked clone that is acceptable because the desktop is disposable, but on a production server it throws away everything written since the snapshot was taken. Diagnose the chain first and take a copy of the VM folder (or at least the descriptor files) before altering anything. For a related Horizon symptom see Fix Horizon “Agent Unreachable” and desktops stuck in Pending state.

Redo log of vmdk is corrupt at a glance

Official documentation: Broadcom TechDocs (VMware), Linux man pages.

Related guides: Fix “Another task is already in progress” in vCenter with vim-cmd task_info · Fix ESXi \”Datastore not accessible\”: All Paths Down (APD) and Permanent Device Loss (PDL) · Kill an unresponsive VM on ESXi with vim-cmd, esxcli and esxtop.

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

ESXi 7.0, 8.0 U3 and 9.x; Horizon 8 linked-clone and instant-clone pools

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

techdocs.broadcom.com