Determining if an array supports automated unmap in vSphere 6.5

Many of you will be aware of the new core storage features that were introduced in vSphere 6.5. If not, you can learn about them in this recently published white paper. Without doubt, the feature that has created the most amount of interest is automated unmap (finally, I hear you say!). Now a few readers have asked about the following comment in the automated unmap section.

Automatic UNMAP is not supported on arrays with UNMAP granularity 
greater than 1MB. Auto UNMAP feature support is footnoted in the 
VMware Hardware Compatibility Guide (HCL).

So where do you find this info in the HCL? I’ll show you here.

First, navigate to the VMware HCL – Storage/SAN Section. Click here for a direct link.

Next select ESXi 6.5, the vendor of the array, and in the features section, Thin Provisioning. Finally click on “Update and View Results”. This will provide a list of supported arrays and models. In this example, I selected DELL as a vendor. It produced a range of Compellent and EQL arrays. I choose Compellent Storage Center with Array Type FC, as shown below:

vcg-compellent-fcNow, if I expand on the 6.5 supported release, I can see the tested configurations, including the supported driver, firmware, multipathing and fail-over policies associated with this array config.

vcg-compellent-fc-configsIf I expand any of those entries, I will see the footnote entries. In this example, let me select the FW version 7.1, with 16GB FC Switch and lpfc HBA.

vcg-fc-footnotesAnd there you can see the statement in the footnotes that this configuration support automatic storage space reclamation on VMFS6.

Let’s compare this to an iSCSI configuration using the same arrays. Here is the list of iSCSI Compellent configurations, once more detailing the supported driver, firmware, multipathing and fail-over policies associated with this array config.

vcg-compellent-configsLet’s select the 7.1 firmware version as before, and examine the footnotes:

vcg-iscsi-footnotesAs you can clearly see, there is no mention of automatic unmap/space reclamation support in the footnotes in this example. Therefore unsupported.  Note: Since this article was published, the HCL listing shown above has been updated to reflect the automatic unmap certifications are completed on Compellent, and are now supported!

As you can see, support statements around unmap will continue to change, so check back regularly to see whether or not your array vendor has passed the certification tests required to support automated unmap. Alternatively, speak to your array vendor to find out where they are on the certification path.

16 Replies to “Determining if an array supports automated unmap in vSphere 6.5”

      1. Why is that? I mean, vSAN is certainly the future, and VMware controls the entire stack- no 3rd parties to work with. Why isn’t it a priority for vSAN?

        1. That’s a question for the vSAN product managers, who prioritize which features get added to which release. I’ll let them know that you feel this should be added sooner rather than later Carlo, but all I can say is that it is on the radar for inclusion in vSAN at some point in the future.

  1. Great blog, Cormac.

    Excited to confirm that as of NimbleOS 3.6 (released December 2nd) – we now support auto-SCSI UNMAP for all Nimble arrays 😀

    1. Nick, It’s great to hear that it is supported on all Nimble arrays, but does Nimble allow adding a VMFS6 datastore using their web client integration?

      We are running vSphere 6.5 with our Nimble running 3.6, but there doesn’t appear to be a way to select VMFS 6 with the VMware integration (defaults to VMFS5). Let me know if this requires manual setup, will be an option with a future release, or is an option now.


  2. I looked at both 3PAR 8000 and VNX 7600 for FC block, NMP, there is conflicting or missing info:

    – 3PAR 8450: Really old release 3.2.1 has footnotes and supports automatic reclaim, but for 3.2.2 which has been out of a long time makes no reference.

    – VNX 7600: Has footnotes and says it’s supported with NMP (but not with PowerPath) on block 05.33 with 16GB FC switch & VMW_SATP_ALUA_CX. However the same code SATP and device driver says not supported when using an 8Gb FC switch. That’s inconsistent as 8 vs 16 Gb switch should not matter.


    1. Can you raise this with you HP and EMC contacts Ben?

      If the information is inaccurate, they have access to the folks who are responsible for maintaining these footnotes in the HCL.

      For all I know, this could be completely accurate.

      1. Confirmed with the cert team, all certs were submitted and accepted by VMware prior to the GA of 6.5, we’ll check with them to get it cleared up and the HCL updated.

  3. Hi Cormag,
    great post with very important clarification detail.

    To be honest, I assumed it works for any storage supporting UNMAP. Just another proof, that assumptions are very risky.

    Is there any way (for example esxcli storage vmfs unmap, scsi sense code in vmkernel.log, etc.) how to determine if automatic unmap is supported or not on particular storage which is already connected to ESXi?

    It would be very useful especially on our home labs where we are running not supported storages like Synology, FreeNAS, etc.

    Or the footnote from HCL is the only way?


    1. Well, you have the “esxtop” VAAI stats. The DELETE_F column will show if UNMAPs are failing. I don’t know of a way to proactively tell if it works or not.

Comments are closed.