Karl Erik Filip Modén
Explainers 6 min read

ESXi Troubleshooting: Common Faults and the esxcli Commands That Help

A practical ESXi troubleshooting guide covering common host, network, storage, management, and performance faults, with esxcli commands to identify the failing layer before making a change.

When an ESXi host is unhappy, the fastest route to a bad outcome is changing three things at once. Start by identifying the failing layer: management, network, storage, compute, or a specific VM. esxcli is useful because it asks the host directly rather than relying only on a vCenter symptom.

A safe first five minutes

Before remediation, record the affected host, VM, datastore, time, and recent changes. Then gather a small baseline:

esxi-01 — SSH 
# Host version, uptime, and hardware view
esxcli system version get
esxcli hardware platform get

# Storage and network inventory
esxcli storage filesystem list
esxcli network nic list

# VMkernel interfaces and routes
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list

These commands do not fix anything. That is the point. They tell you whether the host still sees its adapters, filesystems, VMkernel interfaces, and routes before you introduce another variable.

Fault 1: The host is disconnected or vCenter cannot manage it

Typical symptom: vCenter reports the host as disconnected or not responding, while VMs may still be running.

Start with the management agents and the resources they depend on:

/etc/init.d/hostd status
/etc/init.d/vpxa status
esxcli network ip connection list
vdf -h

hostd is the ESXi management service. If it is unresponsive, direct management and vCenter communication can fail even though the VM data path remains alive. Check free space first: a full / or /var/log filesystem can stop hostd from working normally. Also check for slow or unavailable storage; commands that hang while accessing /vmfs/volumes are a storage clue, not merely a management-service problem.

Narrow remediation: if storage and filesystem checks are healthy, restart only the affected management service according to the current Broadcom procedure. Do not restart agents as a substitute for investigating storage I/O or a full filesystem.

Fault 2: A VM or VMkernel network is unreachable

Typical symptom: management, vMotion, vSAN, or NFS connectivity fails for one host while other hosts work.

esxcli network nic list
esxcli network nic stats get -n vmnic0
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list
vmkping -I vmk0 192.0.2.10

Read the path in order:

vmk interface -> port group and VLAN -> vmnic uplink -> switch -> route -> remote endpoint

esxcli network nic list confirms link status, speed, duplex, and driver. The NIC statistics command shows errors and drops. A nonzero counter is not automatically today’s problem; record it, wait, and see whether it increases during the fault. vmkping -I is valuable because it tests from the intended VMkernel interface rather than from a random guest network.

If a datastore or vSAN endpoint is reachable from a VM but not from ESXi, inspect the ESXi route table and the VMkernel interface selected for that destination. The host may simply be taking a different path than you expected.

Narrow remediation: correct the physical VLAN, uplink, routing, or compatible driver/firmware issue. Do not clear NIC counters with a reboot just to make the numbers look clean; capture the rate of increase first.

Fault 3: A datastore is missing, inaccessible, or slow

Typical symptom: VMs show inaccessible files, a datastore disappears, or host management commands are slow.

esxcli storage filesystem list
esxcli storage core device list
esxcli storage core path list
esxcli storage core path list -d naa.<device-id>
esxcli storage core adapter list

First establish scope: is one host affected, a subset of hosts, or the entire cluster? A single affected host points toward its HBA, paths, zoning, iSCSI/NFS network, driver, or firmware. A cluster-wide loss points farther upstream, such as the array or fabric.

For Fibre Channel, this checks discovered initiator details:

esxcli storage san fc list

For a specific device, examine path state and adapter association. Dead or repeatedly changing paths are far more useful evidence than a generic “datastore unavailable” message.

Narrow remediation: after the array or fabric issue is corrected, a storage rescan can rediscover paths:

esxcli storage core adapter rescan --all

Do not use a rescan as a cure for an unresolved SAN, NFS, or iSCSI problem. If esxcli itself is blocked by an unresponsive hostd, Broadcom documents localcli as an alternative for host-local checks; treat that as a sign to investigate the underlying condition.

Fault 4: The host is slow or VMs are stuttering

Typical symptom: user applications are slow, but there is no obvious hardware failure.

esxcli provides inventory and state; use esxtop for the live performance counters.

esxtop

Start with the CPU screen (c) and memory screen (m). Check whether the affected VM has high %RDY or %CSTP, whether a CPU limit is involved, and whether the host is ballooning or swapping. Then use the disk VM/device/adapter views (v, u, d) to compare DAVG, KAVG, and GAVG latency.

High DAVG + low KAVG -> device, fabric, or storage array delay
Low DAVG + high KAVG -> ESXi-side queuing or contention
High %RDY            -> a vCPU is ready but cannot be scheduled

Narrow remediation: fix the constrained layer. Moving a VM may relieve a CPU contention problem; it will not repair an array latency problem. Likewise, adding vCPUs to a VM with high co-stop can worsen scheduling.

Fault 5: A physical NIC has errors, drops, or disappears

esxcli network nic list
esxcli network nic stats get -n vmnic1
esxcli software vib list | grep -i <driver-name>

If a NIC is missing from esxcli network nic list, ESXi has not discovered it correctly. Check PCIe visibility, compatible driver and firmware versions, hardware support, and the physical slot or adapter. If the NIC is present but counters climb, compare link configuration with the switch and involve the hardware or network owner with the counter evidence.

Fault 6: You need evidence for an intermittent issue

Use a bounded collection window. For performance, batch esxtop data is more useful than a screenshot taken after the spike is gone.

# Every 2 seconds, for 30 minutes
esxtop -b -a -d 2 -n 900 > /vmfs/volumes/DATASTORE/esxtop-incident.csv

For a support case or a serious host incident, collect a support bundle before disruptive action whenever practical. Keep the exact incident time and any related vCenter, storage, or switch events with it.

A compact decision table

SymptomFirst commandsLikely next check
Host disconnectedhostd status, vdf -h, esxcli network ip connection listManagement service, disk space, storage responsiveness
VMkernel path failsnic list, nic stats get, ip route, vmkpingVLAN, uplink, MTU, route, endpoint
Datastore missingfilesystem list, core path list, adapter listHBA, path state, array presentation, fabric
VM slowesxtopCPU ready, memory reclaim, storage latency
NIC errorsnic list, nic stats getSwitch, driver, firmware, hardware

The habit that pays off is simple: establish scope, collect evidence, identify the layer, then make one reversible change. ESXi faults become much less mysterious when the host’s state is read in that order.

Official references