"Regarding your earlier question about what I did: I created a dummy VM with the exact same disk size as the original disk. Then, I edited the vmdk file descriptors to point to the original vmdk files. I also edited the attributes of the original files to point to these dummy files. You suggested this process in one of your messages in 2017"
Yes, this was plan B but it should work so we should check exactly what you did to ensure it is correct - can you send the link of the Communities thread you are referencing?
You mentioned "I tried create a new directory and change file path attribute to point in that directory but directory remains empty."
The new directory should just be the namespace of the donor-VM you created, what do you mean this is empty?
Can you attach (or PM me if don't want to share online) the donor-VM vmdk descriptors, objtool getAttr output of the original vmdk objects and the debug object list output of the 3 vmdks? ('Docker Server 2.0.vmdk', 'Docker Server 2.0-000001.vmdk' and 'Docker Server 2.0_1.vmdk')
e.g.:
# esxcli vsan debug object list --all > /tmp/objout
# less /tmp/objout
Then type 'Esc', '/', '12cf' to go to the first object, copy the full output of it's entry then press 'n' to go to next one and do the same for all 3 vmdk objects.
This will give you the object UUIDs of the 3 vmdk objects ('Docker Server 2.0.vmdk', 'Docker Server 2.0-000001.vmdk' and 'Docker Server 2.0_1.vmdk'), do a lookup of these from any node in the cluster and save the output:
# /usr/lib/vmware/osfs/bin/objtool getAttr -u UUIDGoesHere
cd to the namespace directory of the donor-VM and cat each of the 3 replacement vmdk descriptors you should have and save the output.
Just to re-iterate the correct steps for doing this:
1. Identify the object UUIDs and sizes (SIZE not USED space) from esxcli vsan debug object list for all vmdks belonging to the VM (including snapshots).
2. Create a donor-VM for ease of creating vmdk descriptors (this can be done manually or via other means but this is simplest), this should have the same number of disks as base-vmdks and they should be the exact same size as shown in debug object list. You only have a single snapshot on one of the disks but not the other here - this can have a descriptor created for just it (but not the other disk) by detaching the vmdk that doesn't have a snapshot then 'take snapshot' of the VM and then re-add the other disk. Generally one can guess by size which is the boot vmdk and thus which should be attached to vscsi0:0 .
3. Go to the namespace of the donor-VM and edit each of the vmdks using vi, replacing the object UUID (which currently point to empty new objects which can be later deleted) with the original vmdk object UUID e.g. if object UUID is 'a1c26155-5678-1012-a1fb-ecf4bbcfca20' in the vmdk you would replace 'a5c26155-1234-b111-bc9c-ecf4bbcfca20' with 'a1c26155-5678-1012-a1fb-ecf4bbcfca20' in this line of the vmdk:
RW 46800640 VMFS "vsan://a5c26155-1234-b111-bc9c-ecf4bbcfca20"
4. The original objects are still trying to be resolved at their original vmdk location, this needs to be changed to the new vmdks in the new namespace location of the donor-VM, this should be done for each vmdk object using:
# /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-5678-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.