vCenter Server Appliance on Netdata

vCenter '503 Service Unavailable': the vSphere Client will not load

Mon, 01 Jan 0001 00:00:00 +0000

A 503 from the vSphere Client means the reverse HTTP proxy (rhttpproxy) accepted the TLS connection but could not reach the backend it routes to. The proxy itself is healthy. One of its dependents, typically vpxd, vmware-vapi-endpoint, vmware-stsd (STS), or the HTML5 client backend (vsphere-ui), is stopped, still starting, or crash-looping. The error string often reads “Initialization of one of the components failed.”

Running VMs are unaffected. The hypervisor plane keeps scheduling and serving I/O. What you lose is the management plane: DRS stops rebalancing, HA cannot be reconfigured, vMotion orchestration is gone, and provisioning is blocked. The urgency is operational visibility and control, not workload survival.

vCenter 'Cannot complete login due to an incorrect user name or password': SSO failures

Mon, 01 Jan 0001 00:00:00 +0000

The “Cannot complete login due to an incorrect user name or password” string is the exact message operators see in the vSphere Client, in PowerCLI sessions, and in API responses when SSO authentication fails. The text is misleading: the cause is rarely a typo. For a single user it is usually a credential or permission problem. For every account at once it is an SSO/STS infrastructure failure.

The first triage question is scope: does the local SSO administrator account (administrator@vsphere.local) still work? If yes, the STS signing certificate and token service are healthy, and the problem is in an identity source (AD/LDAP) or a service account. If administrator@vsphere.local also fails, the STS infrastructure itself is broken: expired STS signing certificate, clock skew rejecting SAML tokens, or STS memory pressure.

vCenter /storage/db full: vPostgres stops and the whole management plane dies

Mon, 01 Jan 0001 00:00:00 +0000

The vSphere Client returns 503 Service Unavailable. PowerCLI sessions hang and time out. DRS has stopped evaluating, vMotion orchestration is gone, and provisioning fails. Running VMs on the ESXi hosts continue to operate, but the management plane is gone.

The root cause is almost certainly the /storage/db partition on the vCenter Server Appliance (VCSA). This is where vPostgres keeps its data files. At 95% utilization on any partition, VMware automatically shuts down vmware-vpxd to protect the database from corruption. At 100%, vPostgres cannot extend a data file or write a WAL record and crashes. Once vPostgres is down, vpxd has no database and cannot restart.

vCenter /storage/seat full: stats, events, alarms, and tasks outgrowing their partition

Mon, 01 Jan 0001 00:00:00 +0000

The /storage/seat partition on the vCenter Server Appliance (VCSA) holds the vPostgres tables for Stats, Events, Alarms, and Tasks: vpx_event, vpx_event_arg, vpx_task, and the vpxd_hist_stat* rollup tables. In modern VCSA it is a dedicated mount, so it can fill while /storage/db, /storage/log, and / all show healthy utilization. Operators checking only / or the VAMI dashboard’s “VCDB” usage will miss it until vpxd refuses to start.

When /storage/seat crosses 95% utilization, vpxd refuses to come up to avoid database corruption. Without vCenter: DRS stops scheduling, vMotion is gone, HA cannot be reconfigured, no provisioning, no management operations. VMs on ESXi hosts keep running because the data plane is independent of vCenter, but everything that touches vCenter is broken.

vCenter certificate expired: the STS signing cert outage nobody saw coming

Mon, 01 Jan 0001 00:00:00 +0000

vCenter is down. Not “slow” or “degraded.” Down. The vSphere Client shows a white screen or a 503. PowerCLI sessions fail to connect. API calls return authentication errors. ESXi hosts show as disconnected in bulk. Every integration that depends on vCenter (NSX, vRA, SRM, backup products) has lost connectivity simultaneously. VMs on the hosts are still running, but you cannot manage, migrate, or orchestrate anything.

You check the browser certificate on the vCenter URL. It looks fine. Months left. You check NTP. Synchronized. You check disk space. Plenty. Nothing in your standard monitoring explains why the entire management plane went dark at once.

vCenter Server Appliance Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

vCenter Server Appliance Monitoring

What Is vCenter Server Appliance?

vCenter Server Appliance (vCSA) is a powerful, preconfigured Linux-based virtual machine optimized for running VMware vCenter Server and associated services. It is a vital component in managing virtualized environments, providing centralized management of virtualized hosts and virtual machines from a single console.

Monitoring vCenter Server Appliance With Netdata

Netdata offers a seamless and efficient way to monitor vCenter Server Appliance. As a comprehensive monitoring tool, it provides real-time insights and detailed metrics that are crucial for maintaining the health and performance of your vCSA environment. With Netdata’s free and open-source platform, you get simple configurations, interactive visualizations, and a low-overhead monitoring solution.

vCenter vpxd crash loop: the core service that keeps restarting

Mon, 01 Jan 0001 00:00:00 +0000

vpxd is the C++ core of vCenter Server. It holds the entire managed inventory in memory, dispatches every management task to ESXi hosts via hostd, runs DRS, executes statistics rollups, and serves every SDK client (vSphere Client, PowerCLI, Veeam, NSX Manager, Aria Operations, custom automation). When vpxd dies, vCenter is functionally down: no provisioning, no vMotion orchestration, no DRS, no HA reconfiguration. VMs already running on hosts keep running, and FDM still restarts them after a host failure, because HA does not depend on vpxd.

VMware vSphere Operations Guides

Mon, 01 Jan 0001 00:00:00 +0000

How vSphere and vCenter actually fail in production, what the early warning signals look like, and the runbooks for the symptoms you’ll see in real incidents — across both the ESXi data plane and the vCenter management plane.

vSphere monitoring checklist: the signals every host, VM, and vCenter needs

Mon, 01 Jan 0001 00:00:00 +0000

Send this to someone standing up vSphere monitoring for the first time, or rebuilding an alerting setup that pages too often and misses real incidents. It lists the signals worth collecting across the hypervisor plane (ESXi hosts and VMs) and the management plane (vCenter Server Appliance).

vSphere does not fail like a generic Linux box. CPU contention is invisible from inside the guest. Memory goes from fine to catastrophic in minutes once host swapping starts. A datastore at 99% full looks identical to one at 5% full from inside a VM, until every VM on it halts. And vCenter can degrade for weeks before anyone notices, because DRS, HA, and the API quietly keep working until they don’t. Generic CPU/disk/network dashboards miss most of this.