Bean recently upgraded Nimble's storage system, created a new LUN, added a new datastore via ISCSI, and then performed a Storage Vmotion operation on ESXi 6.5. The whole process was smooth, and about 10T of data was migrated to this new LUN. Then the problem arises.
VSphere VCenter shows that the original Datastore has been emptied, but on my LUN, it still shows that it occupies 6.6T of storage space!
In ESXI 6, this problem is normal, because it is designed that way, the user needs to manually execute the esxicli command to manually unmap the freed space.
http://blog.51cto.com/beanxyz/2064459
ESXi6.5 claims to be able to automatically perform unmap operations in the background, but why doesn't it work!
Douzi waited for 2 days without any response, and then simply executed the command manually. After waiting for 1 day, still no response? !
There is no other way but to contact the manufacturer's technical support. The engineer of the other party watched it remotely for a long time, and finally concluded that this is a bug of VMware that has not been officially recorded. This bug has been submitted by Nimlbe as a partner.
厂商工程师给我的回复：
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.
The reason for this bug is that if the corresponding datastore is empty, the LUN will be automatically turned off, and the unmap command will not be accepted. A temporary solution is to put a running VM into this datastore and manually execute the command esxcli storage vmfs -l XXX, so that it will rebuild the unmap structure. But this process will be quite slow~
Another possible solution is to upgrade to ESXi 6.7. Douzi probably looked at the relevant release notes. An important improvement of ESXi 6.7 is unmap, which allows users to customize the speed, and can monitor the status through esxtop, etc. This new version of the system was only officially released last week, though, so it's best to wait a while before trying it out.
2 days after the implementation of this workaround, about 1T of space has been released. It can be seen that the engineer's suggestion is effective.