As some of you are probably already aware, one of the storage-related features added to vSphere 5 is support for the SCSI UNMAP command. While you would normally want this functionality enabled, there could be instances where you might want to disable this functionality. Unfortunately, there’s no option in the user interface to enable or disable SCSI UNMAP support.
However, you can use esxcli to enable or disable UNMAP support:
esxcli system advcfg setvalue --int-value [0|1] --option /VMFS3/EnableBlockDelete
Setting this value to 0 disables SCSI UNMAP support; setting the value to 1 enables it.
Many thanks to Cormac Hogan of VMware and Cody Hosterman of EMC for their help with this command.
Update: I received word back from Cormac that the syntax above was lifted from a beta build; the correct syntax (thanks Nick T!) is as follows:
esxcli system settings advanced set --int-value [0|1] --option /VMFS3/EnableBlockDelete
You can use this command to list the current status:
esxcli system settings advanced list --option /VMFS3/EnableBlockDelete
Thanks for all the comments and additional information!
Tags: Virtualization, VMware, vSphere
-
Feeling pretty dumb here, trying with vMA5 vifp targeted fine. But I get error “Error: Unknown command or namespace system advcfg setvalue”
Even tried over ssh and ESXi shell.
Help anyone?
-
You have to use the VMware vSphere CLI. You can install it on windows or linux, or you can deploy a vMA.
-
Can you please give some examples when you want to disable UNMAP?
-
# esxcli system settings advanced list –option /VMFS3/EnableBlockDelete (default is 1)
# esxcli system settings advanced set –int-value 1 –option /VMFS3/EnableBlockDelete
if you cd into the datastore you can then use vmkfstools to recovery space immediately on a TP datastore by setting the % of space to reclaim
# cd /vmfs/volumes/your datastore
# vmkftools -y “any value from 0-100″ -
Hi Scott,
You can also find this command on pg 188 of the vSphere Storage Guide
-Josh
-
@Arnold: You’d want to disable because of performance issues identified in the Friday release of VMware KB 2007427
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007427 -
What I find interesting is the following excerpt from the KB:
“The implementation and response times for the UNMAP command may vary significantly among storage arrays. This variation of response times in critical regions could potentially interfere with operations such as Storage vMotion and Virtual Machine Snapshot consolidation.”
The above strongly indicates this is storage specific, applies to specific vendors and VMware will try to address it on the host side…
So why is it, that if a vendor has an issue, the rest of the vendors and their customers need to penalized? What’s wrong with this picture?
-
(For those that don’t know, Nick works for NetApp.)
Nick, I think the issue is really more of a support issue—UNMAP is just “on,” a user doesn’t have to do anything to start using it, and suddenly VMware has some customers calling in with errors and issues. I don’t think this has anything to do with—as you put it—”penalizing” vendors, but rather taking a proactive approach to support.
My 2 cents…
-
Scott, Just to be clear, I have no idea as to who is experiencing this issue, for all I know we (netapp) could be one of the vendors, but that would not change my stance on this.
In any case, since “implementations and response times vary between arrays” the proper thing to do thing to do would be to identify the storage arrays that have these types of issues, and instruct vendors to have their customers change the default behavior rather than making a broad non support statement impacting everyone. This would also constitute a proactive support approach.
Cheers
-
Nick, as far as I know EMC has been the only vendor to actually step forward and discuss the matter, but I don’t know if other vendors are actually affected. The KB article does imply that some arrays are not affected; again, though, I don’t know if there are actually arrays that implement this functionality that aren’t affected. I suppose VMware could have taken a different approach, but the impression that I get–and this is just my perspective, so take it for what it’s worth—is that they preferred to err on the side of caution.
Thanks for your response!
-
Seems like HDS Stepped up? Hu did a blog… makes me wonder who is seeing this issue. Glad we use HDS.
-
Oh thank you for this. There’s a bug in our VNX that causes the SPs to panic when this is enabled. Which is sad, since this is a major feature I was looking forward to.
-
KenC, I’d recommend you contact your EMC support team. I believe (although I could be mistaken) that there have been some VNX software updates that affect this particular issue.
Site Sponsors
13 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2011/09/22/hidden-vaai-command/trackback/