Site icon CormacHogan.com

VSAN 6.0 Part 3 – New Default Datastore Policy

One of the most common issues I got questions about in VSAN 5.5 was “why is VSAN deploying thick disks, when all of the documentation stated that VSAN deploys thin disks”?

The answer was quite straight forward, and was due to the fact that the VMs were being deployed without a VM Storage Policy. This meant that it went through the standard VM deployment wizard which offered administrators the option of thin, lazy-zeroed thick (LZT) and eager-zeroed thick (EZT). The default option is LZT, which if you just do click-click-click (just like I do) when deploying a VM, then you end up deploying a LZT format VM, even on the VSAN datastore. I described this issue in this older blog post. Its only when you select an actual VM Storage Policy when deploying a VM that VSAN uses the Object Space Reservation capability, which by default is 0%, meaning that the VM is effectively thinly provisioned. We realized that this was causing some issues for customers so we improved this whole deployment mechanism in 6.0 with the introduction of Datastore Default policies.

In Virtual SAN 6.0, there is now a default policy for the VSAN datastore, called the Virtual SAN Default Storage Policy. If you wish to change the default policy, you can simply edit the capability values of the policy from the vSphere client.

Out of the box, the capabilities are tolerate 1 failure, set stripe width to 1, no read cache reservation, no object space reservation and do not force provision.

Now when deploying a virtual machine, once the VSAN datastore is selected (as shown below), the VM Storage policy is set to Datastore Default. You no longer need to explicitly pick a policy. For the VSAN datastore, the Datastore Default policy is the Virtual SAN Default Storage Policy (as shown above).

When the VM is deployed, the policy settings can be checked and they will match the settings in the Virtual SAN Default Storage Policy, and its compliance state:

You can also verify that the capabilities are correct, at least the failures to tolerate setting and the stripe width setting by looking at the placement tab for the policy as shown here:

I think this is a nice new feature, and will help to avoid deploying “thick” VMDKs on the VSAN datastore.

Exit mobile version