YYYY-MM-DDThh:mm:ss.397Z In(18#) vmkernel: cpu##:95538## opID=c1aae###)World: ##: VC opID m1hkp###-21###-auto-gag-h5:70002###-2#-60-#### maps to vmkernel opID c1aae###
YYYY-MM-DDThh:mm:ss.397Z Wa(18#) vmkwarning: cpu##:95538## opID=c1aae###)WARNING: Sched: vm 160089##: 63##: could not create container group, status: Limit exceeded
YYYY-MM-DDThh:mm:ss.397Z Wa(18#) vmkwarning: cpu##:95538## opID=c1aae###)WARNING: Sched: vm 160089##: 63##: could not create container group, status: Limit exceeded
Errors similar to following are noticed in /var/run/log/hostd.log:
YYYY-MM-DDThh:mm:ss.208Z Er(163) Hostd[20996##]: [Originator@6876 sub=SysCommandPosix opID=CSMM-domain-c370915-39762-d### sid=52738### user=vpxuser] Failed to ForkExec /usr/lib/vmware/clusterAgent/bin/clusterAdmin: File too large
YYYY-MM-DDThh:mm:ss.443Z Er(163) Hostd[20996##]: [Originator@6876 sub=SysCommandPosix opID=CSMM-domain-c370915-39763-d### sid=52738### user=vpxuser] Failed to ForkExec /usr/lib/vmware/clusterAgent/bin/clusterAdmin: File too large
VMware NSX-T Data Center
If a very large number of processes are started exceeding the number allowed by the system a large number of times, or if processes fail to start due to lack of their memory resource a large number of times, it may become impossible to start new processes. This issue could cause ESXi host to become unresponsive.
When the ESXi host and its virtual machines become unresponsive to any changes, it prevents necessary updates to the host and edge nodes, ultimately causing the NSX upgrade to fail.
This issue has been fixed in ESXi 8.0u3e. To download the same, click on this link to Broadcom Support Portal
Workaround:
Reboot the ESXi host to restore responsiveness and SSH access.
For further information regarding troubleshooting SSH connectivity issues in ESXi 8.0u3,refer: