It doesn’t matter if we run vSphere in a home lab, for an SMB or a large enterprise, costs are always a factor into any data center solution.
One of the biggest costs for us is storage, we need storage to run our workloads but did you know there are many ways to keep storage utilization to a minimum?
Thin provisioning your Virtual Machine’s VMDKs is a simple way to reduce the amount of storage you use on your VMFS datastores. Unlike thick provisioning which allocates all space to the VMDK at the time of creating it, thin provisioning only uses up the amount of space it needs to, as determined by the operating system.
This means that you can over-allocate space on your datastores.
This is great but it comes with a warning: If your VMs end up using all the space you allocate to them, then your thin VMDKs will use the same space as if they were thick provisioned. In a scenario where you have overcommitted a datastore, this will cause Virtual Machines on that datastore to stop working.
Fortunately, many IT admins try to keep 20-30% free space on our Virtual Machine volumes, so overcommitting by up to this much wouldn’t generally cause us any issues. Even a 20% storage-saving is quite considerable when looking at the costs associated with it.
In nearly all cases, I’ve recommended thin provisioning for the significant cost benefits provided that good monitoring and alerting is in place and you don’t make your datastores too small. If you already have vRealize Operations, this is a good example of a tool which can do this for you, reliably.
Checking which Virtual Machines are thick provisioned
You can verify in the vSphere UI on a per-VM basis as to which disks are thick or thin provisioned:
You can also use PowerCLI to gather this information:
Get-VM | Get-Harddisk | Select Parent, StorageFormat
The output looks something like this:
Converting between thick and thin provisioned VMDKs
The easiest way to convert a thick VMDK to thin is via a simple Storage vMotion:
You can also vMotion a VM with PowerCLI, changing the disk format at the same time:
Move-VM -VM VN-NAME -Destination ESXI-NAME -Datastore DATASTORE-NAME -DiskStorageFormat thin
Automatic Space Reclamation with VMFS6
You might be thinking that if you are already thin-provisioning Virtual Machines that there’s not much else you can do, well you would be wrong thanks to vSphere’s automatic space reclamation.
VMDK storage reclamation
Space Reclamation or TRIM & UNMAP on vSphere has been supported on vSphere for quite some time, but depending on your vSphere version the process was far from automatic.
For a start, initially, space reclamation was not automatic, requiring manual scripts to reclaim space.
It also didn’t support Linux or the older type of snapshot.
Fortunately, with VMFS6 automatic space reclamation is fully supported across more common deployments.
Space reclamation detects when an operating system deletes files (issues a TRIM command). When this happens, vSphere removes the space from the underlying storage, VMFS6 in this case although there is suppose for NFS depending on your vendor’s supportability.
Let’s have a look at this in action:
In the lab, I have a Windows Server 2016 Virtual Machine which according to vSphere is using 13.1GB of VMFS space. Its provisioned capacity is 40GB but it’s thin provisioned which is why only 13.1 GB is used on the datastore.
Next, I uploaded a large file to the Virtual Machine.
After a short while the UI updates the storage usage metric:
Finally, I deleted the file and waited for the UI to refresh, we can see the space usage by the VM on the VMFS6 datastore is reduced.
What I found interesting is that the space usage after deleting the test file resulted in less space than was originally used. I can only assume there were some logs or other files being removed at around the same time!
Storage Array Space Reclamation
But what about the storage array? – There is good news here too.
In the past, if you used thin provisioning on your storage array pools then you might have noticed that over time, all the provisioned LUNs end up looking full, even if they are not.
With VMFS v6 the array can now be notified when data is deleted from a VMFS6 datastore. This means that the storage array can now be oversubscribed. While there is risk in doing this (imagine if all datastores suddenly became full), this risk can be mitigated, as with thin provisioning of VMDKs, with good monitoring and alerting practices.
vSAN Space Reclamation
vSAN as of 6.7 Update 1 supports automatic TRIM & UNMAP space reclamation. This means that when thin provisioned VMDKs are written to by the Guest Operating System, the think VMDK will expand. More importantly, the VMDK will now shrink in size when files are deleted from the Guest OS. This can be very useful in VDI environments as an example.
This is the same high-level view of space reclamation that is also available on VMFS6 datastores with Virtual Machines running both Windows and Linux operating systems.
This is almost common sense but if you have old Virtual Machines lying around which are there for archive or “just in case” purposes there are things you can do here too.
- Consider backing those VMs up and deleting them from your primary storage.
- You could move those VMs to slower, cheaper storage or local datastores to not use up valuable, more expensive storage array-based storage.
- Thin provision these VMs and store them on a dedicated datastore
We might also have some unregistered Virtual Machines or VMDKs which have been detached from Virtual Machines in the past. You can use tools such as RVTools to detect such things.
If you have vRealize Operations, take a look at the dashboard I uploaded to the Solutions Exchange which helps identify old VMs: https://virtualg.uk/using-vrealize-operations-to-identify-zombie-vms
Saving money is a big deal for most businesses, it allows them to be more profitable or frees up funds to be spent on other things within the department. Recommending such things to your manager can also make you look good at work!
It is clear that VMware is dedicated to helping us get the most out of our hardware investments. vSphere continues to improve storage reclaim options for us, natively in their product which are welcomed improvements.