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.

VSAN Default PolicyOut 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).

Datastore default policyWhen 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:

compliantYou 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:

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

  1. Cormac, good change this. But I thought that 5.5 had a default storage policy for vSAN, which had FTT=1 in it. Was that policy not automatically applied?

    • It does indeed. It is called “none”. However, if you do not select a policy, and go for the default, you are still put through the standard VM provisioning mechanism which allows you to pick thin, LZT and EZT. there lies the problem.

      If you explicitly select a policy in 5.5, you go through a different VM deployment wizard path, and VMDK format is chosen “as per policy setting”, e.g. Object Space Reservation set to 0 by default.

    • There is no software checksum in VSAN 6.0.
      My understanding is that there is hardware checksum in some VSAN Ready Node configurations. I haven’t looked to see which ones however.

Comments are closed.