7

Slightly related to a previous question about thick vs thin provisioning, why does eager zeroing the to-be-cloned VM take longer than lazy zeroing?

For example, in a recent test we ran, an eager-zeroed clone took ~85 minutes to complete, whereas changing to lazy zeroing made it complete in ~50 minutes.

How much overhead is incurred when eager zeroing vs lazy?

When would 'eager' be the right mode to use?

Community
  • 1
warren
  • 17,829
  • 23
  • 82
  • 134

2 Answers2

9

Eager Zeroing writes 0s to all empty blocks. This slightly increases performance later on when those blocks need to be written to for the first time.

Lazy Zeroing does nothing to the unallocated blocks. If you have an 80GB VMDK and only 10GB worth of data, only 10GB worth of blocks are used and the rest is left as-is until needed. If this example were eager zeroed, at the time of creation all 80GB would be written to, with zeroes filling the remaining 70GB.

If you're using thin provisioning at the storage level, you want to avoid eager zeros, as that will completely defeat the purpose of thin provisioning.

When would 'eager' be the right mode to use?

Eager is the right mode to use when you're not thin provisioning LUNs and you don't mind waiting a bit longer for the VMDK to be created.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • 1
    I always eager zero where possible to avoid the .vmdk's being fragmented, and to be confident I won't run out of space on the host if the drives in the vm's are filled. – Robin Gill Aug 30 '12 at 14:55
  • 1
    How would writing 0s to a volume increase its performance...? – Basil Aug 30 '12 at 15:15
  • @RobinGill - how can you run out of space in a thick-provisioned drive? – warren Aug 30 '12 at 15:21
  • 1
    @ warren - oops got mixed up (I'm still getting to grips with ESXi). – Robin Gill Aug 30 '12 at 15:44
  • @Basil A lazy zeroed VMDK is like a sparse file basically. So the blocks have to be initialized (or whatever the term is) before they can be written to. Zeroing them doesn't increase performance, but the fact that they're not sparse does. – MDMarra Aug 30 '12 at 15:51
  • 1
    So it's not like another file system that can simply write over the garbage data in uninitialized sectors? – Basil Aug 30 '12 at 16:39
  • @Basil I'm under the impression that there's a performance hit for using a lazy zero because the block must be initialized immediately before it can be written to. I'll have to look into this further and update if needed. – MDMarra Aug 30 '12 at 16:44
  • @MDMarra - from the vSphere ICM class I'm in this week, all thick-provisioned virtual disks should have equal performance (outside of the sub-1% performance hit to zero the space before writing the first time; the thick-provisioned disk won't be spread all over the drive – warren Sep 10 '12 at 19:43
0

Im rephrasing and reducing this to be a bit to be less confusing:

When would 'eager' be the right mode to use?

When you are Using Deduplication, Compression, or Thin Luns, on your SAN underlying the VMFS Store, instead of or in addition to, using Thin Provisioned VMs.

Usually you would only use this when reclaiming all of the free space in a vmfs volume by creating an extra Disk deployed this way.

Eager Zero is used for zeroing the space used by the VMDK on the VMFS store, and isn't really useful on a deployment of a new VM.

The classic example on why else you might use it was always pretty extreme/niche, and even more so today.

That is:

To pre-zero the sectors that will be written to by the VM, so that when the VM is running, it reduces VCPU load and disk write latency when writing 0s to the disk.

However this benefit is only while the VM writes to unused sections of disk, and so applications that were write-once read many would see the largest benefit.

Ben Personick
  • 119
  • 6
  • This adds nothing to the [accepted answer](https://serverfault.com/a/422895/2321) – warren Feb 19 '19 at 17:19
  • Well I could see how it was a bit confusing, I cleaned up the answer a bit to make it more clear as to what scenarios would be when the option should be used. :) – Ben Personick Feb 19 '19 at 20:14
  • @warren Well I could see how it was a bit confusing, I cleaned up the answer a bit to make it more clear as to what scenarios would be when the option should be used. :) – Ben Personick Feb 20 '19 at 00:59