Specialist · virtual machines & VMware
A failed VM can be broken at any of four levels: the RAID underneath it, the VMFS datastore, the VMDK files themselves, or the file system inside the guest. The only sequence that works runs upwards from the bottom, each level rebuilt on images before the one above it is touched. And no, we need neither your ESXi host, nor vCenter, nor a matching anything.
Speak to an engineer about it
0800 6890668
| The problem | What that tells you | First step |
|---|---|---|
| A VM removed from the datastore | Its VMDK blocks stay on the VMFS volume until something reuses them | Freeze all new provisioning now |
| Cannot open the disk: the parent virtual disk has been modified | The snapshot chain's CIDs disagree — child and base no longer match | Never force it; chains snap |
| Datastore unreachable following a RAID failure | Storage gave way underneath, though the VMFS above it is usually mendable | Start at the lowest layer |
| A backup run has left a locked ghost snapshot | Consolidation stopped and orphaned the delta files | Frequent, and usually fixable |
| Hyper-V guest dead once a checkpoint merged | The AVHDX chain is broken, and its structures are binary rather than text | Check every parent link first |
| VMDK recovered, yet the Windows inside refuses to start | That's layer four — the guest's file system needs work | Partly finished is not finished |
As soon as it lands with us, your device gets its own case number. An engineer works out the fault, says what can genuinely be pulled off, then puts one fixed price in writing — no charge for diagnosis, no obligation, and no chargeable work until you approve it.
Physical storage is imaged and, where the array calls for it, reconstructed just as our server pages set out — everything above then works only from those read-only images.
From the image we parse the VMFS or NTFS datastore, locate the VMDKs both live and deleted, and map the snapshot chains, checking CIDs and parent links before a single thing is stitched together.
Descriptors are put right, chains consolidated the proper way, and the guest's own file system dealt with last — the job closes once the machine's data actually mounts, not once files simply exist.
You sign off a complete list of the recovered files first; only then does the recovery fee fall due. Everything returns on fresh media, postage paid, and the job stays open until you confirm the files open at your end.
Why bottom-up is not fussiness: the data in a virtual machine passes through four owners — physical blocks, VMFS, VMDK, then the guest file system — and a repair aimed at the wrong one writes fiction into everything stacked above. The proper order is dull and non-negotiable: image, rebuild, parse, extract, repair, mount. Always that way round, because it is the only sequence that cannot destroy anything.
A tidy-up script run by an admin deleted the wrong folder. Nothing touched the datastore over the weekend, so both VMDKs lay unlinked but intact; we pulled them from the VMFS image on Monday, rebuilt the descriptors, and had both machines running in a sandbox by Tuesday evening — payroll one of them.
Often, yes — removing a VM detaches its files from the datastore index, but the blocks sit there until fresh provisioning takes them. Freeze the datastore, take an image of the storage, and whole VMDKs can normally be parsed back out. How quickly you freeze decides it.
Think of it as a VMware snapshot chain flunking a paternity test: the parent ID written into the child delta stops matching the base disk, typically after a consolidation or restore that only half finished. Repair happens at descriptor level — and forcing the IDs to line up without knowing why they diverged is how a sound chain turns into lost data.
No. It all happens on our bench from images of the storage beneath — VMFS read, VMDKs extracted, guests mended — with nothing booted on your kit until you say so. A dead host makes no difference to what returns.
The thinking is the same, the syntax is not: VHDX holds binary internal logs, and AVHDX checkpoint chains carry parent links that need checking — through PowerShell rather than a text editor — before anything is merged. Layers first, images only: that rule doesn't change.
Powering a damaged device up again costs you data. Start a case first; diagnosis is free whatever you decide.