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

Posted by

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

Machine generated alternative text:
VM Hardware 
> CPU 
Memory 
> Hard disk 1 
> Network adapter 1 
CD/DVD drive 1 
> Video card 
VMCI device 
2 CPU(s) 
C] 378 Ga. 0.04 (3B memory active 
33.92 Ga 
(connected) 
Disconnected
Machine generated alternative text:
Hard disk 1 
Capacity 
Type 
Location 
33.92 Ga 
Thick Provision Eager Zeroed 
(85 43 TB free)

You can confirm it is Thick Provision Eager Zeroed

Machine generated alternative text:
Virtual Hardware 
CPU 
Memory 
v Hard disk 1 
Maximum Size 
VM storage 
Type 
Sharing 
Disk File 
VM Options 
ADD NEW DEVICE 
37812S 
33.915527343 
62 TB 
Data store 
As defined in tne VM storage colicy 
No sharing

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

Machine generated alternative text:
Virtual Hardware 
CPU 
Memory 
Hard disk 1 
VM Options 
ADD NEW DEVICE 
o 
Maximum Size 
VM storage policy 
Type 
Sharing 
Disk File 
33.915327843 
62 TB 
Raid-S Disk stripe 1 FTT 1 storage Policy 
As defined in the VM storage policy 
Na sharing

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

Machine generated alternative text:
VM Storage Policies 
VM Storage Policies 
VM Storage Policy Compliance 
Last Checked Date 
VM Replication Groups 
Check Compliance 
Raid-5 Disk Stripe 1 FTT 1 Storage Policy 
Compliant 
03/19/2020. PM

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.

Leave a Reply