VMware ESXi and vSphere Cluster Management
Types of Virtual Disks in VMware vSphere
Learn how Thick Lazy Zeroed, Thick Eager Zeroed, and Thin Provision virtual disks allocate datastore capacity, handle zeroing, affect performance, and fit different vSphere use cases.
A virtual disk is a virtual machine storage device with a configured capacity. The guest operating system sees that device as a disk, while the underlying virtual disk files consume space from a vSphere datastore. A datastore is the vSphere storage location that holds virtual machine files.
Provisioning is the method used to reserve and initialize datastore storage for a virtual disk. In VMware vSphere, the usual provisioning choices are Thick Provision Lazy Zeroed, Thick Provision Eager Zeroed, and Thin Provision.
The selected format determines when datastore capacity is consumed and when disk blocks are initialized, or zeroed. You normally choose the format while creating a virtual machine or adding a virtual disk. The disk-size field determines the capacity visible to the guest; the provisioning format determines how that capacity initially uses the datastore.
How virtual disk provisioning works
Two ideas are important when comparing disk formats:
- Preallocation means reserving the entire configured virtual disk capacity on the datastore when the disk is created.
- On-demand allocation means allocating datastore blocks as the virtual machine writes data.
Zeroing means initializing disk blocks so that old or uninitialized storage contents are not exposed as new disk contents. A first write is the initial guest write to a previously uninitialized block. Different disk formats perform this work at different times.
Where the choice appears
During virtual machine creation, or when adding a virtual hard disk, vSphere presents a disk size and a provisioning format. The selectable formats covered here are:
- Thick Provision Lazy Zeroed
- Thick Provision Eager Zeroed
- Thin Provision
For example, selecting a 10 GB disk tells the guest that a 10 GB disk exists. Selecting a thick or thin format then determines whether the datastore reserves all 10 GB immediately or allocates storage progressively.
Thick Provision Lazy Zeroed
Thick Provision Lazy Zeroed is the standard thick provisioning option in this lesson. The full configured capacity is reserved on the datastore when the virtual disk is created. A 10 GB lazy-zeroed thick disk therefore consumes 10 GB of datastore capacity even if the guest has written only a small amount of data.
Its zeroing is lazy: disk blocks are initialized when the guest first writes to them, rather than when the disk is created. Because full initialization is deferred, disk creation is usually relatively quick compared with eager-zeroed thick creation.
The trade-off appears during operation. A first write to a previously untouched block can require zeroing work before the guest write completes. This may introduce initialization overhead during workload activity, particularly when a workload writes across a large new area of the disk.
Example: 10 GB lazy-zeroed thick disk
- Create a virtual disk with a configured capacity of 10 GB.
- The datastore reserves 10 GB immediately.
- Write 3 GB of guest data.
- The guest sees a 10 GB disk, and the datastore still has 10 GB reserved for that disk.
The amount of guest data is not the same as the amount of datastore capacity reserved for a thick disk.
Thick Provision Eager Zeroed
Thick Provision Eager Zeroed also reserves the full configured capacity immediately. A 10 GB eager-zeroed thick disk consumes 10 GB of datastore capacity regardless of how much data the guest has written.
With eager zeroing, all disk blocks are initialized while the virtual disk is created. Creation can therefore take considerably longer, because vSphere performs the initialization before the disk is ready for normal use.
The runtime benefit is that first-write zeroing is not deferred to ordinary workload activity. The disk has already been initialized, so the workload does not need to pay that particular initialization cost when it first writes to each block. This makes eager-zeroed thick disks suitable for performance-sensitive workloads where more predictable initialization behavior is desirable.
Certain advanced vSphere capabilities, including Fault Tolerance in this lesson, require eager-zeroed thick disks. Fault Tolerance is an advanced vSphere feature that keeps a protected virtual machine available through a redundant execution arrangement. When a feature requirement applies, compatibility takes priority over faster creation or capacity efficiency.
Example: creation-time trade-off
Suppose two equal-size virtual disks are created, one lazy-zeroed thick and one eager-zeroed thick. The lazy-zeroed disk can generally finish creation sooner because it reserves the space but postpones block initialization. The eager-zeroed disk takes longer because it reserves the space and initializes every block before creation completes.
Thin Provision
Thin Provision separates the disk capacity visible to the guest from the physical datastore capacity currently consumed. The guest can see the full configured size, but datastore blocks are allocated as the guest writes data.
For example, create a thin virtual disk configured for 10 GB and place 3 GB of data inside the guest. The guest sees a 10 GB disk, while the thin disk consumes approximately 3 GB of datastore capacity, subject to implementation overhead. As more data is written, the thin disk grows toward its 10 GB maximum.
Thin provisioning allocates and initializes blocks as they are needed. This can make initial disk creation fast and can conserve datastore capacity when the guest uses only part of its configured disk. However, allocation and initialization can occur during writes. Of the three formats covered here, thin provisioning has the lowest performance positioning because this work can occur during normal workload activity.
Thin disks and deleted files
Deleting files inside the guest normally does not automatically reduce the thin disk's datastore consumption. The guest may report more free space, but blocks that were previously allocated at the datastore layer can remain allocated.
This creates an important distinction:
- Guest free space is space the guest operating system can use for new files.
- Datastore free space is physical capacity not currently consumed by virtual machine files.
Returning previously allocated blocks to the datastore requires an explicit, supported space-reclamation workflow where applicable. Do not assume that deleting guest files automatically makes the same amount of datastore capacity available.
Comparison of VMware vSphere virtual disk types
| Disk type | Datastore allocation at creation | When blocks are zeroed | Relative creation time | Runtime first-write behavior | Datastore consumption for a 10 GB disk with 3 GB written | Relative performance consideration | Typical use case |
| Thick Provision Lazy Zeroed | Full 10 GB is reserved immediately. | On the first write to each previously untouched block. | Relatively quick because initialization is deferred. | First writes can include zeroing work. | 10 GB reserved and consumed by the thick disk. | Can experience initialization overhead during first writes. | Full space reservation without paying the entire initialization cost during creation. |
| Thick Provision Eager Zeroed | Full 10 GB is reserved immediately. | All blocks are initialized during creation. | Longest of the three in the typical comparison because initialization is upfront. | No deferred first-write zeroing for the already initialized blocks. | 10 GB reserved and consumed by the thick disk. | More predictable initialization behavior; useful for performance-sensitive workloads and required features. | Fault Tolerance requirements or workloads that prefer up-front initialization. |
| Thin Provision | Capacity is allocated on demand as blocks are written. | As blocks are allocated and needed for writes. | Usually fast because the maximum capacity is not initialized at creation. | Allocation and initialization can occur during writes. | Approximately 3 GB, subject to implementation overhead, while the guest still sees 10 GB. | Lowest performance positioning of the three because allocation and initialization can occur during workload activity. | Capacity efficiency when monitoring and growth planning are in place. |
Creation time, allocation, and zeroing
The formats differ in both when capacity is reserved and when initialization occurs:
- Lazy-zeroed thick reserves the full capacity at creation, then zeroes individual blocks on their first write.
- Eager-zeroed thick reserves the full capacity and zeroes all blocks during creation.
- Thin provisioning allocates and initializes blocks as the guest needs them.
These choices affect both creation time and runtime behavior. Faster creation does not necessarily mean better workload performance. A thin or lazy-zeroed disk may shift some work from the creation phase into later writes, while eager-zeroed thick provisioning performs the initialization up front.
Selecting a disk type
| Requirement or priority | Recommended provisioning format | Reason | Operational caution |
| Full capacity reservation with faster creation | Thick Provision Lazy Zeroed | The full datastore capacity is reserved, but zeroing is deferred. | First writes to unused blocks can incur initialization work. |
| Up-front block initialization or Fault Tolerance requirement | Thick Provision Eager Zeroed | All blocks are initialized at creation, and the format supports requirements such as Fault Tolerance in this lesson. | Allow for longer creation time and immediate full capacity consumption. |
| Datastore capacity efficiency | Thin Provision | Capacity is consumed as guest writes require additional blocks. | Monitor growth and ensure the datastore can support future allocation. |
| Avoiding thin-disk growth surprises | Thick Provision Lazy Zeroed or Thick Provision Eager Zeroed | Full configured capacity is reserved from the beginning. | Thick disks consume the full capacity even when guest usage is low. |
Use lazy-zeroed thick disks when you want full space reservation but do not want to wait for full initialization during creation. Use eager-zeroed thick disks when a supported advanced feature requires them or when up-front initialization and predictable first-write behavior are important. Use thin provisioning when conserving datastore capacity is more important than immediate full allocation, provided that capacity monitoring and growth planning are active.
Always evaluate both the individual virtual machine and the aggregate datastore. Several thin disks can each have a large configured capacity while consuming less space initially. If they all grow at the same time, their combined potential growth can exceed available datastore capacity.
Disk growth and space reclamation
Thin disks grow as guest writes require additional blocks. A guest can report substantial free space after files are deleted, while the datastore continues to show the blocks as consumed by the virtual disk.
This is why guest free space must not be interpreted as automatically available datastore free space. Where storage must be returned to the datastore, use an appropriate supported space-reclamation workflow and verify the result at the datastore layer. The exact workflow depends on the environment and storage implementation, so capacity recovery should be planned rather than assumed.
Troubleshooting common symptoms
Thin disk remains large after guest files are deleted
Likely cause: Guest file deletion does not automatically reclaim previously allocated thin-disk blocks at the datastore layer.
Response: Compare guest free space with actual datastore usage, then use an appropriate supported reclamation process if applicable. Verify datastore capacity afterward.
Datastore is nearly full although guests report free space
Likely cause: Thin disks may have grown during earlier writes and may not have shrunk after guest deletions.
Response: Review actual datastore usage, identify thin-provisioned disks, estimate their possible future growth, and plan reclamation or datastore expansion.
Virtual disk creation takes longer than expected
Likely cause: The disk is being created as Thick Provision Eager Zeroed.
Response: Confirm the selected format. The longer creation time is expected because the full capacity is initialized at creation.
Workload experiences initialization work on first writes
Likely cause: The disk may use Thick Provision Lazy Zeroed, which zeroes blocks on first write.
Response: Explain the deferred-zeroing behavior and assess whether eager-zeroed thick provisioning is justified by workload requirements or an advanced feature.
VM does not meet an advanced feature's disk requirement
Likely cause: The selected provisioning format does not satisfy the feature requirement, such as the eager-zeroed thick requirement associated with Fault Tolerance in this lesson.
Response: Verify feature compatibility and select the required disk format before enabling the feature.
Exam-relevant notes
- Thick disks reserve their full configured capacity at creation.
- Lazy-zeroed thick disks zero blocks on first write.
- Eager-zeroed thick disks zero all blocks during creation.
- Thin disks allocate datastore capacity as data is written.
- A guest-visible 10 GB disk does not necessarily consume 10 GB of datastore space when it is thin provisioned.
- Deleting files in the guest does not automatically return thin-disk capacity to the datastore.
- Fault Tolerance is associated here with an eager-zeroed thick disk requirement.
- Thin provisioning requires monitoring because aggregate disk growth can create datastore overcommitment: potential thin-disk growth can exceed available datastore capacity.
For related study, review Types of Virtual Disks.