posted

14 Comments

By now, regular readers of this blog will be aware that VMFS-5 supports a single extent volume size of 64TB. In an earlier post, I mentioned that newly created VMFS-5 partitions use a GUID Partition Format, GPT. This partition format allows for the creation of large partition sizes to cater for the new single extent 64TB VMFS-5 volume.

But what about VMFS-3 volumes, which were created with the MBR (Master Boot Record) format, and are subsequently upgraded to VMFS-5? MBR has a maximum partition size of ~ 2TB, so does this mean that VMFS-3 filesystems upgraded to VMFS-5 are still limited by this partition format? The answer is no. The partition format will change automatically & seamlessly from MBR to GPT when the size of the upgrade VMFS-5 volume is grown above the 2TB threshold. This change can also occur when the VMFS-5 has VMs powered on and running. The change-over to the new partition type is non-disruptive. I've alluded to this in previous posts. In this post I wanted to show you a little more detail.

Let's have a closer look: In this example, I have a LUN presented to my ESX. The LUN is 3TB in size as is presented from a NetApp FAS 3170A over FCoE. I will now create a 2TB VMFS-3 volume on it, with 1TB of unused space remaining on the LUN. Note that the partition table is MBR.

Vmfs-3 creation
Note that because the partition format is MBR, we can continue to use fdisk in the CLI to examine this disk:

Fdisk
The next steps are to upgrade this volume to VMFS-5, and then grow the volume above the 2TB threshold. Once these steps are initiated, we will observe the automatic switching of the partition format from MBR to GPT.

Here is the view of this volume before the upgrade:

Vmfs-3-before

Just above the Datastore Details, on the right hand side, there is the option to Upgrade to VMFS-5. This is another cool feature and allows you to do an online non-disruptive upgrade of a VMFS-3 volume to VMFS-5. Click this option, and the following message is displayed:

Upgrade-to-vmfs-5

Once the upgrade has completed, we can now see the properties of the datastore reflect that it is now a VMFS-5 volume:

Vmfs-5-after
But the point is that this disk, although it now has a VMFS-5 volume on it, continues to use MBR. It is only when this volume is grown above 2TB that the partition format changes to GPT. Let's do that next.

The LUN that we presented from the NetApp is 3TB in size, although we only used 2TB when we initially built the VMFS-3 volume. We will use that 1TB of free space to grow the volume to 3TB:

2tb-vol
Once the online grow operation has been completed, the VMFS-5 volume (upgraded from VMFS-3) should now show a new size of 3TB:

3tb-volume
Let's now look at the partition format using the fdisk command at the CLI:

Fdisk-failure
Ah, this is interesting. fdisk no longer works on this disk. The partition format is no longer MBR, but as the fdisk command states, it has found a valid GPT. VMware prevents fdisk from being used on GPT to prevent customers inadvertently damaging the GPT partition table. As the message states, we should now be using partedUtil to query GPT disks. Let's do that:

Partedutil

Now our 3TB VMFS-5 volume is using GPT, and have seamlessly switched to this new format. The only thing we did was grow the volume above 2TB. Everything was taken care of automatically. And the point is that this can be done online and non-disruptively, even with VMs running on the datastore.

To learn more about VMFS-5 features, take a look at this earlier posting from around the time of the vSphere 5.0 launch.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage