← Back to the catalog

Virtual Machine Disk Corruption

A virtual machine that won't boot can fail at several layers: the virtual-disk container, a snapshot chain, the guest file system, or the host storage underneath. Recovery starts by identifying the failed layer before any repair or consolidation writes are allowed.

What's actually happening

A VM's entire disk is really one file, or a linked chain of files, on the host's storage — a VMDK, VHDX, QCOW2, or similar — that the hypervisor presents to the guest operating system as if it were a physical drive. Corruption can hit at two different levels: the container format itself, such as its header, its internal block-allocation table, or a broken link in a snapshot chain, or the file system the guest operating system has inside that container — the same kind of problem covered in file system corruption, just one layer deeper. A host crash or an interrupted snapshot operation mid-write is the most common trigger for the first kind.

How recoverable this really is

Recoverability depends on which layer is damaged. A container-header or snapshot-chain problem can be relatively contained when all component files and the host storage remain readable. Missing or overwritten snapshot extents, datastore damage, or an underlying RAID/storage failure can make the same symptom much more serious. Guest file-system corruption is a separate inner layer to analyze after a consistent virtual disk can be reconstructed or exposed.

The general approach

Recovery generally works in two possible stages: first repairing or bypassing the container-format issue — rebuilding a damaged header, reconnecting an orphaned snapshot to its correct parent, or extracting the raw disk contents directly from a container whose own metadata can't be trusted at all — to get at the guest disk's raw bytes, then treating that raw data with standard file-system or file-level recovery as needed.

The one thing not to do

Don't let the hypervisor "consolidate" snapshots or run automatic repair on a disk chain that's already showing errors. Consolidation is a write-heavy operation across the entire chain, and running it on a chain that's already inconsistent is a common way to lose the ability to recover individual snapshot states at all.

Practical, step-by-step guides for specific recovery software will be added here as separate linked articles.

This page describes the general situation, not a guaranteed fix for your specific case. If you'd rather have someone experienced take a look before you try anything, see what a hands-on evaluation looks like.