VMware descriptor recovery

A remaining flat VMDK may still contain the guest disk, but it needs an exact descriptor and snapshot context.

A VMware virtual disk commonly consists of a small text descriptor and a much larger flat extent containing guest sectors. Datastore incidents, accidental deletion, failed migration, or cleanup can remove the descriptor while leaving the flat file.

Start a recovery case Call 682-325-7712

Understand the symptom

The descriptor defines extent size, geometry, adapter type, provisioning, and parent relationships.

WHY

What is happening

Broadcom documents recreating a missing descriptor from a temporary virtual disk, then pointing its extent line to the original flat VMDK. A wrong sector count, adapter, snapshot relationship, or extent name can prevent access or damage a chain. Work only on protected copies.

What you may see

Symptoms that change the recovery path.

VM reports VMDK not found

The descriptor filename referenced by VMX is missing.

Large flat VMDK remains

Guest sectors may survive even though the small descriptor was deleted.

Datastore browser hides expected disk

Descriptor loss can make a flat extent look orphaned.

Snapshots also exist

The base descriptor may be one dependency in a larger delta chain.

Protect the source

Actions that can make the situation worse.

Wrong extent size shifts the disk

Incorrect sectors or geometry can expose invalid boundaries.

Attaching the base bypasses snapshots

Newer guest writes may exist only in delta disks.

Powering on writes to the candidate

Guest boot and journal replay can alter the only surviving copy.

Do this now

Safe steps before evaluation.

Copy the complete VM directory

Preserve descriptors, flat and delta extents, VMX, VMSD, logs, and lock files.

Record exact byte sizes

Do not round the flat file size when calculating sectors.

Identify virtual controller type

Save SCSI, SATA, NVMe, provisioning, and VM hardware information from VMX and logs.

Stop creation on the source datastore

Do not create a new disk with the same name where it can overwrite the extent.

NEPFOSYS process

How a data-first evaluation proceeds.

Descriptor reconstruction

NEPFOSYS derives extent size, adapter, geometry, and parent context from evidence.

Copy-based validation

A replacement descriptor is tested against a protected duplicate of the flat file.

Guest extraction

Filesystems and priority VM data are recovered without booting the only source.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Is the flat VMDK the actual data?

Usually it contains guest sectors, while the small descriptor explains how VMware should access them.

Can I create any descriptor with the same capacity?

No. Exact sectors, extent name, adapter type, provisioning, and snapshot context matter.

What if snapshot files exist?

Do not attach only the base disk. The active guest state may depend on the complete snapshot chain.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case