Within vSphere 4.x and later (through the gui) thin provisioned VMFS volumes are an option. For those who have shared storage many storage providers also provide the option to provide Thinly provisioned LUNs. So it is foreseeable one could provision a 100GB VMDK thinly on a 1TB thinly provisioned LUN but then if the VMDK is only using 1GB then the LUN should be using close to 1GB of data assuming it is not blown out by data usage.
The Test
For testing purposes I’m using a 60GB thinly provisioned VMDK with approximately 50% fragmentation (10k files with 90k fragments) . With using vSphere 4.1 Update 1 and a HP Lefthand P4500 cluster running SAN I/Q 9.0.
Diskeeper has a product called V-Locity 3 which is suppose to offer great defragmentation options for the Thin on Thin world. The question is does the boat hold water?
Well after testing a number of LUNs there are some truth to it’s functionality and some dead weight. When looking back at the physical world with Windows Server installed on bare hardware Diskeeper Server Edition works at both preventing fragmentation to a point and defragmenting. When we look at VM’s instead Intelliwrite (http://www.diskeeper.com/blog/post/2009/11/20/Inside-IntelliWrite-technology.aspx) everything still works as expected. When looking at the automatic defrag feature, we then balloon out the volume and if left to run 24×7 would fully balloon the volume.
This is where V-Locity is suppose to step in where you take Diskeeper Server falls short for virtual servers. Be for-warned Diskeeper Administrator is required to gain full functionality of software to take advantage of (V-Aware and CogniSAN to prevent over utilization of the given VM Server or SAN). While there are some other features the one feature I was looking at in particular was the Automatic zeroing of free space
Automatic Zeroing of Free Space is an interesting feature basically offering their version of sDelete.exe at a file by file level. By design you are suppose to run the automatic defrag feature during a relatively idle period in the datacenter and the rest of the time the Automatic zeroing will reclaim the space used. If and only if a storage vMotion to a different block size occurs the space will really be reclaimed.
So as expected it does work but I would check your cost/benefit analysis before buying V-Locity for the entire enterprise. When looking at my every day production environment, I can only see three or four heavy usage systems actually benefiting significantly from this software. While the rest would run the regular version of Diskeeper Server purely for Intelliwrite.
vSphere 5.0
Now what about all the talk of vSphere 5 adding in a new version of Array Integration (VAAI) which takes care of the reclamation without a vMotion? Well, it’s there but as it currently stands there are two big issues with it:
1) VMWare has published KBs instructing everyone to disable it due to performance issues. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007427)
2) Some SAN appliances don’t support the new feature – which is my current problem
As for number one, test and see how bad the performance hit is in a lab environment first before trying it in production. Technically I don’t see why the features is recommended to be just disabled, you could have the feature disabled except during some scheduled times enabling it for a few hours at a time allowing at least a partial benefit from the feature.
For number two, start leaning heavily on your SAN providers to provide the functionality. As of this writing SAN I/Q 9.5 doesn’t support disk space reclamation (sometimes referred to as UNMAP). Hopefully this feature it will be out in the next release in a production environment scripting out the creation of LUNs to perform a storage vMotion to then finally performance destroy the existing LUN requires heavy I/O load on the SAN and an ugly solution for automation.
Conclusion
For myself I find this the biggest deal-breaker with the software isn’t the software itself as it works as designed. Unless the entire stack supports reclamation as a whole the product is *nice* but not worth it in large deployments and time consuming in small deployments.