Reverse engineer vSAN backingobjectid after vmdk file corruption

[Max Thurner]

I have been looking into rebuilding my vmdk descriptor files following the below KB:
VMDK File Is Missing on Virtual Volumes Datastore 

My problem is that the vm is missing the backingobjectid.

that said I know that the yellow highlighted part is referenced in the ending part of the backingobjectid but no idea how the rest of it is created.
Does anyone have an idea how the backingobjectid gets composed in vSAN and how it can be reverse engineered if missing?

Any help is much appreciated!!

[Geogee]

If you need the vSAN object ID, then you can try to use the commandline from any ESXi host, which is part of vSAN cluster:
esxcli vsan debug object list
There you can find the "File name.vmdk" and with that you can find UUID for creation the descriptor. 

[TheBobkin]

@Max Thurner

Can you provide more background information of what you meant by "vmdk file corruption"? Is the namespace object (where the .vmx and .vmdk descriptors are stored) inaccessible or some other issue making the .vmdk descriptor(s) unusable?
 
Step 1. is to validate the backing .vmdk objects are accessible, you can use what @Geogee said but need to generate the full list ('esxcli vsan debug object list' will only generate the first 100 objects, use 'esxcli vsan debug object list --all' instead, helpful to output this to a file e.g. using 'esxcli vsan debug object list --all > /tmp/objout123' and then open the file with 'less' command).

Assuming the backing vmdk objects are accessible then can use the information generated from the above command to get the 2 bits of information needed to recreate the .vmdk descriptors: 1. the 'Size' of the object (this is the provisioned size in GiB and doesnn't account for FTT=1, you don't need to be concerned with that, this is the Size of the disk from the VM perspective) and 2. the 'Object UUID' of the backing object.

While you can manually or using tools/scripts create new .vmdk descriptors, I have never seen anyone (from vSAN team anyway) use the MOB method you mentioned - what I find much simpler is to just use the vSphere UI to do this for you by creating a new VM with the correct number and size disks (or just add new disk of correct size if don't need a new .vmx and namespace object etc.), then you can use that newly created .vmdk descriptor to just point to the backing .vmdk object - this requires 2 things 1. edit the .vmdk so it points to the existing .vmdk 'Object UUID' - in the .vmdk descriptor there is line like below, you would change 'a5c26155-1234-b111-bc9c-ecf4bbcfca12' to the 'Object UUID' (let's say it is a1c26155-1234-1012-a1fb-ecf4bbcfca20) of the object:

RW 46800640 VMFS "vsan:1234abcd56781234-1234abcd56781234/a5c26155-1234-b111-bc9c-ecf4bbcfca12"

Then 2. need to change the lookup path of the original object to point to this newly created .vmdk descriptor path e.g.:
# /usr/lib/vmware/osfs/bin/objtool setAttr -u <Object UUID> -d <Path to VMDK>
e.g.:
# /usr/lib/vmware/osfs/bin/objtool setAttr -u a1c26155-1234-1012-a1fb-ecf4bbcfca20 -d "/vmfs/volumes/vsan:1234abcd56781234-1234abcd56781234/DonorVMNamespaceUUID/Donor-VM.vmdk"

This kb covers most of this and can be used as a reference for most parts https://kb.vmware.com/s/article/70774 .