Unable to read partition - LOCAL storage

[colindunn]

I am trying to add a 1.64TB RAID-5 array to a VMware ESXi 3.5u4 host as local storage (directly attached via a SCSI RAID controller).

When doing so, I get an "unable to read partition information from the disk" error, and the "add storage" wizard does not allow me to proceed.

I tried logging on to the unsupported shell prompt and running the Linux fdisk utility to create a fresh MS-DOS format partition table on the 1.64TB logical drive. Still no luck.

Then I tried creating a 1.64TB Linux ext3fs partition (with the idea I would then overwrite it). Still no luck.

What else should I try to get this disk recognized in ESXi 3.5u4?

[kjb007]

The partition type needs to be 'fb' for vmfs. Then, after that has been created, you need to run 'vmkfstools -C vmfs /vmfs/devices/disks/vmhba0:0:0:x' where x is the partition to create the new vmfs filesystem on. Then, go back and rescan.

-KjB

VMware vExpert

[colindunn]

Getting closer, but still not there.

When I do the vmkfstools command (vmkfstools -C vmfs /vmfs/devices/disks/vmhba1:0:0:1), I get an error: "Error: Bad file descriptor."

This is with a DOS-compatible partition table set up and one primary partition of type 0xfb created.

Other thoughts?

[colindunn]

I also tried the above with the path pointing to vmhba1:0:0:0, since the "LUN" number of the 1.64TB array (7x280GB RAID-5) is 0, resulting in a canonical path of vmhba1:0:0:0.

Same results - unable to read the partition table, even when I use fdisk to create a new, DOS-compatible table.

Since the array is <2TB, there shouldn't be an issues with using a DOS-compatible partition table - right???

The storage controller is a Dell PERC4e/DC. It appears in ESXi as an LSI Logic MegaRAID controller. I am running ESXi 3.5u4 with the Dell management components. The server is a Dell PowerEdge 2950.

[kjb007]

You can not use 0 as the final number. That 0 would represent the entire disk. The final 0 should be your partition, the the canonical path is hba:target:lun:partition, so it should be vmhba1:0:0:5, or something similar to that. Post the output of fdisk -l for help with that.

Your array is fairly large. Do you need to keep your partition at 1.6+ TB? I would break it up into smaller partitions. You will also have to modify the vmkfstools command slightly to fit the size of the partition you will be creating. If you use the default, which is 1 MB, then the maximum size file or vmdk you can create is 256 GB, 2 MB = 512GB, 4 MB=1 TB, and 8 MB = 2 TB. You can change the block size by using the -b Xm.

-KjB

VMware vExpert

[colindunn]

This time, I targeted the fdisk utility to vmhba1:0:0:0 and created two ~800GB partitions, resulting in vmhba1:0:0:1 and vmhba1:0:0:2.

If I rescan the adapter, it still only shows the overall disk (vmhba1:0:0:0).

Trying the vmkfstools command still results in a "bad file descriptor" error. See console output below.

~ # fdisk -l

Disk /dev/disks/vmhba1:0:0:0: 1799.8 GB, 1799859732480 bytes

255 heads, 63 sectors/track, 218820 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba1:0:0:1 1 109409 878827761 fb VMFS

/dev/disks/vmhba1:0:0:2 109410 218820 878843857+ fb VMFS

Disk /dev/disks/vmhba0:0:0:0: 146.1 GB, 146163105792 bytes

64 heads, 32 sectors/track, 139392 cylinders

Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba0:0:0:1 5 750 763904 5 Extended

/dev/disks/vmhba0:0:0:2 751 4845 4193280 6 FAT16

/dev/disks/vmhba0:0:0:3 4846 139392 137776128 fb VMFS

/dev/disks/vmhba0:0:0:4 * 1 4 4080 4 FAT16 <32M

/dev/disks/vmhba0:0:0:5 5 52 49136 6 FAT16

/dev/disks/vmhba0:0:0:6 53 100 49136 6 FAT16

/dev/disks/vmhba0:0:0:7 101 210 112624 fc VMKcore

/dev/disks/vmhba0:0:0:8 211 750 552944 6 FAT16

Partition table entries are not in disk order

