VMware ESXi Virtual Disk Provisioning Types: Thick Lazy Zeroed, Thick Eager Zeroed, and Thin
Learn how VMware ESXi thick lazy zeroed, thick eager zeroed, and thin virtual disks allocate datastore space, when blocks are zeroed, and how to choose a format.
When you create a virtual machine (VM) in vSphere, you choose how each virtual disk uses datastore capacity. The three common provisioning formats are Thick Provision Lazy Zeroed, Thick Provision Eager Zeroed, and Thin Provision.
The choice affects disk creation time, datastore consumption, write behavior, capacity planning, and compatibility with some vSphere features. This guide explains the differences and provides a practical selection method.
Virtual Disk Provisioning Basics
A virtual disk is a file-backed virtual storage device presented to a VM as a disk. The virtual disk file is stored on a datastore, which is a VMware storage location for VM files such as configuration files, virtual disks, and snapshots.
Two capacity values are important:
- Provisioned capacity is the maximum virtual disk size configured for the VM and normally visible to the guest operating system. For example, a disk can be configured as 10 GB.
- Consumed capacity is the physical datastore space currently occupied by the virtual disk.
A 10 GB virtual disk can therefore have 10 GB of provisioned capacity while consuming either approximately 10 GB or only a few gigabytes on the datastore, depending on its format and contents.
Provisioning controls two related operations:
- Block allocation: when datastore blocks are reserved or assigned to the virtual disk.
- Zeroing: when zeros are written to blocks before those blocks are used for guest data.
The word first write means the initial guest write to a disk block that has not previously been initialized for guest data.
Thick Provision Lazy Zeroed
Thick Provision Lazy Zeroed is the traditional default provisioning choice in the described vSphere VM creation workflow. It is a thick format, so the complete configured capacity is reserved on the datastore when the virtual disk is created.
Zeroing is deferred. Each block is zeroed when the guest first writes to that block rather than when the virtual disk is created. This is called lazy zeroing.
Example: 10 GB Lazy-Zeroed Disk
- The virtual disk is configured for 10 GB.
- The datastore immediately reserves approximately 10 GB.
- The guest may initially contain little or no data, but datastore consumption remains approximately 10 GB.
- If the guest later stores 3 GB, datastore consumption is still approximately 10 GB.
- Blocks receive their zeroing work when the guest first writes to them.
The main benefit is relatively fast creation because the platform does not need to zero the entire disk before reporting that creation is complete. The trade-off is possible extra work and latency during first writes to previously uninitialized regions.
Thick Provision Eager Zeroed
Thick Provision Eager Zeroed also reserves the full configured virtual disk capacity when the disk is created. Unlike lazy-zeroed thick disks, it zeroes all disk blocks during creation.
Because the platform must allocate and zero the complete disk before creation finishes, eager-zeroed disks take longer to create. Once creation is complete, later guest writes do not need the same first-use zeroing step. This can improve runtime write behavior for workloads where predictable first-write performance matters.
Example: 10 GB Eager-Zeroed Disk
- The virtual disk is configured for 10 GB.
- The datastore immediately reserves approximately 10 GB.
- Creation takes longer because all blocks are zeroed before completion.
- The disk consumes approximately 10 GB regardless of whether the guest uses 0 GB, 3 GB, or nearly all of the virtual capacity.
- Later guest writes do not need the same first-write zeroing operation.
Some advanced vSphere capabilities, including Fault Tolerance in applicable configurations, require eager-zeroed thick disks. Fault Tolerance is an advanced availability capability that maintains a secondary execution copy of a VM. Always verify the requirements for the specific vSphere version and feature configuration before deploying the VM.
Thin Provision
Thin Provision allocates datastore blocks on demand as the guest writes data. The virtual disk can have a large provisioned capacity without immediately consuming that entire amount on the datastore.
Example: 10 GB Thin Disk with 3 GB of Data
- The virtual disk is configured for 10 GB.
- At creation, datastore use is minimal apart from virtual disk metadata and any required filesystem overhead.
- After the guest writes 3 GB, the virtual disk consumes roughly 3 GB of datastore capacity, subject to metadata and filesystem overhead.
- As the guest writes additional blocks, the thin disk grows and consumes more datastore space.
Thin provisioning conserves initial datastore capacity, but it transfers capacity-management responsibility to the administrator. Several thin disks can collectively have more provisioned capacity than the datastore can physically provide. If many guests grow at the same time, the datastore can run out of free space.
Thin disks also generally perform more allocation and zeroing work while they grow than preallocated formats. The exact behavior depends on the storage system, datastore type, workload, and vSphere configuration, so performance expectations should be validated for the intended environment.
Side-by-Side Comparison
| Disk type | Datastore allocation at creation | When blocks are zeroed | Relative creation time | 10 GB configured disk with 3 GB of guest data | Growth behavior | Key considerations |
|---|---|---|---|---|---|---|
| Thick Provision Lazy Zeroed | Approximately 10 GB is reserved immediately. | On the first guest write to each block. | Relatively fast. | Approximately 10 GB consumed. | Does not grow based on guest data; capacity was preallocated. | Predictable datastore consumption, with possible first-write overhead. |
| Thick Provision Eager Zeroed | Approximately 10 GB is reserved immediately. | All blocks are zeroed during creation. | Slowest of these formats for large disks. | Approximately 10 GB consumed. | Does not grow based on guest data; capacity was preallocated. | Avoids the same first-write zeroing work and may be required by advanced features. |
| Thin Provision | Only initially required space and metadata are consumed. | Allocation and required initialization occur as blocks are used. | Usually fast initially, but growth adds allocation work. | Roughly 3 GB plus metadata and filesystem overhead. | Grows as the guest writes additional blocks. | Efficient initial capacity use, but requires active monitoring and growth planning. |
Choosing a Disk Provisioning Type
| Requirement or priority | Preferred disk type | Reason | Operational caution |
|---|---|---|---|
| Reserve all capacity immediately | Thick Provision Lazy Zeroed or Thick Provision Eager Zeroed | Both thick formats preallocate the complete configured capacity. | Confirm that the datastore has enough free space at creation time. |
| Minimize disk creation time while using thick allocation | Thick Provision Lazy Zeroed | It reserves capacity without zeroing every block before creation completes. | Some first writes can have additional zeroing work. |
| Avoid runtime first-write zeroing | Thick Provision Eager Zeroed | All blocks are zeroed during creation. | Allow for longer creation time and sufficient storage throughput. |
| Meet applicable Fault Tolerance requirements | Thick Provision Eager Zeroed | Applicable Fault Tolerance configurations can require this format. | Check the exact feature prerequisites before creating or converting disks. |
| Conserve initial datastore space | Thin Provision | Datastore blocks are assigned as guest data is written. | Monitor actual consumption and expected growth continuously. |
| Control thin-provisioning overcommit risk | Thick Provisioning, or tightly managed Thin Provisioning | Thick disks make capacity reservation predictable; thin disks require growth controls. | Do not rely only on configured disk sizes or the initial size of thin files. |
Where the Format Is Selected
The provisioning format is selected in the vSphere management interface while creating a VM or adding a virtual disk. In the workflow, select the virtual disk size, select the datastore, and choose one of the available formats:
- Thick Provision Lazy Zeroed
- Thick Provision Eager Zeroed
- Thin Provision
The choice applies to the individual virtual disk. A VM with several disks does not necessarily use the same format for every disk. For example, an operating-system disk could be thick while a temporary data disk is thin, provided the workload and policy requirements allow that design.
For a broader VM creation workflow, see Create Virtual Machines. To add or modify virtual hardware after deployment, see Add Virtual Hardware to VM and Edit Virtual Machine Settings.
Configuration Checklist
- Determine the virtual disk's required provisioned capacity as seen by the guest.
- Check available datastore capacity and expected growth from all VMs.
- Choose the datastore on which the virtual disk will reside.
- Select the provisioning format appropriate for capacity, performance, and feature requirements.
- Verify that advanced features and storage policies support the selected format.
- After deployment, monitor both provisioned capacity and consumed datastore capacity.
Operational Cautions and Troubleshooting
Thin Disk Still Uses Space After Guest Files Are Deleted
Symptom: A thin virtual disk continues to consume significant datastore capacity after files are deleted inside the guest.
Cause: Guest-level deletion marks blocks as available to the guest filesystem, but it does not automatically shrink the virtual disk's datastore allocation.
Lesson: Guest free space is not the same as datastore space reclaimed by the virtual disk. Reclamation requires an appropriate, supported storage-reclamation process and should be planned carefully.
Datastore Runs Low on Space
Symptom: A datastore becomes nearly full even though individual thin disks appeared small when they were created.
Cause: Thin disks expanded as guests wrote more data. The combined growth of multiple VMs created overcommit pressure.
Response: Monitor actual consumed capacity, configured capacity, free datastore space, and expected guest growth. Set alerts and maintain enough reserve capacity to handle normal and unexpected expansion.
Datastore administration topics such as browsing VMFS datastores, expanding a VMFS datastore, and inflating a thin disk can help with capacity operations.
Disk Creation Takes Longer Than Expected
Symptom: VM deployment or virtual disk creation takes much longer than expected.
Likely cause: Thick Provision Eager Zeroed was selected, so the platform is zeroing the full configured capacity during creation.
Lesson: Longer creation is an expected trade-off for eager zeroing, not necessarily a fault. Check storage throughput and disk size if the delay is excessive.
Extra Latency on a First Write
Symptom: A first write to a new disk region experiences extra latency.
Likely cause: A Thick Provision Lazy Zeroed disk is zeroing that block when it is first written.
Lesson: Lazy zeroing defers work until first use, while eager zeroing performs the work during disk creation.
Advanced Feature Cannot Be Enabled
Symptom: An advanced availability feature cannot be enabled with the VM's current disk format.
Likely cause: The applicable feature configuration requires Thick Provision Eager Zeroed disks.
Response: Check the feature prerequisites and storage policy before finalizing the VM. For related availability configuration, see Enable vSphere FT.
Exam-Relevant Summary
- Thick means the complete configured virtual disk capacity is reserved at creation.
- Thick Provision Lazy Zeroed reserves all capacity immediately but zeroes each block on its first guest write.
- Thick Provision Eager Zeroed reserves and zeroes all capacity during creation, so creation takes longer but first-write zeroing is avoided.
- Thin Provision allocates datastore blocks as the guest writes data, conserving initial space but creating growth and overcommit risk.
- A 10 GB thick disk consumes approximately 10 GB even when the guest uses only 3 GB.
- A 10 GB thin disk containing 3 GB of data consumes roughly 3 GB plus overhead, but it can continue growing to 10 GB.
- Deleting guest files does not automatically reclaim the thin disk's datastore footprint.
- Applicable vSphere Fault Tolerance configurations can require eager-zeroed thick disks.
Choose the format only after considering datastore capacity, workload behavior, creation-time expectations, performance requirements, and required vSphere features. Thin provisioning is appropriate when conserving initial capacity is the priority and growth is actively monitored; lazy-zeroed thick is appropriate when full reservation and faster creation are preferred; eager-zeroed thick is appropriate when feature requirements or runtime first-write behavior justify longer creation.