ESXi 6.5 unmap的bug和workaround

豆子最近升级了一下Nimble的存储系统，创建了一个新的LUN，通过ISCSI添加新的datastore， 然后在ESXi 6.5上面执行了一个Storage Vmotion的操作。整个过程都很顺畅，大概迁徙了10T的数据到这个新的LUN上。然后问题出现了。

VSphere VCenter上显示原先的Datastore已经清空了，但是在我的LUN上，仍然显示占据了6.6T的存储空间！

在ESXI 6里面，这个问题很正常，因为就是这么设计的，用户需要手动执行esxicli 命令来手动unmap 释放的空间。

https://blog.51cto.com/beanxyz/2064459

ESXi6.5 号称能够自动在后台自动执行unmap的操作，但是为啥不工作！

豆子等了2天都没反应，然后于是干脆自己手动执行一遍命令，等了1天，还是毫无反应？！

没法子，只能和厂商技术支持联系了。对方的工程师远程看了半天，最后的结论是这个是Vmware的一个尚未正式记录的bug。这个bug Nimlbe作为合作伙伴已经提交过了。

厂商工程师给我的回复：
As mentioned, there are no VMs or files opened on MEL-Veeam datastore, volume gets auto closed and if that happens then in-memory data structures gets flushed. Next time volume is opened, these pending unmap info needs to be re-built over time through a scanner and that is a slow process (10X slower than unmap rate). In order to keep the volume open, you need to have some files opened, VM running, this auto-close issue is fixed in the next major vSphere 6.7.

Unfortunately, this issue is not documented. Please try vSPhere 6.7 beta release and confirm if the fix addresses this issue.
Feel free to reference this DCPN case 00047300 in the SR if you contact vmware support for this issue.

Please let us know if you have any further question.

这个bug的缘故是如果对应的datastore为空的话，LUN会自动关掉，然后unmap的指令则无法接受。临时解决的方法是把一个正在运行的VM放入这个datastore，手动执行esxcli storage vmfs -l XXX的命令，这样他会重建unmap的结构。不过这个过程会相当的慢~

另外一个可能的解决方案是升级到ESXi 6.7。豆子大概看了看相关的release note，ESXi 6.7的一个重要改进就是unmap，可以允许用户自定义速度，还可以通过esxtop进行监控状态等等。不过这个新版系统上周才正式发布，所以最好等待一段时间再去尝试。

执行这个workaround之后2天，大概释放了1T的空间，可见这个工程师的建议是有效的