~ # vmkfstools -C vmfs3 /vmfs/devices/disks/vmhba1:0:0:1

Creating vmfs3 file system on "vmhba1:0:0:1" with blockSize 1048576 and volume label "none".

Usage: vmkfstools -C vmfs3 /vmfs/devices/disks/vmhbaW:X:Y:Z

Error: Bad file descriptor

~ # vmkfstools -C vmfs3 /vmfs/devices/disks/vmhba1:0:0:2

Creating vmfs3 file system on "vmhba1:0:0:2" with blockSize 1048576 and volume label "none".

Usage: vmkfstools -C vmfs3 /vmfs/devices/disks/vmhbaW:X:Y:Z

Error: Bad file descriptor

[kjb007]

fdisk shows your partition created successfully, but I'm not sure it was created successfully. Looks like you may need a 3rd party utility, such as a linux livecd, or a vendor's disk partition utility instead of fdisk.

-KjB

VMware vExpert

[virtuon]

Check your SCSI controller in HAL list , i also faced similer problem

[colindunn]

The PERC4e/DC controller I am using is on the HCL.

I tried re-creating the array and still no luck. I noticed that when I first logged on, it was an EFI/GPT partition table. So I used fdisk to enable DOS-compatibility mode and create a DOS partition table. Still no luck.

See console output below for what I did.

Other thoughts???

~ # fdisk -l

Disk /dev/disks/vmhba1:0:0:0: 1799.8 GB, 1799859732480 bytes

255 heads, 63 sectors/track, 218820 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba1:0:0:1 1 18446744073709503089 18446744073319743488+ ee EFI GPT

Disk /dev/disks/vmhba0:0:0:0: 146.1 GB, 146163105792 bytes

64 heads, 32 sectors/track, 139392 cylinders

Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba0:0:0:1 5 750 763904 5 Extended

/dev/disks/vmhba0:0:0:2 751 4845 4193280 6 FAT16

/dev/disks/vmhba0:0:0:3 4846 139392 137776128 fb VMFS

/dev/disks/vmhba0:0:0:4 * 1 4 4080 4 FAT16 <32M

/dev/disks/vmhba0:0:0:5 5 52 49136 6 FAT16

/dev/disks/vmhba0:0:0:6 53 100 49136 6 FAT16

/dev/disks/vmhba0:0:0:7 101 210 112624 fc VMKcore

/dev/disks/vmhba0:0:0:8 211 750 552944 6 FAT16

Partition table entries are not in disk order

~ # fdisk /dev/disks/vmhba1:0:0:1

Unable to open /dev/disks/vmhba1:0:0:1

~ # fdisk /dev/disks/vmhba1:0:0:0

The number of cylinders for this disk is set to 218820.

There is nothing wrong with that, but this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/disks/vmhba1:0:0:0: 1799.8 GB, 1799859732480 bytes

255 heads, 63 sectors/track, 218820 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba1:0:0:1 1 18446744073709503089 18446744073319743488+ ee EFI GPT

Command (m for help): m

Command action

a toggle a bootable flag

b edit bsd disklabel

c toggle the dos compatibility flag

d delete a partition

l list known partition types

m print this menu

n add a new partition

o create a new empty DOS partition table

p print the partition table

q quit without saving changes

s create a new empty Sun disklabel

t change a partition's system id

u change display/entry units

v verify the partition table

w write table to disk and exit

x extra functionality (experts only)

Command (m for help): c

DOS Compatibility flag is not set

Command (m for help): c

DOS Compatibility flag is set

Command (m for help): o

Building a new DOS disklabel. Changes will remain in memory only,

until you decide to write them. After that, of course, the previous

content won't be recoverable.

The number of cylinders for this disk is set to 218820.

There is nothing wrong with that, but this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

(e.g., DOS FDISK, OS/2 FDISK)

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

~ # fdisk -l

Disk /dev/disks/vmhba1:0:0:0: 1799.8 GB, 1799859732480 bytes

255 heads, 63 sectors/track, 218820 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Disk /dev/disks/vmhba0:0:0:0: 146.1 GB, 146163105792 bytes

