A sudden VCHA failover happens without any environmental issues.
vCenter 8
The Active vCenter node experiences severe memory resource exhaustion (an Out of Memory / OOM condition). This resource starvation prevents critical VCHA file replication services from executing, which severs synchronization and ultimately triggers an automatic failover to the Passive node.
A review of the vcha.log files on the originally Active node reveals critical process creation failures due to memory starvation. Specifically, the system cannot allocate memory to fork the rsync process, which is mandatory for VCHA state replication.
Log Excerpt:
2026-05-19T22:44:23.524-04:00 error vcha[54743] [Originator@6876 sub=SysCommandPosix] Failed to fork '/usr/bin/rsync': Cannot allocate memory
2026-05-19T22:44:23.544-04:00 error vcha[54743] [Originator@6876 sub=SysCommandPosix] Invocation of process: '/usr/bin/rsync' failed: Resource error - Process Creation - Error: Cannot allocate memory
2026-05-19T22:44:23.544-04:00 error vcha[54743] [Originator@6876 sub=VchaUtil] Failed to launch system command; '/usr/bin/rsync', args: [...] e: Resource error - Process Creation - Error: Cannot allocate memory
Proactive Maintenance: Implement a quarterly maintenance schedule to reboot the vCenter Server Appliance (VCSA) nodes.
System Upgrade: Plan a maintenance window to upgrade/patch the vCenter environment to the latest supported release.
Over extended periods of uptime, certain vCenter services may slowly consume available RAM or develop minor memory leaks.
A quarterly reboot serves as a standard proactive measure to clear zombie processes, refresh the Java Virtual Machine (JVM) heaps, and reclaim system memory.
Upgrading ensures the environment benefits from the latest code optimizations and bug fixes, as VMware/Broadcom routinely patches known memory-handling inefficiencies in newer releases.