VMware Cloud Community
prcatk
Contributor
Contributor

Datastore not available. Lun ok, Partition issue

All,

After a consecutive set of drive failures on a RAID-5 disk ( Dell 2970, Perc 6/i) forced drive replacements- the RAID-5 has finished it's rebuild and there is a single Lun that appears in the Storage Adapters list but has disappeared from the Storage volumes list.

The log indicates an error with the partition table:

Jul 26 17:34:24 Hostd: [2013-07-26 17:34:24.681 'Partitionsvc' 16384 info] Error Stream from partedUtil while getting partitions: Error: The partition table on /dev/disks/vml.02000000006001ec90f77b73001163b08e1403e788504552432036 is inconsistent.  There are many reasons why this might be the case.  However, the most likely reason is that Linux detected the BIOS geometry for /dev/disks/vml.02000000006001ec90f77b73001163b08e1403e788504552432036 incorrectly.  GNU Parted suspects the real geometry should be 25000/64/32 (not 3187/255/63).  You should check with your BIOS first, as this may not be correct.  You can inform Linux by adding the parameter disks/vml.02000000006001ec90f77b73001163b08e1403e788504552432036=25000,64,32 to the command line.  See the LILO or GRUB documentation for more information.  If you think Parted's suggested geometry is correct, you may select Ignore to continue (and fix Linux later).  Otherwise, select Cancel (and fix Linux and/or the BIOS now).

There are a multitude of VM's on this data-store that I would like to retrieve intact. The question is exactly how to do this. I have read the KB(1002281) about rebuilding a partition table and am prepared to execute this but I'm curious if there is any other "recovery" tricks that can resolve the issue.

Environment- Dell 2970, RAID-5  missing a single volume data store ( 1.4TB in size) all other data storage on the "failed" RAID-5 recovered correctly.

ESX Server 3i Version 3.5.0 Build 283373

Thanks for any help/advice.

Tags (3)
0 Kudos
1 Reply
prcatk
Contributor
Contributor

More information-

After using fdisk to try and rebuild the partition table( as shown in KB 1002281) the inconsistent error message is still appearing. The fdisk command "v" to verify the partition indicates an error in the disk size vs. the table entries ( I used the recommended values from the KB start= 128, default the size).

The interesting item is the CHS values in the partedUtil error message DO NOT match what fdisk "thinks" the disk is.

fdisk- reports the disk as: 255/63/179327.

Any suggestions on getting a partition table that "works"

here is what the /sbin/partedUtil shows:

~# /sbin/partedUtil get /dev/disks/vmhba1:5:0:0

Geometry Known: 0

179327 255 63 2880897024

1 128 2880897023 251 0

~ # /sbin/partedUtil get /dev/disks/vmhba1:5:0:1

179327 255 63 2880896896

~ #

Question: what process creates the /dev/disks/vmhba1:5:0:1  entry? It looks like that entry is mismatched with the "real" partition table.

Thanks.

0 Kudos