VMware vCenter Server on Netdata

VMware Monitoring Software Without Centralized Data

Thu, 18 Dec 2025 00:00:00 +0000

Netdata delivers per-second VMware monitoring with zero configuration, built-in ML anomaly detection, and 90% cost savings. Monitor vSphere, ESXi hosts, VMs, and hybrid clouds with true real-time visibility.

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/log full: the log-bomb disk death spiral

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

You log in to the vSphere Client and get a 503, or the UI hangs mid-task. You SSH into the VCSA and run df -h: /storage/log is at 100%. The root filesystem may still have plenty of free space, which is why a generic disk-space alert missed it. The VCSA has many dedicated partitions, and they fill independently.

A single failing service can write gigabytes of logs per hour. STS authentication failures, database connection errors, alarm flapping, or a misbehaving SDK client flooding vpxd with errors will take /storage/log from 40% to 100% within hours. Once the partition is full, services that try to log crash. vmon restarts them. The restart itself generates more log lines as the service hits the same fault and tries to log it again. The loop is self-reinforcing, and clearing space temporarily makes the next iteration worse because the service can write again, refilling the partition faster.

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 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 vCenter Server Monitoring

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

VMware vCenter Server Monitoring

What Is VMware vCenter Server?

VMware vCenter Server is a centralized platform for managing VMware vSphere environments. It allows administrators to automate and deliver a virtual infrastructure with confidence. vCenter Server provides essential vSphere and ESXi host management capabilities for IT teams.

Monitoring VMware vCenter Server With Netdata

Netdata offers a real-time monitoring solution for VMware vCenter Server with its robust vSphere collector. This powerful tool allows you to track host and virtual machine (VM) performance statistics, providing valuable insights into your virtual environments.

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 'Virtual machine disks consolidation is needed': clearing the warning without stunning the VM

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

The “Virtual machine disks consolidation is needed” warning means the VMkernel left delta VMDKs on the datastore after a snapshot delete that did not fully commit. The VM is still running, but its writes are going through delta files that were never meant to persist.

The warning is set by VirtualMachine.runtime.consolidationNeeded in the vCenter inventory. It is distinct from the Snapshot Manager view: a VM can have this flag set while showing zero snapshots in the manager, because the flag tracks orphaned files on the datastore, not the snapshot tree.

vSphere active vs consumed vs granted memory: why the percentage lies

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

The “Memory Usage” percentage on a vSphere host summary is one of the most misread signals in infrastructure monitoring. An 85% number that pages you at 3 a.m. may represent a healthy host with no reclamation at all. The same number on a different host may mean VMs are being actively swapped to disk. The percentage alone tells you nothing useful about either state.

The host summary percentage is computed from consumed memory divided by physical RAM. Operators interpret this as demand, but consumed is not demand. It is a high water mark that includes idle pages. To reason about memory pressure you must read consumed alongside active, granted, and the reclamation signals (balloon, compression, swap). This article explains what each metric actually measures, why consumed greater than active is normal and expected, and how to tell a healthy 85% from a crisis 85%.

vSphere CPU co-stop high (%CSTP): the SMP vCPU co-scheduling penalty

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

%CSTP in esxtop is the time a vCPU in a multi-vCPU VM sits halted because the ESXi scheduler is waiting to co-schedule the VM’s other vCPUs. In a healthy environment it is essentially zero. Sustained above a few percent on modern ESXi means a sizing or topology problem, not a performance problem you can tune away.

The classic shape: you give a database 16 vCPUs and it gets slower. The guest OS reports low CPU utilization because the vCPUs are not doing work. They are parked in COSTOP waiting for their siblings. From inside the VM this is invisible. The application runs slowly while the OS reports idle capacity.

vSphere CPU limit hit (%MLMTD): the forgotten MHz cap that silently throttles a VM

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

A VM is slow. The application team reports degraded throughput. You check the usual suspects: guest CPU utilization is high, but that is expected for a busy workload. Host CPU utilization is moderate, nowhere near saturated. %RDY, the standard vSphere CPU contention signal, is moderate. Everything looks healthy from the hypervisor’s perspective, yet the VM is underperforming.

The missing signal is %MLMTD, the CPU max-limited counter. A CPU limit is an administrative MHz ceiling that silently throttles the VM. The guest OS cannot see it. The host has spare capacity. The scheduler is not contended. The VM hit a cap that someone configured and forgot about.

vSphere CPU ready time high (%RDY): VMs starved while the guest looks idle

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

A database VM takes twice as long to run its nightly batch. Application latency pings fire. You SSH into the guest, run top, and CPU utilization sits at 25%. Memory is fine. Disk I/O looks normal. Nothing inside the VM explains the slowdown.

This is the classic signature of CPU ready time in vSphere. The guest OS has no visibility into hypervisor scheduling decisions. When the ESXi CPU scheduler cannot find a free physical CPU for a runnable vCPU, the vCPU waits in the READY state. The guest never learns it was descheduled, so from inside the VM everything looks idle while the hypervisor sees a starved VM.

vSphere datastore latency high: reading GAVG, DAVG, and KAVG

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

High datastore latency is the single most common cause of “everything is slow” in vSphere. Applications time out, guest iowait climbs, and in severe cases VMs lose heartbeats. Storage I/O traverses guest OS, virtual SCSI adapter, VMkernel SCSI stack, storage driver, fabric, and array. A single “latency is high” reading does not tell you where the time is going.

Three counters slice that path into layers: GAVG is what the guest sees, DAVG is what the array reports, KAVG is what the VMkernel adds in between. The relationship among the three is the diagnostic.

vSphere HA 'Insufficient resources to satisfy configured failover level': admission control

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

The error “Insufficient resources to satisfy configured failover level for vSphere HA” is admission control refusing a VM power-on, vMotion, or reservation change because granting it would leave the cluster without enough spare capacity to honor the configured HA failover policy. Admission control is doing its job: protecting the restart guarantee after a host failure.

The cluster may physically hold more capacity than admission control lets you commit. A cluster with 500 GHz of CPU and 2 TB of RAM may only let you deploy against roughly 70% of that, with the rest held in reserve so HA can restart protected VMs after a host failure. Operators who bought hardware expecting to use all of it hit this wall during provisioning and reach for the disable switch.

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.