StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Recreating VMDK descriptor files for disks and their snapshots in VMware vSphere virtual machines

  • March 28, 2023
  • 14 min read
Virtualization Architect. Alex is a certified VMware vExpert and the Founder of VMC, a company focused on virtualization, and the CEO of Nova Games, a mobile game publisher.
Virtualization Architect. Alex is a certified VMware vExpert and the Founder of VMC, a company focused on virtualization, and the CEO of Nova Games, a mobile game publisher.

Sometimes, while working with VMware vSphere virtual machines, admins encounter an error with VMDK descriptor files that goes like this:

  • The virtual machine disk file is listed in the Datastore Browser, but does not have an icon
  • When powering on a virtual machine, you see a “File not found” error
  • The  <vm_name>-flat.vmdk file is in the virtual machine’s directory but the <vm_name>.vmdk is not visible
  • The  <vm_name>.vmdk file does not exist or is corrupted

These events can occur due to different reasons, but they always mean one thing: the disk descriptor file for the VM’s disk is either corrupted or missing. You can still fix everything if the <vm_name>-flat.vmdk file still exists and is preserved completely. The whole process of recreating the disk descriptor file for the virtual machine’s disk is quite straightforward, as you can see for yourself from the article or this video below:

Let’s take a look at two separate aspects of this issue, which are recreating the disk descriptor file for the virtual machine’s disk and the disk descriptor files for snapshots.

Part 1 – Recreating a VMDK descriptor file for the VM’s disk

Before proceeding with the steps below, make sure you have a full VM copy (remember that the files could be scattered through different directories, it depends on the VM’s settings). If there’s a backup and you don’t mind recovering it, then it will be simpler and safer to just go with that.

Long story short, to recreate a VDMK descriptor file you need to do the following:

1. Connect to the VMware ESXi host as root through SSH. You can also perform operations through the DCUI console itself.

2. Navigate to the directory that contains the VM to identify and record the exact size of the <vm_name>-flat.vmdk file using this command:

You will see the disk size in bytes. The output is supposed to look something like that:

3. Recreate the VMDK (<vm_name>.vmdk) file using the disk size from the previous step:

Now, rename the descriptor file for the new disk to the file we will need for the original disk. Furthermore, delete the empty disk that we will no longer need (temp-flat.vmdk).

4. Open the renamed descriptor file and change the red lines:

# Disk DescriptorFile

# Extent description
RW 8388608 VMFS “vmdisk0-flat.vmdk”

# The Disk Data Base

ddb.virtualHWVersion = “4”
ddb.geometry.cylinders = “522”
ddb.geometry.heads = “255”
ddb.geometry.sectors = “63”
ddb.adapterType = “lsilogic”
ddb.thinProvisioned = “1”

If the original disk was not thin provisioned (thin disk), remove the last red line. Such an option had been added to avoid waiting for the new disk’s initialization (which could take a long time).

There’s also an option to change the adapter type with the ddb.adapterType = lsilogic на ddb.adapterType = pvscsi in case the paravirtualized SCSI controller was used.

To check the disk chain for consistency, run this command:

If everything is fine, you’ll see output similar to:

Disk chain is consistent.

If there’s a problem, the output will be something like this:

Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).

If you’re successful, power the VM after adding it back to the vSphere Client environment.

Part 2 – Recreating descriptor files for the VM’s snapshots (delta-files)

The situation is getting more complicated if the VM happens to have snapshots, which makes the virtual machine directory look like this (important files are marked with red color once again):

drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw——- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw——- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw——- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw——- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw——- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw——- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw——- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw——- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw——- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw——- 1 root root 259 Aug 16 09:36 examplevm.vmxf

You can find more details about the appropriate procedure there, here we are only covering the basics (let me say to you one more time that you do need to back up all virtual machine files before any operations):

1. Selecting the required files

Basically, virtual machine snapshot files are stored in the vmfsSparse format, paired together with delta extent file, where all the data actually is (such as examplevm-000001-delta.vmdk).

That way, using the aforementioned example, we need to locate snapshot files like examplevm-000001.vmdk and examplevm-000002.vmdk. Keep in mind, though, that both disks and their snapshots could be in different directories on different datastores, which is why the first step is to find out where you keep them. In case you have doubts about the names, check for them in vmware.log to find out the necessary paths.

2. Creating a new snapshot descriptor

Assume that the descriptor file for the delta disk examplevm-000001.vmdk is missing or corrupted. Let’s recreate a descriptor from its associated file examplevm.vmdk by copying it:

3. Changing the information to data for the snapshot file

Now we need to open this file in text and start modifying it. Looks something like this:

# Disk DescriptorFile

# Extent description
RW 31457280 VMFS “examplevm-flat.vmdk”

# The Disk Data Base

ddb.virtualHWVersion = “7”
ddb.longContentID = “5fd87dda1dc77cafd5be881a19741890”
ddb.uuid = “60 00 C2 9e 3d 8d 45 82-dd 1f e4 93 22 da 9c 61”
ddb.geometry.cylinders = “1958”
ddb.geometry.heads = “255”
ddb.geometry.sectors = “63”
ddb.adapterType = “lsilogic”

The lines marked with red color are those that we are going to change, the lines marked with blue are the ones we are going to delete.

Do the following with this file:

  • The CID=19741890 line is going to be replaced with a randomly generated eight-digits value (disk identifier)
  • The parentCID=ffffffff line is going to be replaced with the parentCID=19741890 line (parent disk identifier; could be a parent snapshot)
  • The createType=”vmfs” line is going to be replaced with the createType=”vmfsSparse” line
  • The RW 31457280 VMFS “examplevm-flat.vmdk” line is going to be replaced with the RW 31457280 VMFSSPARSE “examplevm-000001-delta.vmdk” line (the 31457280 number stays the same – as it is supposed to stay the same for all delta disks)

4. Adding the information inherent to the snapshot file

  • Now we’re going to add something new to the snapshot:

Under the createType=”vmfsSparse” line we are going to add the parentFileNameHint=”examplevm.vmdk” line

Time to remove stuff we don’t need anymore. Delete the following lines from the file (these are only necessary for the original disk):

This one can stay though:

That way, you’re supposed to see output similar to:

After that, try powering the VM with the snapshot. Don’t forget to check the descriptor integration using this command:

This algorithm will work for further levels of delta snapshots if their data disks are alright. Just don’t forget to create backups prior to making any changes and good luck!


Found Alex’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!