With vSphere 5.0 a brand new primitive has been introduced which is called Dead Space Reclamation as part of the overall thin provisioning primitive. Dead Space Reclamation is also sometimes referred to as unmap and it enables you to reclaim blocks of thin-provisioned LUNs by telling the array that specific blocks are obsolete, and yes that command used is the SCSI “unmap” command.
Now you might wonder when you would need this, but think about it for a second.. what happens when you enable Storage DRS? Indeed, virtual machines might be moved around. When a virtual machine is migrated from a thin provisioned LUN to a different LUN you probably would like to reclaim the blocks that were originally allocated by the array to this volume as they are no longer needed for the source LUN. That is what unmap does. Now of course not only when a virtual machine is storage vmotioned but also when a virtual machine or for instance a virtual disk is deleted. Now one thing I need to point out that this is about unmapping blocks associated to a VMFS volume, if you delete files within a VMDK those blocks will not be unmapped!
When playing around with this I had a question from one of my colleagues, he did not have the need to unmap blocks from these thin-provisioned LUNs so he asked if you could disable it, and yes you can:
esxcli system settings advanced set --int-value 1 --option /VMFS3/EnableBlockDelete
The cool thing is that it works with net-new VMFS-5 volumes but also with upgraded VMFS-3 to VMFS-5 volumes:
- Open the command line and go to the folder of the datastore:
cd /vmfs/volumes/datastore_name - Reclaim a percentage of free capacity on the VMFS5 datastore for the thin-provisioned device by running:
vmkfstools -y <value>
The value should be between 0 and 100, with 60 being the maximum recommended value. I ran it on a thin provisioned LUN with 60% as the percentage to reclaim. Unfortunately I didn’t have access to the back-end of the array so could not validate if any disk space was reclaimed.
/vmfs/volumes/4ddea74d-5a6eb3bc-f95e-0025b5000217 # vmkfstools -y 60
Attempting to reclaim 60% of free capacity 3.9 TB on VMFS-5 file system 'tm-pod04-sas600-sp-4t'.
Done.
/vmfs/volumes/4ddea74d-5a6eb3bc-f95e-0025b5000217 #
Compellent Storage Center already supports unmap. This is a welcomed addition the thin provisioning portfolio.
Is this advanced parameter meant to be hidden, meaning you can’t query the current value by using esxcli? I noticed I was not able to see this parameter when running the “list” operation but as you pointed out in the article, you can update the value to either 0 or 1.
The only way I’ve been able to query it is using the legacy esxcfg-advcfg option:
~ # esxcfg-advcfg -g /VMFS3/EnableBlockDelete
Value of EnableBlockDelete is 0
OR using vim-cmd:
~ # vim-cmd hostsvc/advopt/view VMFS3.EnableBlockDelete
(vim.option.OptionValue) [
(vim.option.OptionValue) {
dynamicType = ,
key = "VMFS3.EnableBlockDelete",
value = 0,
}
]
Also you can use the hidden parameter /VMFS3/BlockDeleteThreshold which allows you to set a pre-defined threshold which by default it’s 10% … I’m assuming you know this already
Come on Ducan. A word about the new license model fiasco.
Agree with John!
I was just playing with the unmap and an EMC VNX tonight (disclaimer: I am an EMC employee). The question of how to recover if the VM moved popped in my head and 15 seconds later I have my answer.
thanks man
nick