I have a spanned datastore volume that is comprised of 4 extents and I suffered a disk array failure that forced me to re-import the disk volume on a very old PERC 5/I disk controller. I was able to recover the original disk array, but it was assigned a new disk NAA number which is causing the VMFS-5 datastore not to recognize it. I am not sure what tools to use to update the datastore to replace the OLD NAA disk with the new NAA disk to provide for the missing extent.
[root@Pegasus:~] vmkfstools -Ph /vmfs/volumes/datastore1\ \(1\)/
VMFS-5.54 file system spanning 4 partitions.
File system label (if any): datastore1 (1)
Mode: public
Capacity 7.3 TB, 917.9 GB available, file block size 1 MB, max supported file size 62.9 TB
UUID: 51f563b0-25ee3451-895e-00188b440eff
Partitions spanned (on "lvm"):
naa.600188b0436047001987f1834fc6754b:3
naa.600188b0436047001987f1dce0ed5c8c:1
(device naa.600188b0436047001987f219956c8e6e:1 might be offline)
naa.600188b04360470019997bb04b041de4:1
(One or more partitions spanned by this volume may be offline)
Is Native Snapshot Capable: YES
The drive that contains an extent "naa.600188b0436047001987f219956c8e6e:1" is the old disk array and the new disk array was assigned in as "naa.600188b043604700256a4374a7dd9376:1".
What are the steps to update the datastore to replace the old NAA disk with the new NAA disk?
Plan A:
resignature .... you very likely already tried that
Plan B:
extract data ...
this requires that the parent datastore is healthy. Lots of manual work necessary
Plan C: highly experimental - I only try this if everything else failed
Hexedit the VMFS header of the parent and the extent datastores.
Experimental because the format of the extent headers is undocumented and I usually follow plan B
Moderator: Moved to vSphere Storage
After checking the VMFS headerdump it looks like plan B should work. It will be quite time-consuming to create dd scripts for the 35 vmdks but it should work.
Next we will do a remote session and check our options in detail.