64 heads, 32 sectors/track, 139392 cylinders

Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba0:0:0:1 5 750 763904 5 Extended

/dev/disks/vmhba0:0:0:2 751 4845 4193280 6 FAT16

/dev/disks/vmhba0:0:0:3 4846 139392 137776128 fb VMFS

/dev/disks/vmhba0:0:0:4 * 1 4 4080 4 FAT16 <32M

/dev/disks/vmhba0:0:0:5 5 52 49136 6 FAT16

/dev/disks/vmhba0:0:0:6 53 100 49136 6 FAT16

/dev/disks/vmhba0:0:0:7 101 210 112624 fc VMKcore

/dev/disks/vmhba0:0:0:8 211 750 552944 6 FAT16

Partition table entries are not in disk order

~ # fdisk -l

Disk /dev/disks/vmhba1:0:0:0: 1799.8 GB, 1799859732480 bytes

255 heads, 63 sectors/track, 218820 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Disk /dev/disks/vmhba0:0:0:0: 146.1 GB, 146163105792 bytes

64 heads, 32 sectors/track, 139392 cylinders

Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

/dev/disks/vmhba0:0:0:1 5 750 763904 5 Extended

/dev/disks/vmhba0:0:0:2 751 4845 4193280 6 FAT16

/dev/disks/vmhba0:0:0:3 4846 139392 137776128 fb VMFS

/dev/disks/vmhba0:0:0:4 * 1 4 4080 4 FAT16 <32M

/dev/disks/vmhba0:0:0:5 5 52 49136 6 FAT16

/dev/disks/vmhba0:0:0:6 53 100 49136 6 FAT16

/dev/disks/vmhba0:0:0:7 101 210 112624 fc VMKcore

/dev/disks/vmhba0:0:0:8 211 750 552944 6 FAT16

Partition table entries are not in disk order

~ #

[colindunn]

One more interesting thing -

I removed the entire 1.64TB array and created two smaller RAID arrays, of 838GB and 558GB respectively.

Once I did this, I had no problem creating / partitioning VMFS using the ESXi GUI.

I thought the DOS partition table standard supported disks of up to 2TB. Is that a true 2TB, or 2.0 trillion bytes (which may actually be less than 1.64 true TB)?

So it appears my issues have been due to exceeding a size limit - either of DOS partition table, or cylinders/heads/sectors.

Creating the two smaller arrays results in one more disk lost to parity than having a single RAID-5. I get about 1.3TB of usable capacity.

So if there's a way I could get the 1.64TB (7x286 GB RAID-5) configuration to work, that would be preferable.

[kjb007]

One thing to note is that my working environments do not have the dos compatiblityflag set on any of them. I also am using a RAID5 set that is larger than the one you are trying to create. It should work.

-KjB

VMware vExpert

[colindunn]

I did some more experimentation. A 6x286GB RAID-5 (1.36TB usable) gave me the same partition table error.

A 5x286GB RAID-5 (1.09TB usable) worked without issues, just like the 4-drive (850GB) and 3-drive (550GB) arrays.

So it appears that somewhere between 1.09TB and 1.36TB I am exceeding a limit. Still not sure what it is, since the DOS partition table is supposed to work for disks up to 2TB. I suspect it's something about the CHS mapping of the controller exceeding some other limit.

[kjb007]

Strange. Below is the output of 5x750 gb drives. Partitioning works just fine, but I am using ESX in this case and not ESXi.

Disk /dev/sda: 2199.0 GB, 2199023254528 bytes

64 heads, 32 sectors/track, 2097151 cylinders, total 4294967294 sectors

Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System

/dev/sda1 * 32 204799 102384 83 Linux

/dev/sda2 204800 51404799 25600000 83 Linux

/dev/sda3 51404800 63692799 6144000 83 Linux

/dev/sda4 63692800 -2049 2115636224 f Win95 Ext'd (LBA)

/dev/sda5 63692832 66969599 1638384 82 Linux swap

/dev/sda6 66969632 67174399 102384 fc Unknown

/dev/sda7 67174432 1043738623 488282096 fb Unknown

/dev/sda8 1043738656 -2049 1625613296 fb Unknown

-KjB

VMware vExpert