Vmware ESX on Netdata

Vmware ESX on Netdatahttps://www.netdata.cloud/tags/vmware-esx/Recent content in Vmware ESX on NetdataHugoen-usSat, 22 Aug 2026 05:09:03 +0300VMware Monitoring Software Without Centralized Datahttps://www.netdata.cloud/solutions/technologies/vmware-monitoring/Thu, 18 Dec 2025 00:00:00 +0000https://www.netdata.cloud/solutions/technologies/vmware-monitoring/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 certificate expired: the STS signing cert outage nobody saw cominghttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-vcenter-certificate-expired/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-vcenter-certificate-expired/<p>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.</p> <p>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.</p>VMware vSphere Operations Guideshttps://www.netdata.cloud/guides/vmware-vsphere/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/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 VMhttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-snapshot-consolidation-needed/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-snapshot-consolidation-needed/<p>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.</p> <p>The warning is set by <code>VirtualMachine.runtime.consolidationNeeded</code> 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.</p>vSphere datastore full: 'No space left on device', paused VMs, and power-on failureshttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-datastore-full/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-datastore-full/<p>A vSphere datastore hitting 100% is a cliff-edge failure. Below 100%, VM performance is unaffected. At 100%, every VM that needs to write to the datastore stops: running VMs pause with the “There is no more space for virtual disk” dialog, thin-provisioned VMDKs cannot extend, snapshot deltas cannot grow, and power-on operations fail because the per-VM <code>.vswp</code> swap file cannot be created.</p> <p>The vmkernel log records the kernel’s view with <code>No space left on device</code>. The most common root cause is unattended snapshot growth: a delta VMDK consumes the same datastore as the base disk and grows with every guest write. A VM with a 200 GB base disk and an active snapshot can grow its delta to 200 GB.</p>vSphere datastore latency high: reading GAVG, DAVG, and KAVGhttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-datastore-latency-high/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-datastore-latency-high/<p>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.</p> <p>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.</p>vSphere dropped packets (%DRPRX/%DRPTX): ring buffers, CPU, and uplink backpressurehttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-dropped-packets/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-dropped-packets/<p>%DRPRX and %DRPTX in esxtop are usually the first sign a VM is losing packets inside the host. They should be zero at steady state. When they are not, the guest retransmits, latency climbs, and for latency-sensitive workloads (IP-based storage, databases, replicated queues) the impact can be severe well before the drop rate looks alarming.</p> <p>The distinction that matters: %DRPRX and %DRPTX count drops at the virtual switch port, between the vSwitch and the guest OS driver. They are not physical NIC drops. The uplink vmnic can report zero drops via <code>esxcli network nic stats get</code> while %DRPRX is non-zero on the VM attached to it. Treating them as the same counter is the most common diagnostic mistake.</p>vSphere host swapping (SWCUR/SWW/s): hypervisor swap and the memory death spiralhttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-host-swapping/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-host-swapping/<p>When <code>SWR/s</code> is sustained above zero on an ESXi host, the VMkernel is actively reading VM memory pages back from <code>.vswp</code> files on the datastore. That is not a warning state. It is an active performance emergency. Every swapped-in page costs roughly 100x DRAM latency, and the swap I/O itself competes with VM disk I/O on the same datastore, producing a double penalty that degrades every VM on the host simultaneously.</p>vSphere memory ballooning (MCTLSZ): the host is reclaiming guest RAMhttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-memory-ballooning/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-memory-ballooning/<p>You open esxtop, switch to the memory view, and a VM’s MCTLSZ column is no longer zero. A few hundred megabytes or several gigabytes, the VMkernel has inflated the vmmemctl balloon driver inside that guest and is forcing the guest OS to hand back memory it thought it owned. From the host’s perspective this is gentle reclamation. From the guest’s and the application’s perspective, it is often the start of a silent performance decline.</p>vSphere monitoring checklist: the signals every host, VM, and vCenter needshttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-monitoring-checklist/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-monitoring-checklist/<p>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).</p> <p>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.</p>vSphere PSOD (purple screen of death): diagnosing an ESXi host crashhttps://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-host-psod/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/vmware-vsphere/vmware-vsphere-host-psod/<p>A purple screen of death (PSOD) is the ESXi VMkernel’s deliberate halt. When the kernel detects an unrecoverable condition, an uncorrectable machine check, a driver panic, or a corrupted data structure, it stops the host on purpose, paints the purple diagnostic screen, and writes a core dump if a target is configured. Every VM on that host dies instantly. There is no graceful shutdown and no live migration off the host.</p>