0

vSAN 6.7U1 Storage reclamation

When deploying a VM on a VSAN datastore, it is thinly provisioned unless the capability ‘Object Space Reservation’  is specified in the VM Storage Policy, otherwise vSAN will commit only the storage space needed for its initial operations. This is all good as there is definitely a use case for thin provisioning, however this does introduce a couple of challenges.

A grown VMDK will not shrink even when files within the guest OS are deleted. Add to this that quite a few file systems will always direct new writes into free space, so a set of writes to the same block of a single small file will eventually use significantly more space at the VMDK level. Not great! There are painful workaround to this situation ie storage vmotion or powering off the VM in question. This is not just time consuming and disruptive but also performance intensive.

Enter vSAN 6.7U1!

vSAN 6.7U1 introduces automated space reclamation support as it’s fully aware of TRIM/UNMAP commands sent from the guest OS and can therefore reclaim the previously allocated storage as free space.

This feature can be enabled via rvc using the commands below:

To enable

vsan.unmap_support yourclustername -e

To disable

vsan.unmap_support yourclustername -d

I would use this feature with caution as it does carry a performance impact, especially if your environment has a high number of deletions.

I hope this post was helpful. Thank you for reading.

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

Sharing is caring!

Leave a Reply

Your email address will not be published. Required fields are marked *