Home > Blogs > VMware vSphere Blog


VAAI Thin Provisioning Block Reclaim/UNMAP Issue

A performance issue has recently been discovered in the VAAI Thin Provisioning Block Reclaim mechanism introduced in vSphere 5.0. This feature allows an ESXi host to tell the array that a block on a Thin Provisioned datastore is no longer needed and can be reclaimed. This could be the result of a file delete operation, a Storage vMotion, a Snapshot Consolidate operation, etc. I blogged about the reclaim feature some time ago.

What we have found is that the time taken to complete the Block Reclaim operation could perform poorly.

Unfortunately, in light of this performance issue, VMware are advising that the UNMAP feature be disabled in ESXi 5.0 until further notice.

A KnowledgeBase article, 2007427, has now been published and contains an additional description of the issue and details on how to disable the UNMAP feature. Click here to read the KB.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage

12 thoughts on “VAAI Thin Provisioning Block Reclaim/UNMAP Issue

  1. Ashley

    This is great information to know. I believe we picked up this issue on a Nexenta powered array. There are a fair amount of reports of very slow boot times with iscsi and VSphere5.. could you perhaps please take a look at some of these and post another kb article/fix?

  2. Chogan

    I don’t believe this to be the same issue Ashley. This issue should only arise with file delete or storage migrate operations on VAAI capable arrays, which will allow block reclaims to take place.

  3. Ashley

    Is there any update on the SCSI UNMAP status in ESX5i? Has VMware got any closer to understanding when the UNMAP feature could be re-enabled again?

  4. Chogan

    Hi Ashley,
    My understanding is that our storage partners need to run a new set of test to make sure that the primitive performs optimally. I don’t have a timeframe, but the best thing to do is to keep checking the KB article for an update. I’ll also update the blog article when I hear something.

  5. Schistad

    I know that the KB article still isn’t updated, but are you able to shed some more light on this issue?
    For instance, from the wording of the KB article it sounds like certain platforms implemented the T10 UNMAP command in such a fashion that it is a “blocking” command which can take a long time (in latency terms) to respond, and this breaks storage vmotion badly in that it has to wait for the response before proceeding to the next block in the pipeline.
    Okay: But reading between the lines this suggests that there may be other vendors that have implemented this in a properly asynchronous fashion, and for these vendors the thin reclaim can be safely used.
    I guess you aren’t at liberty to divulge who’s who here, but am I on the correct track here? :)

  6. Chogan

    Hi Schistad,
    When vSphere 5.0U1 releases, we will hopefully have a solution to this issue which will work for all interested parties.
    I can’t really say anymore than that at this time.

  7. Ashley

    Hi Cormac, Is there any clarity on vSphere 5 Update 1 release dates and what storage related changes we should be expecting?

  8. bharat

    Is there a specification document for enabling VAAI block capabilities in a storage array.
    I am working to enable VAAI block primities (ATS, UNMAP, XCOPY, WRITE_SAME) over our storage array but ESX5.0 doesn’t recognise our storage array a VAAI capable. I am following vAAIspec-v7.1-ESX41, I tried with T10 specs also but no success so far.

    Can anyone point me out to the exact document I needed to follow.

Comments are closed.