Disk array failure and recovery leave Spanned datastore degraded and unusable.

[tjsampair]

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?

[continuum]

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

[Scott Vessey]

Moderator: Moved to vSphere Storage

[continuum]

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.