sesparse.vmdk - descriptor files missing (how to reinclude these HDD's in a VM's main HDD)

[casaub]

Hello,

after a reboot of an ESXi host (6.7.0, 17700523) one VM lost the vmdk file for the hard disk (flat.vmdk, 540 GB). After recreating the vmdk for the flat.vmdk (following https://kb.vmware.com/s/article/1002511) the VM started but without the data located in two files (vm-name-000001-sesparse.vmdk / 14 GB and vm-name-000002-sesparse.vmdk / 3 GB).

 

How is it possible to reinclude these sesparse.vmdk files (their data) in the VM? Just edit the vm-name.vmdk and add these sesparse.vmdk's under # Extent description or will these sesparse.vmdk's need their own descriptor files?

[a_p_]

In order to use the snapshots, they need to be chained properly. Please note that the number in the file name does not necessarily correspond with the correct order in which the chain is created.

What's important for the snapshot files are the "parentCID", and "parentFileNameHint" entries in the small descriptor .vmdk files. These entries have to match the filename, and the "CID" of their respective parent file in the chain.

Assuming that in your case the chain is
vm-name-000002.vmdk -> vm-name-000001.vmdk -> vm-name.vmdk
then you need to modify "vm-name-000001.vmdk", and set the "parentCID" to the "CID" found in "vm-name.vmdk". The "parentFileNameHint" should already be correct.

After fixing the snapshot chain, you need to edit the VM's .vmx file, so that the virtual disk name points to "vm-name-000001.vmdk" (the latest snapshot in the chain). After that reload the VM (see steps 2 and 3 in https://kb.vmware.com/s/article/1026043)

Since the VM has been powered on from the base (flat) file, you may experience some data corruption/loss due to the modifications in the flat file, so what I recommend is that you take another snapshot before you power on the VM again.

If you are unsure, please ask before making any modifications!

André

 

 

[casaub]

Before following https://kb.vmware.com/s/article/1002511 we made a copy of the entire VM folder. So we can begin at the moment where that VM could not be started after rebooting the ESXi host.

The files at that moment were:

vm-name-000001-sesparse.vmdk
vm-name-000002-sesparse.vmdk
vm-name-flat.vmdk
vm-name.vmsd
vm-name.vmx
vm-name.vmxf
vmware-1.log
vmware-2.log
vmware.log

 

The vmdk file we created (following article 1002511) contains this:

 

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 1073741824 VMFS "vm-name-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "66837"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "8b5a2dd545afcc18ea746813fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 9a 00 60 0d 03-99 83 ef bf ef 4c ad 24"
ddb.virtualHWVersion = "14"

 

 

In order to avoid getting data corruption/loss we would make a copy of these (copied) files first before proceeding.

 

What would be the next step thereafter?

You mentioned modifying "vm-name-000001.vmdk"; the file "vm-name-000001-sesparse.vmdk" is approx. 3 GB in size. Modifying it does not sound easy. Understand to download it first, then edit it in an text editor:

find and set the "parentCID" to the "CID" found in "vm-name.vmdk", which would be  fffffffe.

 

Editing it on the ESXi host using the "vi" editor leads to:
vi: out of memory (VMFS3.MaxHeapSizeMB can just be set to max 256 MB).

Are there other tools for modifying a 3 GB big "vm-name-000001.-sesparse.vmdk"?


As I understand, it is not necessary to create the vm-name.vmdk file again (we can use the created vm-name.vmdk), is that correct?

[a_p_]

It's not the sesparse files that need to be edited. Each virtual disk/snapshot is comprised of 2 .vmdk files, a small descriptor file (the one without flat, delta, or sesparse in its name) and the large data file.
What needs to be don in your case is to not only recreate the descriptor for the flat file, but also those for the snapshot (sesparse) files.

To be sure that's done correctly, please provide the output of ls -lisa *.vmdk (from the VM's folder), and let me know which .vmdk file is the current one, i.e. the one that's shown in the original .vmx file.
You can of course post the results with a renamed file names. However, if you post the real file names, I can provide you with the required descriptor files.

André

[casaub]

The sesparse files are vmdk files, that's why it is irritating.

ls -lisa *.vmdk
4195332 2544640 -rw------- 1 root root 2605056000 Jan 7 08:10 vm-name-000001-sesparse.vmdk
8389636 14204928 -rw------- 1 root root 14545326080 Jan 7 08:10 vm-name-000002-sesparse.vmdk
1028 536870912 -rw------- 1 root root 549755813888 Jan 7 08:09 vm-name-flat.vmdk
50332676 0 -rw------- 1 root root 477 Jan 7 12:39 vm-name.vmdk

Thought also of creating vmdk files for the sesparse ones but since these are vmdk's already this would not make sense. These are created now. But CID and parentCID are identical in all three descriptor-vmdk's (vm-name.vmdk, vm-name-000001.vmdk and vm-name-000002.vmdk):

