Hi, the cluster vSAN Datastore we have details 193.86 TB Free Space. So this is RAW Usable as the operations reserve and rebuild reserve have already been deducted.
Deduplication and compression are disabled on the cluster and in the storage policy.
The below "What if" scenario for RAID 5 looks wrong? How can there be effective free space of 298.66TB for new Workloads with RAID5 when there is only 193.86 TB Free?
We have workloads we want to migrate into this vSAN that currently have 142.2 TB provisioned Disk. So now want to know if that will fit into this cluster or if storage scale up needed.
With RAID 5, i calculated 142.2 x 1.33 = 189 TB needed in vSAN if these VMs have R5 Policy?
Accepted Solutions
Looking at the screenshot better (not on a phone helps 
), I don't think this is due to the issue I mentioned as that issue resulted in both R5 and R6 calculation being 1. the same and 2. approximately what an FTT=0 usage would be.
Can you confirm 100% that the policy 'R5 FTT1 Thin' does actually have Object Space Reservation set to 0, asking as policy names are just labels and the policy rules might differ from what the name suggests (though yes, of course they should match, but people can of course change them so they don't). Reason I am asking is that if you consider everything OSR=100 then the calculations look to be roughly accurate.
Can you also confirm what policies all the data in this cluster are currently using, you indicated likely RAID1,FTT=1 but please check
"How can there be effective free space of 298.66TB for new Workloads with RAID5 when there is only 193.86 TB Free?"
This is saying how much space would be free in the cluster if you used 'R5 FTT1 Thin' policy for all current data instead of what is currently used.
You mentioned "142.2 TB provisioned Disk" - just to clarify, 'provisioned' generally means the full size of the vmdk e.g. as VM see it e.g. a 500GB vmdk, this doesn't inform of the actual physically written data which could be 1MB or 500GB, this is important as you indicate want to store this with a thin-policy.
The % for Host rebuild reserve and Operations reserve and what they are based on is well explained here - these won't change by you moving more data to this cluster so 142.2 x 1.33 = 189TB is how much that new data should use (assuming by provisioned you meant physically written):
https://core.vmware.com/blog/understanding-reserved-capacity-concepts-vsan
Looking at the screenshot better (not on a phone helps ), I don't think this is due to the issue I mentioned as that issue resulted in both R5 and R6 calculation being 1. the same and 2. approximately what an FTT=0 usage would be.
Can you confirm 100% that the policy 'R5 FTT1 Thin' does actually have Object Space Reservation set to 0, asking as policy names are just labels and the policy rules might differ from what the name suggests (though yes, of course they should match, but people can of course change them so they don't). Reason I am asking is that if you consider everything OSR=100 then the calculations look to be roughly accurate.
Can you also confirm what policies all the data in this cluster are currently using, you indicated likely RAID1,FTT=1 but please check
"How can there be effective free space of 298.66TB for new Workloads with RAID5 when there is only 193.86 TB Free?"
This is saying how much space would be free in the cluster if you used 'R5 FTT1 Thin' policy for all current data instead of what is currently used.
You mentioned "142.2 TB provisioned Disk" - just to clarify, 'provisioned' generally means the full size of the vmdk e.g. as VM see it e.g. a 500GB vmdk, this doesn't inform of the actual physically written data which could be 1MB or 500GB, this is important as you indicate want to store this with a thin-policy.
The % for Host rebuild reserve and Operations reserve and what they are based on is well explained here - these won't change by you moving more data to this cluster so 142.2 x 1.33 = 189TB is how much that new data should use (assuming by provisioned you meant physically written):
https://core.vmware.com/blog/understanding-reserved-capacity-concepts-vsan