Problems with missing extents ...

[continuum]

Good news !
Last weekend I found a new approach to handle missing  / lost extents of a VMFS-datastore.
Unfortunately I was not able to fix the headers of the lost extent so that I was not able to re-add the missing extent.
But I was able to successfully extract all vmdks - some of them used Veracrypt encryption and had up to 25000 fragments.
Even the encrypted VMDKs survived.
This approach is quite challenging and time-consuming as all files have to be extracted.
Advantage: this will also work if the VMFS-headers of the lost extent are partially corrupted.
So if you ever run into a similar issues - call me before you give up ....
Ulli

[daphnissov]

continuum​ Very cool. How does one know if they have this condition? Is it in cases where a VMFS datastore has been spanned across more than one extent where any N extents are missing/dead? What are symptoms that this method could be helpful? I'm curious myself hence the questions.

[continuum]

If an extent is missing the datastore can be still mountable but trying to start a VM or cloneing a vmdk via vmkfstools will fail.
You should see a message in the vmkernel.log that will have lines like:
extent of datastore went offline
or cant mount datastore - reason: extent XY is missing
Basically this is an issue that you can not overlook.
If you have a missing / lost extent you will hear about it very soon.
In this recent  case the parent extent - (that looks like a regular VMFS-volumes and has the regular hidden *.sf files if you check with ls -lah) - had a single I/O error and one of the 3 extents had a bad VMFS-header.
Generally speaking extents are the worst option to enlarge a VMFS-volume.
If just a single one fails - for most users everything would be lost.
So thats worse than a RAID 0