VMware ESXi offers flexible virtual-disk formats, each with trade-offs between speed, capacity use, and features. The four main formats are Thick-Lazy (Thick Provision Lazy-Zeroed), Thick-Eager (Thick Provision Eager-Zeroed), Thin Provision, and Raw Device Mapping (RDM). Understanding how they allocate space, handle zeroing of data, and interact with snapshots is crucial for performance and storage efficiency. The table below summarizes each type:
| Format | Space Allocated at Creation | Zeroing / Initialization | Snapshots | Key Notes / Use Cases |
|---|---|---|---|---|
| Thick (Lazy-Zeroed) | Full size (all blocks reserved) | Blocks are not pre-zeroed; each new write to an uninitialized block is preceded by a zero write. | Fully supported (behaves as thin on first writes if snapshot exists) | Fast to provision (no upfront writes). Default format. Good general-purpose VM disks. Incurs a slight latency on first writes to each block (zeroing cost). After a block is initialized, performance matches other types. |
| Thick (Eager-Zeroed) | Full size (all blocks reserved) | All blocks are zeroed at creation (full disk pre-initialized). | Fully supported (but note on snapshot behavior below) | Slowest to provision (ESXi writes zeroes to entire disk). Once created, no first-write penalty – offers the fastest write performance on new blocks. Required for VMware Fault Tolerance and ideal for mission-critical workloads (e.g. high-I/O databases, where guaranteed performance matters). |
| Thin Provisioned | None (initially 0 bytes, grows on demand) | New blocks are zeroed on first write (same as Lazy). | Fully supported | Maximal space efficiency – consumes datastore space only as data is written. Creation is instant. Writes incur first-time zeroing cost (like Lazy) but modern hardware/VAAI can mitigate this. Risk of datastore overcommitment (if storage fills, VMs can fail). After blocks are written once, throughput matches eager disks. Best for light-duty VMs, dev/test, or workloads where storage savings outweigh initial write latency. |
| RDM (Virtual Compat.) | Uses underlying LUN capacity (pointer file only) | No ESXi zeroing (I/O goes directly to LUN). | Supported (uses VMFS lock/metadata, supports VM snapshots) | Provides a direct LUN mapping to the VM. Useful for MSCS clustering or SAN-level snapshots. Performance can approach native SAN speeds (near-native I/O). Supports vMotion and VM snapshots (via the small pointer VMDK file). Leverages VMFS services (locking, snapshots) while bypassing some VMFS I/O overhead. Typically used for shared-cluster disks or storage-aware apps. |
| RDM (Physical Compat.) | Uses underlying LUN capacity (pointer file only) | No ESXi zeroing (pass-through mode). | Not supported (cannot snapshot or use FT) | Maps the LUN almost transparently into the VM (no VMFS mediation). Offers the lowest latency and full hardware functionality (e.g. SCSI commands). Snapshots, FT, and some VMFS features are disabled. Use for very latency-sensitive or legacy workloads that require raw device access (e.g. older cluster solutions or tape backup libraries). |
Thick Provision Lazy-Zeroed (Thick-Lazy)
Thick-Lazy disks reserve the full virtual disk size immediately (so no later allocation needed), but do not zero out the space in advance. In practice, this means creation is fast, since ESXi just allocates space on the datastore. On the first write to each previously-unused block, ESXi must perform a zero-write before writing your data. This incurs a small extra I/O for those first writes, but once a block has been written, subsequent writes to that block have normal speed.
Key characteristics:
- Full allocation: Entire disk size is reserved on creation (no risk of host running out of allocation, aside from space usage).
- First-write penalty: Initial writes to each new block are slower due to zeroing. On modern all-flash or NVMe datastores, and with VMware’s block-zeroing offload (VAAI “Write Same”), this penalty is much reduced.
- Snapshots support: Works with VM snapshots. (Note: if you snapshot an eager-zeroed disk, the new writes in the snapshot incur zeroing like a lazy disk. Likewise a snapshot of any disk carries on the same behavior for new blocks.)
- Use case: Good default for most VMs where quick deployment is desired and temporary initial write latency is acceptable. For example, general server workloads or desktops that will quickly zero most blocks during OS install.
Thick Provision Eager-Zeroed
Eager-Zeroed disks also reserve the full size, but write zeros to every block immediately at creation time. This “pre-zeroing” means there is no special overhead on later writes. An eager disk acts like it has already been initialized. The trade-off is that creating an eager disk can be slow on very large disks or slower storage, because ESXi must write out the zeros (though VAAI block zero offload can speed this up on capable arrays).
Key characteristics:
- Full allocation & initialization: All storage is set aside and cleared. This gives the best possible write performance on first use (no per-block zeroing delays).
- Slower creation: Provisioning a multi-GB eager disk can take time (potentially minutes or longer). Use on fast storage for huge disks if creation time matters.
- Fault Tolerance requirement: Required for VMware Fault Tolerance disks (and older clustering options).
- Use case: High-performance or critical workloads. For example, heavy databases (SQL, Exchange), transaction processing, or any application sensitive to write latency. Also needed if you intend to use vSphere Fault Tolerance or older FT features, which demand eager-zeroed disks.
- Snapshots: Fully supported. Note, however, that creating a snapshot of an eager disk creates a delta stream; writes in that snapshot must zero old data first (making those writes behave like lazy writes).
Thin Provisioning
A thin-provisioned disk is essentially an on-demand allocated virtual disk. Thin-Provisioned disks start at zero bytes and grow on demand up to the set maximum size. They are space-efficient: if you create an 100 GB thin disk but only write 10 GB of data, it will consume about 10 GB on the datastore.
Key characteristics:
- On-demand allocation: When the guest OS writes to new blocks, ESXi allocates space at that time. Like a thick-lazy disk, each first write to a newly-allocated block incurs a zeroing I/O before the data. On some hardware this is accelerated by VAAI (the “Write Same” offload).
- Capacity efficiency: Thin disks maximize free space on the datastore. This is great if many VMs have a lot of empty space. However, you must monitor usage: if the underlying datastore (or array-LUN) runs out of physical space, VMs will get write errors. In practice, combine thin provisioning with storage monitoring and alerts, or use array-level thin provisioning for safety.
- Performance: New-block writes are initially slower (same zeroing cost as lazy), but after a block is written once, performance is the same as on eager-thick. VMware testing has shown that, apart from the first-write cost, thin disks perform virtually identically to thick disks even under heavy I/O. In fact, in aggregate throughput tests, thin disks had “no performance overhead” compared to pre-zeroed thick disks.
- Use case: Best for workloads where saving storage space is important and slight first-write delays are acceptable. Examples include development/test servers, distributed VDI pools, or when backend storage is itself thin-provisioned. Avoid thin on very I/O-intensive production systems unless space is tight and you have mitigations (like large over-provision capacity or fast storage).
Raw Device Mapping (RDM)
RDM is a way for a VM to access a physical LUN (SAN volume) directly. Instead of a traditional VMDK file, the VM uses a small pointer VMDK that redirects I/O to the LUN. RDMs come in two modes:
Virtual Compatibility Mode
The LUN is accessed via VMFS with a small descriptor, so most VM features work. The LUN appears as a “disk” to the guest. This mode supports VMware snapshots, vMotion, and MSCS clustering (shared LUN locking). Use it when you need LUN-level access and VMware features like snapshots or backups to still operate. For example, Windows failover clusters (MSCS) or Oracle RAC VMs often use RDM in virtual mode.
Physical Compatibility Mode
The LUN is more or less “passed through” to the VM. VMFS overhead is bypassed and the VM sees the raw device (almost like an HBA pass-through). This offers near-native I/O performance (minimal overhead). However, you lose VM snapshots, vMotion storage vMotion (in some cases), and certain VMware tools cannot examine the data. This is suited for very latency-sensitive or legacy workloads (e.g. some tape or SAN-backed backups, older cluster setups) where you don’t need those VMware features.
Key characteristics:
- Performance: RDM can outperform or match VMFS-backed VMDKs in heavy I/O scenarios because I/O goes directly to the SAN. VMware notes RDM can provide “near-native I/O performance” and benefits high-throughput, low-latency applications. In practice, most applications see very similar performance on a RDM as on a well-tuned thick disk on modern SANs or vSAN.
- Sharing: RDM allows the same LUN to be presented to multiple VMs (important for clustering). The virtual compatibility mode handles file locks so MSCS can run on vSphere.
- Space: The VMFS datastore only holds the small mapping file; actual data lives on the LUN. So storage efficiency depends on your SAN, not on ESXi. You cannot thin-provision a RDM in the VM (though the array LUN itself might be thin).
- Use case: Specialized scenarios. Common examples: guest clusters (Windows MSCS or Oracle RAC), SAN-based snapshotting/replication workflows, or hardware that must be passed through. On modern all-flash or vSAN systems, RDM is rarely needed except for legacy reasons.
Performance Benchmarks and Best Practices
In real workloads, performance differences between formats show up mostly during initial writes to new blocks. VMware explains that features like VAAI block zeroing (“Write Same”) greatly reduce these costs. For instance, enabling Write Same on the array can speed up creating eager-zeroed disks and improve first-time write I/O for lazy-thick and thin disks.
After the VM’s file system or application has written to all blocks once (zeroing them), benchmarks show nearly identical throughput for thin and eager disks. In other words, aside from the startup penalty, “thin disks perform as well as thick disks, even under I/O-intensive workloads”. VMware’s testing confirmed that in steady-state, a thin-provisioned disk and a zeroed thick disk delivered the same MB/s on a copy workload.
Practical benchmarking:
To quantify these effects in your environment, use modern I/O tools inside the VM. For Windows guests, CrystalDiskMark 8 or DiskSpd can measure sequential/random throughput. For Linux, FIO (v3.35+) is ideal (use direct=1 to bypass caching). For example, if you run a sequential write test on a fresh 50 GB thin disk (Windows Server 2022/2025 VM), you’ll typically see much lower MB/s on the first pass compared to an eager disk, but on a second pass (same blocks) the speeds match. Similarly, FIO’s zero-write or dd if=/dev/zero tests in Linux will show higher latency on the very first overwrite of each block on a thin/lazy disk.
Best practices:
Alignment and I/O size
Ensure the guest OS partitions and file system are aligned to disk / VMFS block sizes to maximize throughput. During initialization, using large sequential writes (as benchmarks do) is more efficient than many small writes.
VAAI support
Use storage and arrays that support VAAI (Write Same, XCOPY). This offloads zeroing and cloning to the hardware, speeding provisioning and first-time writes.
SSD/NVMe/vSAN
Modern all-flash/NVMe arrays (and VMware vSAN) naturally reduce zeroing overhead due to high IOPS. VMware notes that on such storage, “the overhead of thin provisioning has largely been eliminated”. In practice, if your datastore is very fast, you’ll barely notice the lazy-zeroing penalty.
UNMAP/TRIM
In ESXi 7.x and 8.x you can reclaim free space with UNMAP. For array-thin LUNs, ESXi issues UNMAP to the storage to let it release blocks. At the VM level, guest OSs can also issue trim (e.g. fstrim on Linux, or Optimize-Volume in Windows) if you enable the proper policies, to help ESXi reclaim unused space on a thin disk. This improves long-term capacity efficiency.
Snapshots
Remember that snapshots can change behavior. While all disk types support snapshots, an active snapshot can cause new writes to hit a different internal stream. For example, after a snapshot, an eager-zeroed disk’s new writes will incur zeroing in the delta (acting like lazy). Test performance with snapshots enabled if your workflow uses them.
Practical Use Cases
General-purpose VMs
Thick-Lazy disks are a solid default. They’re quick to create and, after the OS is installed (which zeros most of the disk), run just as fast as eager. This is often fine for regular apps, file servers, application servers, etc.
High-performance or critical VMs
Prefer Thick-Eager for maximum predictability. Large databases, transactional systems, or VMs under heavy write loads benefit from no initialization latency. If using vSphere Fault Tolerance or similar features, thick-eager is mandatory.
Space-constrained or dev environments
Use Thin. If you have lots of VMs but limited datastore space, thin provisioning saves storage. Just monitor your capacity to avoid overcommit pitfalls. Development, test, or CI/CD servers often use thin disks for this reason.
Clustering & specialized hardware
Use RDM when you need raw LUN sharing or direct hardware compatibility. For example, older Windows cluster setups (MSCS/RAC) or SAN-level replication schemes. The virtual-mode RDM lets you still snapshot and vMotion those VMs, whereas physical-mode RDM (almost raw pass-through) is for when you need fully native access and can’t use snapshots.
Mixed environments
You can mix these formats on one host. Newer vSphere allows converting a disk’s type (thick<->thin) while VMs are powered off, if your workflow changes. Always test any conversion on non-critical workloads first.
Conclusion
No one format “wins” in all situations. Eager-zeroed disks trade setup time for the best writes, lazy-zeroed trade some write cost for speed of creation, and thin trades potential write latency and overcommit risk for space savings. RDM is for special use cases. With ESXi 8.x and modern OSes, steady-state I/O is similar for all types once disks are initialized. Therefore, choose based on your priorities: speed of provisioning, space efficiency, and any clustering/snapshot needs. Always validate by testing with your actual storage and workload (using tools like FIO or CrystalDiskMark) under realistic conditions to see how each format behaves on your hardware.
