Posted by on Nov 9 2015 (updated on Jul 6 2016) in • • • • • • This is one of those home lab housekeeping duties that I just hadn't gotten around to. Kind of gets your attention when your datastores start to fill, or you can't Storage vMotion VMs in. Eventually you get weary of the warnings, and you certainly don't want to get to 100% full, when VMs get frozen. So it was time to dig in and fix it.

Windows 7 (32-bit and 64-bit) Windows 8 (32-bit and 64-bit). Reboot your Windows system. Problems using vmkfstools to create VMFS3 volume when using VML name of LUN.

I have a VM that I occasionally use for Gateway duties, at least until I get my wired straight to my cablemodem again. This was my last of my home lab's VMs stuck back in Windows 7. I was curious how an upgrade would go, straight to Windows 10. Of course, I also wanted to be able to roll-back very easily, if things went sideways. So I grabbed a snapshot of the VM before I began, as a very quick backup of sorts. I then mounted the Windows 10 file, and ran through the usual upgrade process.

After I was comfortable that all was well with the VM, and finished up some to Hamachi's gateway function to get it going again, I then deleted all the snapshots. This level of commitment also removed my instant way to revert to Windows 7. I next looked at the C: drive in the Windows 10 VM after the upgrade, and it showed 42GB of data. After running the 'Disk Clean-up for C:', I now had 21GB of data, halving my storage need. But guess what? The VMFS datastore space in use indication didn't drop at all.

And this was precious SSD storage, where I leave all my most used VMs are left running. The dirty secret here is that here is no automatic space reclamation in this scenario. That's right, your VMFS filesystem that has a bunch of thin provisioned VMs will invariably run into trouble, especially obvious with smaller SSDs. All my VMs that I leave running on SSD storage are thinly provisioned, even VCSA. That way, the VM 'thinks' it has, say, a 750GB drive (could go all the way with EFI virtual BIOS type).

The physical SSD is actually much much smaller, merely 256GB in this case, actually. Using thin provisioning for everything, I don't have to try to figure out in advance how much storage the VM will ever need. This tends to waste space, and increases the hassle, having to grow that Windows VM's C: drive.

My alternative means I do have to monitor datastore usage careful. Those are both topics for another day. For now, let's just say I'm done with thick provisioning in my home lab, even on spinning drives, with my whole storage strategy laid out here.

I don't want to set side storage that I wind up never using, and I've noticed that SSDs are fast enough that the impact of not pre-allocating/thick provisioning isn't noticeable. Technically, you could Storage vMotion to another drive, then Storage vMotion back again, as discussed by others folks in disbelief about local disk reclaim, over in the VMware Community forums. What if I not only don't want to do the double-vMotion workaround, or if I don't even have a drive with enough room available to do such a time consuming, multi-step workaround? So started the Googling, and some more Googling, to discover many complicated ways to do reclaim. Along with many ways that are not applicable, such as the VAAI Primitive called UNMAP that just isn't available on local datastores, that part of the 'HW acceleration' you see on SAN LUNs and iSCSI/NFS NAS datastores, see also and: • Back to local disks. Another of the reclaim methods that I read about somewhere suggested I turn off Change Block Tracking on the VM, which seemed to me would give backup products such as Veeam or NAKIVO issues some fits later on, especially for my huge Windows 2012 R2 Essentials VM, with several terabytes of PC backups and video projects on there. Can it really be this difficult?