In this post, we talk about a particular behaviour with using the default (or None) policy with VSAN. I have stated many times in the past that when a VM is deployed on the VSAN datastore, it behaves like it is thinly provisioned unless the capability ‘Object Space Reservation’ (OSR) is specified in the VM Storage Policy. The OSR will pre-allocate space on the VSAN datastore for the virtual machine’s storage objects, and is specified as a percentage of the actual VMDK size. However, there is a slightly different behaviour when the default policy is used. Once again, I was in a conversation with a customer who stated that when he used the default policy of “None”, he could see space being consumed on the VSAN datastore was equal to the size of the VMDK * FTT (Number of Failures To Tolerate). He wondered why this was the case when the default policy clearly did not contain an Object Space Reservation capability.
In a nutshell, if no policy is chosen, and the default policy (None) is used, VMs deployed on VSAN can be specified as thick or thin. This can be done by expanding the Hard Disk configuration options in the VM deploy wizard customize hardware as shown below. Here, in the Disk Provisioning section, I have selected Thin Provision, but by default it will have LZT (Lazy Zero Thick) selected:
This is by design. If you don’t use a VM Storage Policy, then the traditional way of deploying VMs controls what happens, including providing options for thin and thick provisioning. So when you ask for a thickly provisioned VM, you will get thick, i.e. 100% space reservation. If however you use a VM Storage Policy, then the thin/thick decision is delegated to the policy as shown below. By default, this will be ‘thin’ but if the Object Space Reservation capability is specified in the policy, will you get space reservation for the VM storage objects:
So all VMs deployed on the VSAN datastore using a VM Storage Policy will not reserve any space unless Object Space Reservation is specified. However if you choose to use the default policy (None), VMDK formatting (thick/thin) will still be used.