VSAN Part 24 – Why is VSAN deploying thick disks?
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.
Hi @Corman
Use FTT = 1 with VMDK is 50GB, then need 100GB for 2 replica
So total VMDK and 2 replica = 150GB ?
I try create VM 8GB, I use FTT=1, then total vmdk and 2 replica=16GB? Can you explain me?
A replica in this case simply means a copy of the storage object. So with FTT=1, you get a total of 2 replicas (2 copies). Therefore 2 x 8GB = 16GB consumed.
Hi @Cormac
– Remaining capacity of vmdk?….total of 2 replicas (16GB) + vmdk (8GB) = 24GB. Space free is 50GB… Then create VM 8GB and FFT=1, remaining capacity of Vsan datastore = 34GB? So when VM running means 1 replica (1) running, replica(2) other synchronization from 1 replica (1). So there must be 1 replica(1) is vmdk.
– Vsan only show 2 replica, why it don’t show vmdk of object?
Hi @Corman
– Can you help me?
+How manny datasore VSAN have ?? only one or more than one ?????
+ As we know, if we wan’t to configure SQl failover cluster we must use SAN or Virtual SAN (virtual SAN ISCSI), Can we user Virtual SAN (VMware) to configure SQL failover cluster ??? i found it on google but haven’t
1 datastore per VSAN cluster.
If you mean that you wish to use Microsoft Cluster Service (MSCS) for SQL failover clustering running in VMs, then no, there is no support for this as it requires pRDMs, and VSAN does not have RDM support.
thank you very much 😀
Hi @Corman
– Can you help me?
+ VSAN datastore only contain Virtual Machine?
Can you help me??? :((
Correct – VSAN datastore only supports VMs at this time.