Disks format vmdks

[aquila72]

Thick provisioning lazy zeroed, Thick Provision Eager Zeroed and Thin Provision

Although I understood the difference I did not understand when to use them

On what occasions do you use one rather than the other?

[MDNaseer]

Thick Provision Lazy Zeroed

	Creates  a virtual disk in a default thick format. Space required for the  virtual disk is allocated when the virtual disk  is created. Data  remaining on the physical device is not erased during creation, but is  zeroed out on demand at a later time on first write from the virtual  machine. Using  the default flat virtual disk format does not zero out or eliminate the  possibility of recovering deleted files or restoring old data that  might be present on this allocated space. You cannot convert a flat disk  to a thin disk.
Thick Provision Eager Zeroed	A  type of thick virtual disk that supports clustering features such as  Fault Tolerance. Space required for the virtual disk is allocated at  creation time. In contrast to the flat format, the data remaining on the  physical device is zeroed out when the virtual disk  is created. It  might take much longer to create disks in this format than to create  other types of disks.
Thin Provision	Use  this format to save storage space. For the thin disk, you provision as  much datastore space as the disk would require based on the value that  you enter for the disk size. However, the thin disk starts small and at  first, uses only as much datastore space as the disk  needs for its  initial operations.

[TheBobkin · Accepted solution]

Hello Aquila,

Summary of each disk-type:

Thin: Allocate and zero on first write

Thick Lazy: Allocate in advance and zero on first write

Thick Eager: Allocate and zero in advance

rickardnobel.se/eager-thick-vs-lazy-thick-disk-performance/

When to use one over another should be based on the requirements of the VM/Application using the disks -

Do you want to save space?

Do they need the best disk performance possible?

Do they have a high rate of data change?

Some applications (such as those using multi-writer flag) have a requirement for Thick Eager-zeroed disks such as Oracle RAC:

kb.vmware.com/kb/1034165

Other applications also advise using Eager-zeroed for databases such as SAP:

vmware.com/files/pdf/solutions/sap/sap-solutions-on-vmware-best-practices-guide.pdf

So essentially it comes down to what you are using these disks for and which attributes take priority.

Bob

-o- If you found this comment useful please click the 'Helpful' button and/or select as 'Answer' if you consider it so, please ask follow-up questions if you have any -o-

[aquila72]

So for example for a database has high rate of date change so "Thick Provision Eager Zeroed" is it best solution?

[aquila72]

Are there some articles for the best practice to implement it? For example in microsoft moc there are best pratice implementing solutions. Are there also in vmware?

[TheBobkin]

Hello Aquila,

For databases like the ones I referenced above, yes Thick Eager-zeroed would be optimal.

Regarding 'best practice', these are usually advised by the OS/Application vendor (and then included in kb articles etc. on the VMware side).

What Guest OS/Application are you considering here?

Bob

-o- If you found this comment useful please click the 'Helpful' button and/or select as 'Answer' if you consider it so, please ask follow-up questions if you have any -o-

[aquila72]

I'm studying for vmware certification thank you

[continuum]

> Although I understood the difference I did not understand when to use them.
Let me add some important details that you do not hear every where:
In case you use a standalone ESXi host with local storage only and you run into a problem with the VMFS-filesystem the major difference between the 3 types is:

provisioning type	chances to recover after a VMFS-corruption
Eager zeroed thick	good - if the vmdk is not fragmented it can be recovered without any loss
Lazy zeroed thick	good - if the vmdk is not fragmented it can be recovered but the result is dirty
Thin	very poor - a thin provisioned vmdk without healthy VMFS-metadata is nothing but a large pile of garbage

Ulli