Like most of us, you are probably using thin-provisioned LUNS on your storage system. If you’re using an all flash array (AFA), like EMC’s XtremIO, then you’re also probably using a pretty awesome in-line deduplicating and compressing storage system. I did not know until recently that unused storage blocks on a VMFS datastore are NOT automatically “released” back to the XtremIO once you delete something. For example. You have a 100GB VM on VMFS on XtremIO. If you delete that 100GB, the vmware esx host does not automatically tell the XtremIO that it can have those 100GB back.
You have to run what’s called an “UNMAP” command. Here’s the VMware KB with all the details. While you can do this with PowerCLI or with EMC’s VSI plugin to make your life easier (both are options I’m going to explore next), the primary way to do this is by SSH to one of your hosts.
then run a command like this: esxcli storage vmfs unmap -l XIO2-VIEW-Desktops4
Then you wait. It took about 10 minutes per LUN for me. It also uses up a good amount of Bandwidth on your storage system. I would definitely do this in slow periods of usage to avoid latency on your virtual machines.
I started with 4.068TB in use (54% of my XtremIO 10TB X-Brick). I finished with 2.495TB in use (33% used). So I reclaimed 1.573 TB! See comparison chart below.
**Your results will vary based on what you have on your XtremIO/AFA, and how often that data changes. We are hosting 390 linked clone virtual desktops and 65 servers on our XtremIO. I saw the most space being reclaimed after running this command against my Desktop LUNs (over 1TB)**
**ALSO – you have to follow some additional steps FIRST if you have removed a significant amount of data from the guest OS in the VM (like deleting 500GB of data from Windows). The above unmap process does not reclaim those 500GB from the XtremIO without running SDELETE inside of Windows FIRST. There’s more info on the web about running SDELETE and it is available from Microsoft here.**