Troubleshooting VMkernel Network Connectivity on ESXi

VMkernel adapters carry the traffic that keeps an ESXi host operational: management access, vMotion, vSAN, iSCSI, NFS, fault tolerance and other specialised services. When one of these paths fails, the symptoms can range from a lost vCenter connection to slow migrations, inaccessible datastores or a vSAN health warning.

Effective troubleshooting starts with the complete path rather than a single command. Check the VMkernel interface, port group, VLAN, physical uplinks, routing, MTU and remote endpoint in sequence. This approach is especially useful in Australian environments where small IT teams may support sites in Sydney, Melbourne, Brisbane or regional locations with limited on-site hands.

Map the VMkernel Path

Begin by identifying the affected VMkernel adapter and the service assigned to it. Run esxcli network ip interface list to review interface names, MAC addresses, MTU values and link state. Then inspect configuration with esxcli network ip interface ipv4 get and confirm that the expected address, subnet and DHCP or static configuration are present.

The adapter name alone does not tell you how traffic leaves the host. Record its port group, VLAN ID, active and standby uplinks, teaming policy and switch type. VMware’s VMware series provides useful background when you need to relate these settings to broader vSphere networking concepts.

A common mistake is testing the management VMkernel when the failed service uses a dedicated interface. For example, vMotion may use vmk1, while vSAN uses vmk2 on a different subnet and VLAN. Always test the interface that owns the service, not simply the one used to access the ESXi Host Client.

Verify Physical and Virtual Switching

Check the physical link first. Use esxcli network nic list to confirm that each expected vmnic is up, operating at the correct speed and free from obvious errors. A failed transceiver, mispatched cable or switch port in the wrong channel group can appear to ESXi as an IP connectivity problem.

On a standard switch, validate the port group’s VLAN and security policies. On a vSphere Distributed Switch, inspect the distributed port group, uplink assignment, teaming policy and host membership. Commands such as net-dvs -l can help expose inconsistent host or uplink state when the vSphere Client does not make the cause obvious.

The physical switch must match the ESXi design. A tagged VLAN requires the relevant switch port to allow that VLAN, while an access port should not be paired with an ESXi port group expecting tags. In Australian colocation facilities, provider handoffs and managed switches can introduce additional VLAN restrictions, so confirm the service-provider configuration instead of assuming the local switch is transparent.

Test Addresses Routes and MTU

Use vmkping with the correct source interface to test connectivity from a VMkernel adapter. For example, vmkping -I vmk1 192.168.40.12 checks the path using vmk1, while vmkping -I vmk1 -d -s 8972 192.168.40.12 tests a jumbo-frame payload. The destination should be another relevant VMkernel address, gateway or service endpoint.

A successful ping does not prove that every required network function works. Check the routing table with esxcli network ip route ipv4 list, and confirm that the remote address belongs to the expected subnet. If the service crosses a router, firewall or layer-3 boundary, validate return routes and access rules as well as the forward path.

MTU failures are particularly deceptive because small pings succeed while vMotion or vSAN traffic fails under load. Jumbo frames must be configured consistently across the VMkernel interface, port group, distributed switch, physical switch ports and every intermediate device. Test both standard and large packets, and avoid changing MTU values during peak production activity.

Isolate vSAN and Storage Traffic

Storage protocols require careful separation from ordinary management traffic. Confirm that the vSAN VMkernel adapter has the vSAN service enabled, uses the intended VLAN and can reach matching vSAN interfaces on every host. For iSCSI, check the binding configuration, vmkernel-to-physical adapter relationships and target discovery state rather than relying on a general ping.

vSAN connectivity problems often involve an apparently healthy link with inconsistent latency, packet loss or MTU. Review esxcli vsan health cluster list and the vSAN Skyline Health view, then compare results across all hosts. A host can be reachable from vCenter while still failing the east-west communication required by the storage cluster.

The resilient vSAN design guidance is valuable when recurring faults point to a design weakness rather than a single failed port. Consider redundant switches, diverse uplinks and predictable failure domains. This matters for Australian organisations balancing resilience requirements with expensive links between metro sites or remote offices.

Read ESXi Evidence

When basic checks do not identify the fault, inspect live counters and logs. esxtop can reveal dropped packets, receive or transmit errors and unusual activity on physical adapters. The ESXi logs, including /var/log/vmkernel.log, /var/log/vobd.log and /var/log/hostd.log, may show link flaps, driver faults, VLAN-related events or service failures.

Packet capture is useful when the question is whether traffic reaches the host, leaves the host or receives a reply. Depending on the ESXi version and scenario, pktcap-uw can capture traffic at different points in the networking stack. Keep captures short, filter by interface or address and protect any collected data because packets may contain credentials or sensitive application content.

Correlate timestamps across ESXi, the physical switch, firewall and remote host. Australian teams operating under the Privacy Act and internal Essential Eight controls should store diagnostic files securely and remove captures when the investigation is complete. A short maintenance record with the fault, test, result and change made is often more useful than an unexplained configuration adjustment.

Build a Repeatable Diagnostic Routine

A disciplined workflow reduces downtime and prevents random changes from creating a second fault. Use the following checks in order:

• Identify the affected service and its assigned VMkernel adapter.
• Confirm interface state, IP address, subnet, VLAN and MTU.
• Verify port group, vSwitch or vDS uplinks and teaming behaviour.
• Test the path with source-specific vmkping, including jumbo frames where required.
• Review routes, switch counters, ESXi logs and service health.
• Compare the failing host with a healthy host using the same network design.
• Document the confirmed cause before reverting temporary troubleshooting changes.

Keep a small baseline for every host: expected VMkernel names, addresses, VLANs, MTUs, uplinks, switch ports and service assignments. This is valuable for consultants travelling between sites and for internal teams supporting branch offices over NBN, private WAN or leased Ethernet services.

When VMkernel connectivity is restored, repeat the original workload test. Start a vMotion, rescan storage, validate vSAN health or reconnect the management service as appropriate. Monitoring the path after the change confirms that the repair solved the underlying fault rather than only making a single ping succeed.

Use this workflow as a runbook in your home lab or production environment, and adapt it to the switching, routing and compliance requirements of each site. Consistent evidence, source-specific tests and documented network intent make ESXi connectivity faults faster to isolate and safer to resolve.