Itzikr's Blog

Hi,

if you are a follow of my blog, you know how much space reclamation is a topic that is closed to my heart, in fact, almost exactly an year ago, I wrote this post : https://volumes.blog/2014/04/30/the-case-for-sparse_se/ which I highly recommend you to read if you want to get a full understanding of space reclamation, UNMAP and where is VMware in regards to this.

times are changing and im so happy that in 1 year, VMware had made some changes to UNMAP as well, is only a start but it’s a good one.

so what’s so different?

well, in vSphere 6, a guest VM can now issue an UNMAP and the ESXi host will not block it, is it a new thing?

 The config option, EnableBlockDelete, is not new, it even existed prior to vSphere 6.0 (However description of that config option is changed in vSphere to reflect the actual implementation). However, prior to vSphere 6.0, Windows guests did not do the automatic UNMAPs because on the non-supportability of B2 mode page from vSphere side which is required by the windows 8 and above. vSphere 6.0 implements B2 mode page.

as long as the guest OS follows the alignment requirements reported to them in read-capacity16 and B0 mode page it will work

Caveats / Limitations

it’s not perfect, there are many cases where this will not work:

• unmap of deleted blocks with in VMFS (i.e vmdk deletion, swap file deletion etc), for this you can use the EMC VSI plugin.
  
• Smaller unmap granularity. With existing VMFS version, the minimum unmap granularity is 1MB.
  
• Automatic UNMAP for support for windows version less than Windows 8 / server 2012 (no linux support)
  
• the device at the VM level (the drive) must be configured as “thin”, not “eager zeroed thick” or “lazy zeroed thick”
  

Still ok with you? You just upgraded to vSphere 6 and you are running modern guest OS’s like windows server 2012 and windows 8, great!, see the video I made below