How to fix Thick non-vSAN provisioned policies on your VxRail cluster running vSAN 6.7 U3

Have you ever had someone do a restore of a backup to your vSAN cluster?  Ever find it annoying that it does a non-vSAN policy and spits health errors in your vSAN Health check?  Ever find it annoying when this new VM is Thick provisioned and 99% of the time it can be thin provisioned?  You’re in luck because this experience has finally tempted me into writing a blog article.  Below you will see the four options to resolve but today I am going to write about option 1.  The only difference is I am flipping from thick to thin provisioned.  However, if the VMs do require thick provisioning then create a storage policy with thick instead of thin and apply that policy.

Option 1:

Go into VM and change storage policy from non-compliant vSAN policy to compliant vSAN policy. 

Option 2 :

Schedule downtime for the VM and perform a clone within the vSAN datastore. The newly created destination VM should have thin VMDK(s). A back up is recommended as best practice.

It is recommend to perform a final check on the cloned VM and then delete the older respective VM from vSAN datastore, which should auto reclaim space upon deletion.

Option 3 :

Use VMware converter to convert the VM within vSAN datastore which should allow copying the VM contents without powering off the source VM. However, during the switch-over to the newly created VM, you may have to Power OFF source and Power ON destination VM or converter tool may do this automatically based on type of conversion / version.

It is recommend to perform a final check on the cloned VM and then delete the older respective VM from vSAN datastore, which should auto reclaim space upon deletion.

Note : Please test this on a non-critical test VM first and then you may try this on production VM.

Option 4 :

Perform a sVmotion of the VM to regular SAN storage or another vSAN datastore and then back again to the original vSAN datastore.

Option 1 how to
Go to your VM and drop down on the Hard Disk on the VM

You can confirm it is Thick Provision Eager Zeroed

As you can see from the above because no vSAN policy was chosen it was applied Datastore Default

Change the VM storage policy to your desired policy and click on at the bottom

Once the reconfigure VM process is complete you should be able to go back to the bottom of the page and confirm the VM is now compliant.

Summary:
I like this process because it is quick and easy and assuming you’re not doing a lot of these then the backend process isn’t noticeable.  However, if there are concerns or looking for other ways they are listed above.  As always I hope y’all find this article useful.