VMDK creation or expansion beyond 15.8 TB fails on NFS datastore

Products

VMware vSphere ESXi

Issue/Introduction

When attempting to provision a new virtual machine disk (.vmdk) or expand an existing virtual disk beyond 15.8 TB (or 16 TiB) on a shared Network File System (NFS) datastore—such as Azure NetApp Files (ANF) the task fails instantly.

The environment generates the following explicit indicators:

vSphere Client UI Error: Error creating disk: The destination file system does not support large files
Host Daemon Log Entries (/var/log/hostd.log):

Hostd[214993334]: sub=Libs DiskLibIsCapacitySupported: Unsupported disk capacity 27487790694400 bytes. Allowed disk capacity 17383785916071 bytes. Filename: /vmfs/volumes/#####/VM_NAME/VM_NAME.vmdk.

Hostd[214993334]: sub=Vmsvc.VmDiskMgr For disk [ANF_NFS_Datastore] VM_NAME/VM_NAME.vmdk, Error creating disk: The destination file system does not support large files

Hostd[214993334]: sub=Vmsvc.vm:/vmfs/volumes/#####/VM_NAME/VM_NAME.vmx Reconfigure failed: N3Vim5Fault12FileTooLarge9ExceptionE(Fault cause: vim.fault.FileTooLarge)

Virtual Machine Runtime Log Entries (vmware.log):

vmx - HotExtend: Extending scsi0:3 to 53687091200

worker-226083537 - DISKLIB-LIB : Pre-growing disk '/vmfs/volumes/#####/VM_NAME/VM_NAME.vmdk': new capacity = 53687091200 sectors - 25 TB

worker-226083537 - DiskLibIsCapacitySupported: Unsupported disk capacity 27487790694400 bytes. Allowed disk capacity 17383785916071 bytes.

worker-226083537 - DISKLIB-LIB : Failed to grow disk: The destination file system does not support large files (12).

Environment

VMware vSphere ESXi 7.x, 8.x

Azure NetAapp Files

Cause

This issue occurs because the ESXi host DiskLib enforces a cached 16 TiB file size limit established during the initial NFS mount, even if the backend storage (e.g., Azure NetApp Files) has been expanded to support larger files.

Underlying Architecture Mechanics:

The Handshake Lock: When an NFS datastore is mounted to an ESXi cluster, the hypervisor queries the backend NAS controller to negotiate maximum file system boundaries.
Legacy Boundaries: If the Azure NetApp Files pool was originally provisioned under a framework that limited individual files to 16 TiB, ESXi logs and caches this value as a hard limit to prevent filesystem metadata corruption.
The Protocol Refresh Blindspot: Modern network storage platforms (like Azure NetApp Files) have evolved to support single-file sizes up to 64 TiB. However, the standard NFS client protocol dictates that max file dimensions are only updated during volume initialization (mounting).
The Exception Trigger: If the backend volume parameters are adjusted on the fly, or if a global cloud platform update expands capacity boundaries while the NFS datastore remains continuously mounted, the ESXi hosts will continue to enforce the legacy 16 TiB restriction in active memory. Any subsequent request to create a massive disk (such as a 25 TB VMDK, which requires 27,487,790,694,400 bytes) will be immediately blocked by the host with a FileTooLarge exception.

Resolution

To unlock the deployment of virtual machine disks larger than 16 TiB, your platform and storage teams must coordinate during an approved maintenance window to adjust the volume parameters and force a client handshake refresh.

Step 1: Expand the Maximum File Size Attribute on the Storage Pool

Collaborate with your cloud service provider or local storage engineers to ensure the backing file system is configured to support large files:

For Azure NetApp Files: Verify that the regular volume size attributes natively support the modern 64 TiB maximum file parameter tier. Ensure no resource group constraints or localized export quotas are overriding the storage pool layout. Please contact Microsoft support.

Step 2: Refresh the ESXi Host Datastore Client Cache via a Controlled Remount

Because ESXi cannot dynamically polling or update runtime file size limits on a live, open file system mount, you must unmount and remount the datastore across the cluster.

In the vSphere Client, navigate to the Storage inventory view.
Select the affected NFS datastore. Identify all virtual machines currently utilizing this storage tier and either migrate them to a separate volume using Storage vMotion or gracefully power them off.
Right-click the datastore and select Unmount Datastore.
Check the box for all ESXi hosts across the cluster that share the mount path, and confirm the unmount wizard.
Once the volume successfully moves to an unattached state, right-click your Datacenter or Cluster object, navigate to Storage, and select New Datastore.
Select NFS, specify the correct protocol version (NFS 3 or NFS 4.1 to match your previous configuration), and provide the identical export path and server IP address. Complete the wizard to mount the datastore back to the cluster.

Step 3: Verify High-Capacity Disk Provisioning

Navigate back to your target virtual machine and open the Edit Settings menu.
Re-attempt the creation or expansion task to your target limit (e.g., 25 TB).
The newly re-initialized DiskLib engine will read the updated volume characteristics, recognize the expanded file allocation ceiling, and provision the massive VMDK seamlessly.