Virtual Machine Disk Corruption
A virtual machine that won't boot, or a hypervisor flagging its disk file as corrupted, is usually a problem with one large container file, not with the storage underneath it — which is normally still fine, and makes this a more contained problem than it first looks.
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
The outer container issue is generally a good sign, since the disk file itself, and the host storage underneath it, are frequently intact — it's specifically the container's own bookkeeping, or a snapshot delta file that's gone missing or fallen out of sync with its parent, that's inconsistent. If the underlying guest file system is also damaged, that's addressed with the same techniques used for any other file system, just working from the mounted or extracted contents of the container file rather than a physical drive.
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.
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.