cat vm-name-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 5088000 VMFS "vm-name-000001-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "316"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "0cc9a67d87dfa7cf4ddbb13dfffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 9f 12 90 22 d6-a7 67 0a 30 90 bd d6 72"
ddb.virtualHWVersion = "14"

------------------------------------------------------------

cat vm-name-000002.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 28408840 VMFS "vm-name-000002-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "1768"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "3f04beb388ac1c768496bc44fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 99 b8 6d 4d 17-0f 43 1a d6 89 f2 7a 81"
ddb.virtualHWVersion = "14"

------------------------------------------------------------

cat vm-name.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 1073741824 VMFS "vm-name-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "66837"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "b999862163694f825b92aec7fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 94 74 b7 4b 34-80 59 c7 b4 a6 b9 d8 84"
ddb.virtualHWVersion = "14"

[a_p_]

>> ... and let me know which .vmdk file is the current one, i.e. the one that's shown in the original .vmx file.

Likely due to copying the file,both sesparse files have the same time stamp. It's important to know the correct chain, i.e. which one of these two files if the newer one.

André

[casaub]

correct output

ls -lisa *.vmdk
4195332 2544640 -rw------- 1 root root 2605056000 Jan 7 08:10 vm-name-000001-sesparse.vmdk
58721284 0 -rw------- 1 root root 483 Jan 7 13:29 vm-name-000001.vmdk
8389636 14204928 -rw------- 1 root root 14545326080 Jan 7 08:10 vm-name-000002-sesparse.vmdk
67109892 0 -rw------- 1 root root 485 Jan 7 13:33 vm-name-000002.vmdk
1028 536870912 -rw------- 1 root root 549755813888 Jan 7 08:09 vm-name-flat.vmdk
50332676 0 -rw------- 1 root root 477 Jan 7 12:39 vm-name.vmdk

The three descriptor vmdk files were created separately, not copied. Similar time stamps are the result of a backup copy of the entire VM from one folder to another inside the datastore.

The vmx file is showing:

[...]
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "vm-name.vmdk"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
scsi0:0.present = "TRUE"
[...]

[casaub]

Found another article (https://kb.vmware.com/s/article/1026353) which describes the creating of sparse-vmdk's. So after that this is how the vmdk's look like:

cat vm-name.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 1073741824 VMFS "vm-name-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "66837"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "b999862163694f825b92aec7fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 94 74 b7 4b 34-80 59 c7 b4 a6 b9 d8 84"
ddb.virtualHWVersion = "14"

------------------------------------------------------------

cat vm-name-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfsSparse"
parentFileNameHint="vm-name.vmdk"

# Extent description
RW 5088000 VMFSSPARSE "vm-name-000001-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "b999862163694f825b92aec7fffffffe"

------------------------------------------------------------

cat vm-name-000002.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfsSparse"
parentFileNameHint="vm-name.vmdk"

# Extent description
RW 28408840 VMFSSPARSE "vm-name-000002-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "b999862163694f825b92aec7fffffffe"

[a_p_]

After posting my latest reply, I saw yours.

The files that you've create won't work! These are for older ESXi versions, and also contain errors.

André

[casaub]

We were using this article when creating the other vmdk's:
https://kb.vmware.com/s/article/1026353

Which is for ESXi versions < 6.x. But was not able to find an article which is for ESXi 6.x and up.

 

The files you were sharing fixed it. Thank you very much, excellent.

[a_p_]

The descriptor files for flat, and sesparse file do not have the same contents.
I've attached a .zip archive with sample files. After renaming the files, and the content ("vm name" to the VM's real name), you can upload them to the VM's folder on the datastore.

Steps are:

1. rename, and edit the attached descriptor files (or create your own ones)
2. upload the descriptor files to the VM's folder on the datastore
3. edit the VM's .vmx file and set: scsi0:0.fileName = "vm-name-000002.vmdk"
4. reload the VM by following steps 2, and 3 from https://kb.vmware.com/s/article/1026043

Important:
With the attached files, I assume that the current snapshot is "vm-name-000002.vmdk".
To ensure that the current files will not get modified, please create another snapshot before powering on the VM!!!

André

Attachment(s)

vm-name.zip   1 KB 1 version

[paradigmqc]

Hi, we have the same exact problem at the moment. Vmware told me there is nothing to do since I mounte the base drive from the vm.

 

Hope your solution will work !!!

[a_p_]

If you want me to take a look at your specific situation, then please open a new discussion and provide some details, like the output of ls -lisa for a list of files in the VM's folder, the existing (small) .vmdk descriptor files, and maybe what happend that may have cased the issue.

André

[paradigmqc]

Oh wow, I love you so much ! 

 

I will do André !!!