Long live VMFS3! VAAI enabled storage, ESXi 5.x and above, thin VMDK files = Not able to recover unused (null) space.

Basically we still need a VMFS3 datastore as a "AUX" to shrink disks.

This is interesting! Basically, logically, in plain English.. what happens is since the VAAI datamover used is not at the ESXi layer, the storage doesn't know what is on the VMDK and _has-to_ copy everything. There is no chance for ESXi layer to figure out which blocks to drop!

The conditions - ESXi 5.x onwards (VMFS5) + VAAI capable/enabled storage, Thin Provisioned VMs

"...When the source filesystem uses a different  blocksize from the destination filesystem, the legacy datamover (FSDM) is used. When the blocksizes of source and destination are equal, the new datamover (FS3DM) is used. FS3DM decides if it will use VAAI or just the software component. In either case, null blocks are not reclaimed"

Thanks to Boon Hong​ for highlighting this.

http://kb.vmware.com/kb/2004155

Heartbleed remediation for vCenter (build 1750787), ESXi (build 1746018), Web Client Integration plug-in (build 1750778), vSphere C# client (build 1746248)

Glad to report the vCenter update went without a hitch on my home lab. As aways YMMV.

Updating to vCenter 5.5.0u1a - install in sequence following custom install. No reboot required. All other components remain the same as 5.5.0u1

Versions of updated 5.5.0u1a vCenter SSO, Inventory Service, Web Client and vCenter Server.

VMware Update Manager will be restarted during installation.

Web Client Integration Plugin will still have the same name as 5.5.0u1 but the build/version has been updated

vSphere Client updated to build 1746248. Not sure if it's only my home NAS that's slow but it looked like before updating, the stats and info page for ESXi hosts would not display properly.

vSphere Client not displaying ESXi stats properly (before updating; could also be caused by my storage backend)