In order to accommodate much larger VMFS-5 single extent (~60TB) filesystems, VMware needed to implement a new partition table standard in vSphere 5.0. Historically, VMware used the MBR (Master Boot Record) partition table, but this limited the size of the partition to 2TB approx. GPT, the GUID Partition Table, overcomes this limitation.
It should be noted that VMFS-3 filesystems built on previous versions of vSphere which are subsequently upgraded to VMFS5 will continue to use MBR while their size remains below 2TB. Once the filesystem is grown above 2TB, the partition table will automatically & seamlessly be switched to GPT, even if it has running VMs (which is kind of cool).
Newly created VMFS-5 datastores will automatically use GPT instead of MBR.
GPT includes a protective MBR for security, which typically avoids fdisk displaying a blank disk. However VMware has gone one step further here, and if fdisk is used to query a GPT disk, the ESXi shell fdisk command displays a warning to prevent folks using fdisk to splat a GPT partition table:
~ # fdisk -l Found valid GPT with protective MBR; using GPT
fdisk: Sorry, can't handle GPT partitions, use partedUtil ~ #
partedUtil
So just how are we supposed to examine GPT disks in ESXi 5.0? We need to use a utility called partedUtil. This is included in the ESXi 5.0 shell by the way.
Let's look at a few examples. First, display the partition information from a GPT disk using the get option:
The first line displayed is disk geometry information (cylinders, heads, sectors per track and LBA [Logical Block Address] count). The second line is information about the partitions. There is only 1 partition; it starts at LBA 2048 and ends at LBA 1146719699.That's something else to be aware of – newly created VMFS-5 partitions start at LBA 2048. This is different to previous versions of VMFS:
VMFS-2 created on ESX 2.x; starting LBA 63
VMFS-3 created on ESX 3 & 4; starting LBA 128
VMFS-5 created on ESXi 5; starting LBA 2048
What if you upgrade to VMFS-5? In this case, you maintain the original LBA.
VMFS-3 upgraded to VMFS-5; starting LBA remains at 128
VMFS-2 upgraded to VMFS-3 upgraded to VMFS-5; starting LBA remains at 63
Let's use another option to get additional information (let's use getptbl instead of get):
Some additional information. Lets look at the fields being displayed…
Line #1: Partition Type – gpt Line #2: Disk format – 71380 cylinders, 255 heads, 63 sectors per track, 1146734896 LBAs. Line #3: Partition Information – First partition, offset 2048, Last LBA is 1146719699, ID of partition, type is VMFS.
Why is the number of LBAs in the disk parameters field greater than the number of LBAs in the VMFS partition?
The reason is that VMFS partitions finish on a cylinder boundary. Therefore CHS (71380 * 255 * 63) = 1146719700 (0 – 1146719699).
List of relevant GPT partition types
You may observe these partition types on ESXi hosts:
EFI System Partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)
VMFS (AA31E02A-400F-11DB-9590-000C2911D1B8)
vmkcore (9D275380-40AD-11DB-BF97-000C2911D1B8)
Basic Data (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) – e.g. VFAT
For those of you who have relied on fdisk in the past for storage related activited, this is a new utility that you will have to become familiar with in 5.0.
