Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
An ESXi host disconnects from vCenter Server. In the /var/log/vpxa.log file, you see entries similar to: YYYY-MM-DDTHH:MM:SS.SSSZ [2A330B70 info 'commonvpxLro' opID=778b566a-e7] [VpxLRO] -- BEGIN task-internal-402632 -- -- vpxapi.VpxaService.queryBatchPerformanceStatistics -- 05a84037-c508-e746-d9ae-f6757232865c In the /var/log/vmkernel.log file, you see entries similar to: YYYY-MM-DDTHH:MM:SS.SSSZ [40440B70 info 'Vimsvc.ha-eventmgr'] Event 530430 : /usr/lib/vmware/vpxa/bin/vpxa crashed (1 time(s) so far) and a core file might have been created at /var/core/vpxa-worker-zdump.000. This might have caused connections to the host to be dropped. YYYY-MM-DDTHH:MM:SS.SSSZ cpu0:6126820)User: 2888: wantCoreDump : vpxa-worker -enabled : 1 2016-02-17T05:29:33.367Z cpu0:6126820)UserDump: 1820: Dumping cartel 6123450 (from world 6126820) to file /var/core/vpxa-worker-zdump.000 ... YYYY-MM-DDTHH:MM:SS.SSSZ cpu0:6126820)User: 2888: wantCoreDump : vpxa-worker -enabled : 1 YYYY-MM-DDTHH:MM:SS.SSSZ cpu0:6126820)UserDump: 1820: Dumping cartel 6123450 (from world 6126820) to file /var/core/vpxa-worker-zdump.000 ... YYYY-MM-DDTHH:MM:SS.SSSZ cpu18:6126820)UserDump: 1944: Userworld coredump complete. In the /var/log/syslog.log file, you see entries similar to: YYYY-MM-DDTHH:MM:SS.SSSZ Unknown: out of memory [6123450] Notes: The cartel ID (6123450 in the preceding logs) should match between the vmkernel.log and syslog.log files.The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.
ESXi host losing connection to vCenter Server is resolved in ESXi 5.5 Patch 08 and ESXi 6.0 Patch 03.
This issue occurs when too many performance counters are being registered on the ESXi hosts vpxa process causing the process to run out of memory.
This is a known issue affecting ESXi 5.5 and 6.0. This issue is resolved in ESXi 5.5 Patch 08 and ESXi 6.0 Patch 03. For ESXi 5.5This issue is resolved in ESXi 5.5 Patch 08. For more information, see VMware ESXi 5.5, Patch ESXi550-201608401-BG: Updates esx-base (2144361)For ESXi 6.0This issue is resolved in ESXi 6.0 Patch 03. For more information, see VMware ESXi 6.0, Patch ESXi-6.0.0-20160804001-standard (2145667) To work around this issue, increase the default memory allocation to the vpxa process on the ESXi Host. Note: This workaround may only reduce the occurrences of this issue. Connect to the affected ESXi host with an SSH session.Run this command to set the grpID of the vpxa process to a variable: grpID=$(vsish -e set /sched/groupPathNameToID host vim vmvisor vpxa | cut -d' ' -f 1) Run this command to increase the max memory allocation of the vpxa process to 400MB (default value is 304): vsish -e set /sched/groups/$grpID/memAllocationInMB max=400 minLimit=unlimited Verify that the max memory allocation of the vpxa process is changed: vsish -e get /sched/groups/$grpID/memAllocationInMB For example: vsish -e get /sched/groups/$grpID/memAllocationInMB sched-allocation { min:0 max:400 shares:0 minLimit:-1 units:units: 3 -> mb } Note: This setting does not persist across reboot.
To be alerted when this document is updated, click the Subscribe to Article link in the Actions box.. VMware ESXi 5.5, Patch ESXi550-201608401-BG: Updates esx-base ESXi 5.5 或 6.0 主机与 vCenter Server 断开连接VMware ESXi 6.0, Patch ESXi-6.0.0-20160804001-standardESXi 5.5 または 6.0 のホストが vCenter Server から切断される