VMware Cloud Community
Petersaints
Enthusiast
Enthusiast
‎02-09-2021 05:06 AM
Jump to solution

vSAN Raid 5 all flash - FFTT=1 - 4 hosts - Change Storage policy

Hello all,

I have 4 ESXi on version 6.7 U3. Bellow is my actual storage policy

Petersaints_0-1612872163156.png

On vsan, i have enough free space. I have two questions:

1 - Can i edit the policy and change the object storage reservation to 100% (thick)? Will i have any impact performing this operation? VMs will assume the new setting?

2 - If i change the policy, what will happen when i deploy a VM from a template. The deployment is done with Terraform, but on the code arguments, for disk type i only have e.g. thin, lazy... i don't have anything like "As defined in the VM storage policy". What format should i start choosing? Lazy?

 

Thanks.

Regards

0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
‎02-09-2021 06:23 AM
Jump to solution

@Petersaints , In general it is not advised to make changes to in use SP(Storage Policy) that may quickly and/or temporarily use or reserve a lot of space (e.g. changing from RAID5 to RAID1), what is a better approach is to clone the current SP to a new one and then make the changes on the new SP, then apply this SP to a few Objects as test and then do the rest in batches (from the VM page in SPs one can select multiple VMs to apply this to at once). vSAN doesn't actually write zeroes or anything to 'Thick' Objects, it just reserves the space so no it shouldn't have any performance implications provided you have enough space to do so (but note point above to ensure this).

If you cannot choose SP on the 3rd-party application then it will likely use whatever SP is currently set as the vsanDatastore Default SP https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-F52F0AE9-FB31-4... or depending on the application it may just talk to one node and use a non-SPBM host based SP (e.g. as per esxcli vsan policy getdefault ), I would advise go with thin and then configure 'Thick' via SP (which it will already if this is set as the datastore default and this is what it uses).

View solution in original post

1 Reply
TheBobkin
Champion
Champion
‎02-09-2021 06:23 AM
Jump to solution

@Petersaints , In general it is not advised to make changes to in use SP(Storage Policy) that may quickly and/or temporarily use or reserve a lot of space (e.g. changing from RAID5 to RAID1), what is a better approach is to clone the current SP to a new one and then make the changes on the new SP, then apply this SP to a few Objects as test and then do the rest in batches (from the VM page in SPs one can select multiple VMs to apply this to at once). vSAN doesn't actually write zeroes or anything to 'Thick' Objects, it just reserves the space so no it shouldn't have any performance implications provided you have enough space to do so (but note point above to ensure this).

If you cannot choose SP on the 3rd-party application then it will likely use whatever SP is currently set as the vsanDatastore Default SP https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.virtualsan.doc/GUID-F52F0AE9-FB31-4... or depending on the application it may just talk to one node and use a non-SPBM host based SP (e.g. as per esxcli vsan policy getdefault ), I would advise go with thin and then configure 'Thick' via SP (which it will already if this is set as the datastore default and this is what it uses).