Rising VMXNET3 receive-buffer exhaustion counters can explain packet drops inside the virtual receive path even when the physical link is healthy. Compare a correctly identified VM NIC over one uninterrupted observation interval, then correlate CPU scheduling and guest processing evidence before increasing buffers. A23-S1
This article covers the Windows VMXNET3 case documented for ESXi 8.0. Record the installed guest driver and VMware Tools builds. It is source-only diagnosis; no packet generator, workload test, migration or configuration change was executed.
Why the virtual receive path can drop packets
Packets arriving at a virtual NIC need receive buffers and timely processing by the guest. Broadcom documents a case where CPU contention prevents the guest from processing incoming traffic quickly enough, available receive buffers are exhausted, and the running out of buffers counter increases. A23-S1
That mechanism connects host scheduling to a network symptom. Adding a faster physical uplink does not necessarily solve a guest that cannot consume its incoming packets. Equally, a buffer-exhaustion counter does not automatically prove CPU contention; bursts, driver behaviour and other conditions still require investigation.
A ring is a bounded queue. More capacity can absorb some bursts, but it cannot guarantee progress when the consumer remains unable to run. This is why the diagnostic should establish when drops increase and what processing evidence accompanies them.
Use a correctly mapped counter interval
Prerequisites are existing support or diagnostic captures that identify the VM, host, virtual NIC and corresponding receive counters. Include the observation times and any vMotion or power-cycle history between them. Do not reuse a port identifier copied from another host's example.
KB 426261 gives an example inside the vsish diagnostic shell: get /net/portsets/<vSwitch>/ports/<ID>/vmxnet3/rxSummary. The angle-bracket values are placeholders for the verified switch and VM port on the current host. This is an unexecuted read example, not a literal shell command or a universal path. Have the authorised platform operator establish that mapping before interpreting its counters.
Keep the raw starting and ending counters. A large lifetime total is not evidence that the current complaint window suffered new drops. Conversely, a low total immediately after a reset may hide an earlier incident.
Worked counter interpretation
Suppose these synthetic observations refer to the same uninterrupted virtual NIC instance:
| Time | Receive-buffer exhaustion count |
|---|---|
| 10:00 | 1,200 |
| 10:05 | 1,800 |
The interval contains 600 additional events. It does not establish a packet-loss percentage because a suitable denominator and the counter's precise event semantics have not been established. Do not label 600 as a measured number of lost application requests.
If user symptoms and CPU contention rise in that same interval, the documented processing-starvation mechanism becomes a useful hypothesis. Compare it with a quieter interval and existing guest/host evidence. Keep timestamps aligned; a CPU chart from an unrelated five-minute window cannot establish correlation.
If the count remains unchanged during the complaint, that particular counter does not support new receive-buffer exhaustion in the interval. Continue investigating other layers rather than tuning the ring because its historical total is non-zero.
Recognise resets before claiming recovery
Broadcom documents that the counters can reset after vMotion or a VM power cycle, while Windows buffer settings persist. A drop from 1,800 to 0 across such an event cannot be treated as a negative error delta or proof that the configuration was repaired. A23-S2
Split the record into separate observation segments. Preserve the host and port mapping for each segment and state why the counters are no longer directly comparable.
This also explains a misleading incident narrative: “we moved the VM and the error count disappeared.” The movement may change resource contention, but the disappearing total alone proves only that the observation state changed. Subsequent comparable evidence is needed to show that new exhaustion ceased.
KB 426261 says to verify physical NIC firmware and drivers first and describes larger guest buffers as a permanent configuration optimisation for bursts beyond default capacity. That is vendor guidance for a matching case, not proof that every drop warrants larger rings. KB 437897 includes high guest memory associated with event-logging services and SQL audit-log processing among its symptoms; maximum ring sizes also increase guest RAM use. Assess those resource costs alongside CPU contention before any tuning.
Decide what evidence warrants a change
Read the VM's existing CPU limits, host contention history and guest processing evidence before considering a buffer increase. Do not infer adequate scheduling from low guest CPU usage alone; a guest that waits to run can still process traffic too slowly.
Any proposed buffer, driver or resource change needs a separate version-matched plan with its previous values and restart requirements. Broadcom's case-specific tuning suggestions are not a universal instruction to maximise every VM's buffers or reserve all CPU.
Acceptance and limits
A successful diagnosis identifies the right NIC, a valid counter interval, any reset boundary and the supporting or conflicting processing evidence. It may reasonably conclude that buffer starvation occurred but its cause remains unresolved.
After an approved correction, proposed acceptance is fewer new exhaustion events over a comparable workload interval, together with improved application behaviour and no new resource problem. A zeroed counter alone does not pass. No such acceptance test was run here.
Inspection needs no rollback. Preserve the original evidence so a later change can be evaluated against a meaningful baseline.
Learning notes
- A receive-buffer counter describes the virtual endpoint, not the whole route.
- Compare increments within one continuous instance.
- Migration can reset evidence without proving the underlying problem is fixed.
References
- A23-S1: VMXNET3 "out of buffers" packet drops on Windows VMs in ESXi 8.0
- A23-S2: Understanding VMXNET3 Ring Buffer Persistency and Counter Resets