Last week VMware released vSphere 6.5 U2 in the midst of Dell Tech World so I didn’t have a chance to post this. Normally I don’t call out individual updates for vSphere, but this one contains an important fix to UNMAP that one of our customers discovered. The issue occurs only when attempting to run a manual UNMAP in the following environment:
- vSphere 6.5
- VMFS 6
- zeroedthick or eagerzeroedthick vmdks
As you can see it does not impact thin vmdks or VMFS 5, nor automated UNMAP. So how do you know if you have the problem? Basically when you run the esxcli storage vmfs unmap command, it finishes quite quickly and very little storage is reclaimed. If you are monitoring VAAI stats you will also see few UNMAP commands issued.
So why is VMware not issuing enough UNMAPs? Well internally to the VMFS there are two types of filesystem blocks – large (LFBs – 512MB) and small (SFBs – 1MB). In vSphere 6.5 on VMFS 6, VMware is not processing LFBs – the majority of blocks. Since thin vmdks are all SFBs, this bug does not impact them.
Fortunately, as this bug was identified before vSphere 6.7 was in final RTM, we managed to get it added to the GA release of that so you could apply U2 or upgrade to 6.7. Obviously if you use automated UNMAP only or thin vmdks the individual fix is unnecessary, but U2 does have lots of other fixes. This particular bug is shown in the fixed issues of the release notes. It’s always best practice to apply the updates to vSphere as they are roll-ups and have both functional and security fixes.