A topic I got involved with lately is the ability to run an in guest space reclamation automatically, why is that so important you may ask,
well, let’s assume, you are after a storage array, any storage array, you pay good money for it, right? now, you are probably assuming that by deleting files from WITHIN the guest OS, the capacity will return back to the array right? you are probably assuming that if you delete files OUTSIDE the VM, say, deleting an actual VM from the datastore, the physical capacity will also return back to the array, right?
it won’t, in order to support it, both the guest OS needs to translate UNMAP command to the parental hypervisor or OS and the parental Hypervisor needs to pass on this information to the underlying storage array.
ok itzik, so you are telling me that I may gave GB’s or TB’s of space that I can potentially use but I can’t ??
so what can you do, after all, you just spent good money that you want to put to a use, well, like any answer, it depends…
Microsoft Server 2012 / Hyper-V
IF you are using Windows server 2012 / 2012 R2 as a physical OS or with the Hyper-V role installed on it, you do not need to do anything!, UNMAP is built in to the OS for both physical or “virtual” (Hyper-V is just a role enabled on the parental Physical OS)
File deletion can generate UNMAP operations
As a scheduled task through “Optimize Drive”
Volume initialization (format) can generate UNMAP
if you are using Windows Server 2012, you want to Watch for HotFix 444333 , Resolves serialization of UNMAP in NTFS volumes
2012 R2? – It Just Work.
the plot get’s more complex, back in the vSphere 5.0 era, VMware DID support an automated UNMAP command but it turned out that in rare circumstances, it actually cased data corruption so you now need to do it manually at both the in guest level and the datastore level
you can use a free MS utlitiy called sdelete that you need to run on every VM
the sdelete command started to run
the sdelete command is toward the end of it’s run, note the red arrow, our physical capacity just got bigger!
but it’s not over, right? remember I told you that the datastore also need to be aware of the space reclamation so:
run the vmfstools –y command, it will create a baloon file that will then gets deleted and release the capacity back to the array
more or less the same, the syntax is different, you now should run the unmap command
and if you want to properly run the command against an XtremIO array, you want to run it with the “-n 20000” parameters , so
esxcli storage vmfs unmap -l datastorename -n 20000
01/11/2014 — Update ===
you can now reclaim space at the datastore level using our VSI plugin, see a new post i wrote here
seriously man, do I now need to run sdelete MANUALLY on hundreds or thousands of VMs????
well, there is some hope, you can use a third party which ain’t free like sdelete but will automate, report and consume the capacity for you, the software I was using is from a company called RAXCO and the specific product is “PerfectStorage” ( http://www.raxco.com/business/products/perfectstorage )
let me show you one screenshot from my VDI lab that will tell a thousands words, the lab has been running 2,500 VDI VM’s, persistent desktops, no real users are connected to it but I DO use LoginVSI to generate load on it so temporary windows files DO EXIST.
yes, you are seeing it right, the tool just gave me a full report (which is part of it’s centralized reporting engine) about the fact I can claim back 5.14TB of space!!
“ok but deploying this tool is probably a nightmare and it takes ages”, nope, I used it’s ability to push the msi package and it took me 2 minutes to configure the policy and around 2 hours to push it to 2,500 VMs.
the scanning capability is also very important because it letYOU to decide if you want to reclaim back the capacity or leave it as is and wait for the next scanning reporting, the actual claiming process is very sophisticated as it takes into an account both the guest OS / ESX CPU utilization so it knows to “behave” itself in a virtualized environment, here’s the setting how to do it, they call it, virtualization awareness, it takes into an account not just the kernel CPU and the user Mode CPU but also the Disk I/O, pretty cool in my (humble) opinion1
by the way, PerfectStorage isn’t perfect either, you still need to run the space reclaim command per datastore but running this can be scripted and it’s easier to do then manually running “sdelete” on thousands of VM’s
“hmm, sounds very good but isn’t it up to VMware to fix this?”
yes, it is but currently they do it for VMware VIEW when using linked clones only, they basically enable a new disk format called “sParse_SE or “Flex-SE” if you are using the vCenter web interface
you basically set a “blackout” windows, when they will go and claim the capacity inside of these VM’s
I want to show this from a different angle, here, at XtremIO, we have a tool called “dedupe estimator”, it basically can scan volumes (physical or virtual) and will let you know about the data savings that you can have by moving these voumes to XtremIO
here’s how it look before, scanning two PRODUCTION datastore from a real customer, these datastores have been used for couple of years by now
as you can see, the GLOBAL dedupe and data reduction savings (XtremIO dedupe is global, not per volume..) are around 2:1, not bad but not great either.
after running either sdelete or RAXCO and then running the datastore space reclaim commands on these two datastores, the data reduction has gone up to 4.6:1 !!! that is really good, it means you are buying an EMC XtremIO array but you are getting X 4.6 of what you pay for..
I hope I was able to demonstrate why cleaning after yourself is a good habit, for ALL storage arrays but in particular for AFA’s where the media is more expensive.
I truly hope that one day VMware will support SPARSE-SE as the default vdisk format but until then your best option is to use RAXCO PerfectStorage.