This article refers to the Barracuda Backup Legacy Release firmware or newer, and VMware ESX/ESXi 4.0 and higher with the VMware license which includes access to vSphere Data Recovery API.
Use the steps in this article to resolve the error "VMDK is larger than the maximum size supported by datastore" encountered when creating an ESX/ESXi virtual machine snapshot.
In the vSphere Client, you may see the error:
File is larger than the maximum size supported by datastore.
In the hosted log file, you may see the error:
Snapshot guest failed: The file is too big for the filesystem.
In the vmware.log file of the virtual machine, you may see an error similar to:
vmx| FILE: File_VMFSSupportsFileSize: Requested file size ( 554051831808) larger than maximum supported filesystem file size (274877906944)
vmx| DiskLibCreateCustom: if your disk is on VMFS, you may consider increasing the block size.
vmx| DISKLIB-LIB : Failed to create link: The destination file system does not support large files (12)
vmx| SNAPSHOT: BranchDisk: Failed to create child disk ' /vmfs/volumes/uuid/vmname/vmname-000001.vmdk' : The destination file system does not support large files (12)
vmx| SNAPSHOT: SnapshotBranch failed: The destination file system does not support large files (5).
vmx| [msg.checkpoint.save.fail2.std3] Error encountered while saving snapshot.
vmx| The destination file system does not support large files.
These errors occur when the snapshot file has exceeded the maximum size to fit in a datastore. Beginning with version 4.0, ESX/ESXi compares the maximum size of a snapshot redolog file to the maximum size of files on the datastore. The redolog file may not work correctly once it reaches the maximum size of the datastore. If the file can grow beyond the maximum size, ESX cancels the Create Snapshot operation and displays the error message: File is larger than the maximum size supported by datastore
Use the following steps to resolve this error.
Step 1. Determine Maximum File Size
- Compare the base disk size of the virtual machine against the block size of the datastore which contains the working directory of the virtual machine. By default, the working directory contains the virtual machine's .vmx configuration file. Note that the maximum file size differs among versions of ESX/ESXi and among versions of VMFS.
- If you experience this error even after confirming that the snapshot files can fit on the datastore, proceed to STEP 3.
ESXi 5.0 and 5.1 with VMFS5
On ESXi 5.0 and 5.1 and newly formatted VMFS5, a standard 1MB block size is available. The maximum file size is 2TB - 512Bytes.
Block Size 1MB / Maximum File Size 2TB - 512 Bytes
ESX/ESXi 4.1 and ESXi 5.1 with VMFS3
On ESX/ESXi 4.1 and ESXi 5.1 using a VMFS3 datastore, the maximum file size corresponds to the block size of the VMFS datastore:
- Block Size 1MB / Maximum File Size 256GB
- Block Size 2MB / Maximum File Size 512GB
- Block Size 4MB / Maximum File Size 1TB
- Block Size 8MB / Maximum File Size 2TB - 512 Bytes
ESX/ESXi 4.0 with VMFS3
On ESX/ESXi 4.0, the maximum file size corresponds to the block size of the VMFS3 datastore:
- Block Size 1MB / Maximum File Size 256GB - 512Bytes
- Block Size 2MB / Maximum File Size 512GB - 512Bytes
- Block Size 4MB / Maximum File Size 1TB - 512Bytes
- Block Size 8MB / Maximum File Size 2TB - 512 Bytes
Step 2. Move Files to Accommodate Space Requirements
This step describes how to resolve this error by changing either the location of the virtual machine configuration files or the workingDir to a datastore with enough block size.
The workingDir is the location where the snapshots are created, By default, the workingDir contains the virtual machine's .vmx configuration file. To change the workingDir directory to a datastore with enough block size, see the VMware solution Creating snapshots in a different location than default virtual machine directory (1002929).
To move the virtual machine's disks and/or configuration files, use Storage vMotion or cold migration with relocation of files. For more information, see the following VMware documentation:
- vSphere 5: Migrating Virtual Machines section of the vCenter Server and Host Management Guide.
- vSphere 4.1: Migrating Virtual Machines section of the vSphere Datacenter Administration Guide.
- vSphere 4.0: Migrating Virtual Machines section of the vSphere Basic System Administration Guide.
If the virtual machine already has snapshots, some procedures may not work, or they may attempt to create a snapshot. Table 1 table lists the requirements for the various procedures.
Table 1. Procedure Requirements.
The virtual machine must not have snapshots on ESX/ESXi 4.1 hosts or earlier. It may have snapshots on ESXi 5.0 or later.
Cold migration with file relocation
The virtual machine may have snapshots. The source and destination hosts must be running ESX/ESXi 3.5 or later.
The virtual machine may have snapshots. When new snapshots are created, new redologs are placed in the workingDir directory.
The virtual machine may have snapshots, but the snapshot hierarchy must be less than 31 snapshots deep. Hot cloning a virtual machine creates a snapshot on the source at the beginning of the process, and then deletes the snapshot at the end of the process.
The virtual machine may have snapshots. Cloning the virtual machine creates a new virtual machine with the same content as the original virtual machine, but without snapshots.
vMotion to ESX/ESXi 3.5
The virtual machine may have snapshots. The virtual machine must use hardware version 4. ESX/ESXi 3.5 does not perform the check described here and allows snapshots to be created.
Step 3. Calculate Required Overhead
The failure depends on the size of the virtual disk. All virtual machines that have disks greater than the maximum supported size by VMFS may experience this error. Overhead for the snapshot is approximately 2GB for a disk size of 256GB. If snapshots are to be used, consider the overhead while deciding the size of the disks:
Maximum VMDK Size
Maximum Size Less Overhead
256GB - 512B
512GB - 512B
1TB - 512B
2TB - 512B
VMware recommends that you create virtual disks that are smaller than the maximum size minus the overhead to enable the use of features such as snapshotting, cloning, and independent non-persistent disks.