When you create a virtual disk in vSphere, VMware asks you to pick a format: Thin Provision, Thick Provision Lazy Zeroed, or Thick Provision Eager Zeroed. Most people accept the default and move on, then wonder months later why a datastore filled up faster than expected, or why one VM feels snappier than another with identical specs.
The three formats trade space efficiency against up-front allocation and a small first-write cost. None is universally “best.” Thin saves space and lets you over-provision. Thick reserves everything at creation. Eager zeroed goes a step further and wipes the disk clean before the VM ever touches it.
This breaks down what each format actually does on the datastore, where the performance differences come from, and how to choose — plus how to convert between them if you picked wrong.
How a VMDK consumes datastore space
A virtual disk is a VMDK file on a datastore. The provisioning format decides how much of that datastore the VMDK claims and when.
The three VMware disk formats at a glance
| Thin Provision | Allocates space on demand. A 100 GB disk with 20 GB written uses ~20 GB. |
|---|---|
| Thick Lazy Zeroed | Reserves full size at creation. Blocks zeroed on first write. |
| Thick Eager Zeroed | Reserves full size AND zeroes every block at creation. |
The key difference is when space gets committed. A thin 100 GB disk on a fresh VM might occupy only a few gigabytes. The same disk as thick takes the full 100 GB on the datastore the moment you create it, even though the guest OS sees an empty drive either way.
Thin provisioning: pay as you grow
Thin is the space-efficient choice. The VMDK starts small and grows as the guest writes data, up to the disk’s maximum size. This lets you over-provision — assign more total disk to VMs than the datastore physically holds — on the bet that not every VM will fill its disk at once.
That’s powerful and a little dangerous. The upside is obvious: better utilization, less wasted capacity, and the ability to give VMs generous disk sizes without buying storage you don’t need yet. The downside is that over-provisioning means you can promise more than you have.
There’s a minor performance note too. As a thin disk grows into new blocks, vSphere has to allocate and zero them, which adds a small cost on those first writes. On modern flash storage it’s rarely noticeable, but on busy spinning disks or heavy sequential-write workloads it can show up.
Thick lazy zeroed: full reservation, zero on first write
Thick Lazy Zeroed reserves the disk’s entire size on the datastore at creation. The space is yours immediately, so you can’t be surprised later by another VM eating it. But the blocks aren’t wiped yet — whatever data was previously in those datastore blocks stays until the guest writes to them. On that first write, vSphere zeroes the block, then completes the write.
That first-write zeroing is a one-time, per-block cost. After a block has been written once, it behaves like any other. For most workloads the overhead is small and disappears as the disk gets used.
This is a common middle-ground default: you get guaranteed capacity without the longer creation time of eager zeroing.
Thick eager zeroed: everything zeroed up front
Thick Eager Zeroed reserves the full size and writes zeros across every block at creation. Nothing is left for the first-write path, so there’s no per-block penalty when the guest starts writing. The trade-off is creation time — zeroing a large disk takes a while and generates real I/O on the datastore while it happens.
Why bother? Two reasons:
- Consistent low latency. Workloads that can’t tolerate even a small first-write hiccup benefit from having all the zeroing done before they run.
- It’s required for some features. VMware Fault Tolerance and certain clustered/shared-disk configurations require eager zeroed disks.
How the formats compare
| Datastore space at creation | Thin: minimal · Lazy: full · Eager: full |
|---|---|
| Space grows over time | Thin: yes · Lazy: no · Eager: no |
| First-write zeroing cost | Thin: yes (on growth) · Lazy: yes · Eager: none |
| Creation time | Thin: fast · Lazy: fast · Eager: slow (zeroes everything) |
| Over-provisioning possible | Thin: yes · Lazy: no · Eager: no |
| Required for Fault Tolerance | Thin: no · Lazy: no · Eager: yes |
Converting between formats
Picked the wrong format? You’re not stuck with it.
- Thin to thick (lazy zeroed): browse the datastore, right-click the VMDK, and choose Inflate. The VM should be powered off. This claims the full size on the datastore.
- Change format during migration: a Storage vMotion lets you pick the destination format. Migrating to another datastore (or the same one, depending on setup) you can convert thin to thick or thick to thin as part of the move.
- Thick to thin: the cleanest route is Storage vMotion, selecting the thin format on the destination. A plain inflate only goes toward thick.
Which one should you pick?
Match the format to the workload rather than defaulting blindly:
Choosing a provisioning format
- General-purpose VMs where space efficiency matters: thin, with datastore alarms
- Predictable workloads where you want guaranteed capacity: thick lazy zeroed
- Latency-sensitive databases or anything needing steady write performance: thick eager zeroed
- VMware Fault Tolerance or shared-disk clustering: thick eager zeroed (required)
- Tight, well-monitored storage and you want maximum utilization: thin
The pragmatic default for a lot of environments is thin for general VMs — it uses space well and is easy to grow — paired with disciplined monitoring of real datastore usage. Reach for eager zeroed when a workload demands consistent latency or a feature requires it. Lazy zeroed sits in between when you want the capacity guarantee without the long creation time.
If you’re thinking about storage formats, you’re probably also thinking about how to protect what’s on them. Two reminders that pair well here: VMware snapshots are not backups, and you’ll still want a real plan to back up your ESXi virtual machines.
Wrapping up
VMware’s three disk formats are a trade between space and up-front work. Thin grows on demand and lets you over-provision, as long as you watch real datastore usage. Thick lazy zeroed reserves full capacity at creation and zeroes blocks on first write. Thick eager zeroed does all the zeroing up front for steady write latency, and it’s required for Fault Tolerance.
For everyday VMs, thin plus good monitoring is a solid default. Move to eager zeroed when latency or a feature forces the issue, and remember you can inflate or Storage vMotion your way out of a bad early choice. For more storage and platform guides, browse the virtualization guides.
