After issuing TRIM or Unmap operations from a guest operating system virtual machines on the same ESXi host experience hanging, lockup, extreme latency, or other undesired impact. THis is often, but not always seen with a sudden increase in CPU utilization for the host the guest is running on.
Risks:
This may result in impact to production operations as the guests cannot operate or may crash.
8.0 builds prior to 8.0 U3 P05 running vSAN ESA.
The vSAN ESA unmap process may result in CPU contention on the host running the VM that issued the unmap I/O.
This is resolved in upcoming releases 8.0 Update 3 P05 and 9.0.
Before these releases are available please follow the workaround process below:
Must be run on all hosts
Review performance data to see if the issue is present.
From the guest OS (Linux/Unix command here) use the following on a regular basis vs the default scheduled trim in guest. Recommend using cron to schedule. This would reduce the overall impact on Guest latency for reads and writes when unmaps are sent alongside with them.
date; /sbin/fstrim -a -v --offset 0 --length 1G; date; df -h
If this does not resolve the problem, please pull full cluster logs (all hosts in cluster) and contact Broadcom vSAN support.