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:
vsan.unmap_support yourclustername -e
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:
My name is Amine El Badaoui and I currently live in Aylesbury, a small town in the south east of England
I have been working in the IT industry for few years now and specialise in VMware virtualisation, data centre infrastructure and cloud technologies. Over the years I have obtained numerous industry certifications from Microsoft, Netapp and VMware.I currently work as a VMware Product Engineer @ https://www.rackspace.com/
This blog represents my random technical notes and thoughts. The thoughts expressed here do not reflect my current employer in anyway.