Hi,
You are saying that when you choose add storage wizard, it will only lets you to delete them - does it means the ESX hosts recognized the LUN as if it is a new LUN? (has not been formatted to VMFS)
Make sure you documented the 4 extents/LUN/LUN# so you can double check with the storage.
Do you remember where did you build the extents?
From vCenter or from a specific hosts?
Try rescanning from different hosts, see if other ESX can see the complete datastore with 4 extents.
See below posts:
VMFS Extents - Are they bad, or simply misunderstood? | VMware vSphere Blog - VMware Blogs
Misconception #2 – Losing one extent will offline the whole volume
...if the head extent (1st member) has a failure, then it can bring the whole datastore offline.
Head extent offline condition is pretty much always going to cause failures because many of the address resolution resources are on the head extent.
Additionally, if a non-head extent member goes down, you won’t be able to access the VMs whose virtual disks have at least 1 block on that extent.
Misconception #3 – Its easy to mistakenly overwrite extents in vCenter
...the scenario described is where vCenter shows LUNs (which are already used as an extents for a VMFS datastores) as free, and will let you initialize them when you do an Add Storage task.
...
I think this occurred when you built an extent on one host, and then flipped onto a view from another ESXi host which didn’t know that the LUN was now in use.
These days, any changes made to a datastore, where a LUN is added as an extent, updates all the inventory objects so that this LUN is removed from the available disks pool.
Coupled with the fact that we now have a cluster wide rescan option for storage, there should no longer be any concerns around this.
Obviously, if you decide to start working outside of vCenter and decide to work directly on the ESXi hosts, you could still run into this issue. But you wouldn’t do that, would you?
Nice vmkfstools feature for Extents | VMware vSphere Blog - VMware Blogs
Thanks,
Bayu