VAAI Space Reclamation(SCSI_UNMAP) myth buster

Discussion created by wen Employee on Mar 11, 2013
Latest reply on Jun 3, 2014 by abiren

here's a series of Q&A started by our famous Matthew Andersen


  • Q.  First does the VMDK need to be thin provisioned?   I am finding conflicting info on this.  I would think it would just be the SAN Volume which is what we do.   If it has to be thin provisioned the follow up question is what is the overhead of thing provisioned datastores at the VM level?  What is our preferred think/thick/eager/lazy method? By reading the BPG it should be Thick Eager Zeroed.  However since there is no mention of SCSI UNMAP I am not sure this is the case anymore. 
    • Answer: Array volume needs to be thin provisioned – the VMDK format does not matter in this case as we are freeing up space for the VMFS volume.  Keep in mind this operation is manual, meaning you need to invoke "vmkfstools" CLI to clean up space; refer to vmware KB 2014849 for complete instructions.  Regarding thin vs. thick vs. Eagerzerothick, eagerzerothick format will provide the best performance and it’s recommended for Exchange/SQL or any app that has larger write ratio – thin & thick work equally well, and with VAAI WRITE_SAME primitive, the performance difference between the formats is probably not that significant.

  • Q.  We have to run vmkfstools to reclaim space correct? Does anyone have any stats on how expensive this is on the array side?  Or some perf numbers of how long this takes for certain datastores.
    • Answer: yes, see above KB for further details; we have not done any testing in TM to study the overhead from array side.  Per Eric Forgette it may take some time to see the effect of the space reclaim on the Nimble volume.  This is because the garbage collector wont aggressively reclaim this space space if it isn't needed.

  • So if I read the vmkfstools docs correctly we need to have enough free space to unclaim the % of free blocks we want to free.   So we should allow some larger extra % of free space on the volume for this task.
    • Answer: Correct, ESX creates a file and runs the unmap for the block range of the file so some amount of free space is needed for this operation.  Last but not least, (just a warning) you wont get any space back from VMFS unless you've storage vmotion a vm off the datastore or deleted some datastore level files.  In other words, you cannot unmap space in guest filesystems using this feature