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: @VMwareStorage
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?
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.
thanks for that. I fully understand that the SCSI unmap issue was different to the long boot times. I see you have posted a great URL on the slow boot time – thanks. http://blogs.vmware.com/vsphere/2011/10/slow-booting-of-esxi-50-when-iscsi-is-configured.html
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?
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.
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?
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.
Thank you, I appreciate the feedback. Fingers crossed that you’ll chase the gremlins out by U1
Hi Cormac, Is there any clarity on vSphere 5 Update 1 release dates and what storage related changes we should be expecting?
You just needed to wait one more day Ashley
5.0U1 is now out and we have an update on the VAAI UNMAP issue which I describe here – http://blogs.vmware.com/vsphere/2012/03/vaai-thin-provisioning-block-reclaimunmap-is-back-in-50u1.html