While in older versions of vSphere (5.5 and 6.0), it was impossible to extend VMDK past 2 TB, vSphere 6.5 and 6.7 brought that possibility, even for running VMs. Basically, if you wanted to hot-resize the disk past 2 TB, you received an error after the validation that "a specified parameter was not correct". An admin had to follow up with a vMotion for vSphere 6.5 host to be able to resize a disk and successfully complete the operation on ESXi 6.5 or higher.

Today, we'll have a look at this process with vSphere 7.0. We'll use an HTML5 web client, the new standard for vSphere UI management.

As you know, a raw devise map (RDM) still has a 2 TB size limitation. The actual limit of VMDK on a datastore is 62 TB, which is very big, but if you're looking to virtualize large-scale business-critical applications, vSphere now allows you to do so without any limitations.

The fact that vSphere 6.5 and higher version supports the possibility of extending VMDK disks past 2 TB while the virtual machine (VM) is running is not new. However, there are still some restrictions, and it does not mean that all guest OSs support this.

Now, when Microsoft dropped support for old OSs such as 2003 Server or 2008 Server, all modern systems support it out of the box; however, the device must be initialized by using the GUID partition table (GPT) partitioning scheme.

You can also use more than 2 TB for boot volumes. The volume must not only be initialized by using GPT, but also the system firmware must use UEFI.

The latest versions of VMware vSphere have the ability to go beyond 2 TB while the VM is powered on, which gives you an advantage while running the VM in a production environment.

Requirements for hot-extending VMDK in vSphere 7.0 ^

  • Guest OS support is necessary.
  • VMFS-5 or later; NFS datastore formats are supported.
  • VMware Fault Tolerance (FT) is not supported.
  • Under Windows OS, the disk must be initialized using the GUID partition Table (GPT) partitioning scheme.

Steps for hot-extending the VMDK disk over 2 TB with vSphere 7.0 ^

Log in to your vSphere user interface (UI) and navigate to your virtual machine (VM). Click the Edit Settings icon and expand the virtual disk you want to grow. Change the size of the VMDK by entering the new value you want that disk to have.

Change the size to over 2 TB

Change the size to over 2 TB

Then validate by clicking the OK button. Once again, go back to Edit Settings and check the new size. As you can see, the disk size has been changed without any error.

Size after validation

Size after validation

However, this is only half the operation. We now need to go into the guest OS and resize the disk volume within the OS disk management.

Note that this UI might differ depending on the OS type you're using.

Open a disk management snap-in in Windows Server and select the disk. Right-click it and select Extend Volume.

Follow the assistant and validate the pop-up.

Extending the guest OS disk

Extending the guest OS disk

Your disk should resize the volume and show you the new capacity, as on the screen below.

Hot extending of the VMDK guest OS completed

Hot extending of the VMDK guest OS completed

We didn't receive any error within the UI of vSphere when we changed the size.

Conclusion ^

Make sure you know the guest OS to ensure it supports virtual hard disks larger than 2 TB. To use a larger disk, make sure you use the GUID partition table (GPT) partitioning scheme when you initialize and format the disks. Remember, you cannot use a disk larger than 2 TB if you plan to use VMware fault tolerance (FT) protection for your VM. If your VM has snapshots, be sure to delete them before you extend the disk.

One last piece of advice is to keep enough space on the datastore, since with very large VMs the possibility of changing the datastore is limited if all your datastores have been designed with a smaller capacity.

Potential drawbacks for VMs with large disks include backups or replications. If you have a backup strategy that executes one weekly backup, for example, make sure that your backup window is long enough to allow your backup software to finish its job.

Subscribe to 4sysops newsletter!

The back-end storage array architecture should be considered, and so should data protection and disaster recovery protection. It's definitely not good to have a massive volume and a massive amount of storage per VM if you can't protect that data and recover it during a reasonable time period if required.


Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account