A Windows pvscsi Event 129 reports a storage reset, not a complete diagnosis. Before increasing queue depth, correlate the guest timeout with ESXi records and determine whether the evidence supports virtual-controller queue pressure, backing-storage delay or an unresolved combination.
The scope is a Windows guest using VMware Paravirtual SCSI on ESXi 8.0.x. Record the installed PVSCSI driver and VMware Tools versions; the device name alone does not establish the driver build. This is an inspection-only article with synthetic examples and no executed workload tests.
Understand the queues in the path
A guest submits requests through the PVSCSI driver to a virtual controller. There are per-device limits and an adapter request ring before requests proceed through the host storage path. Increasing one limit does not expand every downstream queue.
Broadcom KB 343323 describes default device and adapter queue depths of 64 and 254. It also describes an eight-page request ring, with 4 KB pages and 128-byte entries. The arithmetic is 32 entries per page and 256 entries across eight pages. A24-S1
These figures describe different aspects of the implementation. Do not replace the documented adapter queue-depth value with 256 merely because the ring arithmetic gives that number. Nor does a larger ring imply more IOPS: downstream capacity and workload behaviour still matter.
Gather the reset sequence
Prerequisites are existing Windows System events, the corresponding ESXi vmkernel.log interval, virtual-disk/controller mapping and storage performance history. Identify the VM, host at the incident time and virtual disk paths. Account for a migration during the observation window.
In the guest event, preserve the provider, event identifier, timestamp and device text. An Event 129 from another provider is not automatically the same PVSCSI case. Broadcom's workload example reports source pvscsi and text such as Reset to device, \\Device\\RaidPortX, was issued. A24-S2
Correlate the timestamp with host records such as VSCSI: processing reset for handle and IO was aborted by VMFS via a virt-reset. A virt-reset supports a guest-origin reset. It does not, by itself, establish why the guest stopped receiving timely completions.
Avoid assuming that the Windows port suffix directly names a datastore. Resolve the affected virtual controller and disks from the VM's configuration, then map their backing storage. A VM with several controllers requires that distinction before selecting evidence.
KB 431220 describes resets about 60 seconds apart, matching the driver timeout in its case, and names Congestion Oversubscription and Credit Stall as possible accompanying vmkernel signals. Compare timestamps and the existing storage-health records. Its esxcli storage core device stats text is a command-group reference, not a complete executable device query; this article does not invent missing subcommand/arguments or treat counters alone as a latency measurement.
Worked diagnostic comparison
Suppose an invented database VM logs repeated PVSCSI resets during a batch window. The host records matching guest-origin resets. Two possible evidence sets lead to different conclusions:
| Matching evidence | Defensible conclusion |
|---|---|
| Storage path errors and high backing-device latency begin before the guest resets | Investigate the lower storage path; the reset is a consequence candidate |
| No corresponding path errors, normal observed backing latency and bursts concentrated on one virtual controller | PVSCSI queue pressure is a hypothesis worth driver-specific investigation |
The second row does not prove queue exhaustion. Sampling may miss brief storage delays, and a quiet array average can conceal a busy individual device. State the observation resolution and the missing measurements.
Broadcom KB 431220 describes a high-workload case involving Event 129, host reset records and no observed physical-storage fault. Use that combination as a comparison case, not as a rule that every Event 129 is fixed by increasing buffers. A24-S2
KB 431220 says a guest-originated virt-reset confirms an internal PVSCSI bottleneck rather than the physical SAN. This article deliberately adopts a narrower conclusion: reset origin alone does not exclude a downstream cause; the KB’s accompanying healthy-storage evidence must also be established. If uncertainty remains, the KB recommends Microsoft consultation to rule out Storport.sys issues. KB 343323 documents ceilings of 254 for the device queue and 1,024 for the adapter, but a documented maximum is not a tuning target.
Why this article stops before tuning
The sources discuss both guest queue changes and host HBA settings. Those are distinct changes with different scope: an HBA adjustment can affect other workloads sharing that host and storage path.
There is also a documentation detail requiring care. KB 343323 presents the Windows DriverParameter string using RequestRingPages, while KB 431220 summarises a value using RingPages. This article deliberately supplies no registry write command. Resolve the exact supported driver syntax and workload suitability before a qualified change plan uses either source.
Do not copy legacy adapter module names into a modern host. A source listing several ESXi generations is not evidence that a particular historical HBA parameter exists on the installed driver.
Acceptance, reversal and learning
The diagnostic deliverable is a timestamped reset chain, disk/controller mapping, observed lower-layer health and explicit confidence level. A satisfactory investigation can conclude “cause unresolved”; it should still narrow which missing evidence would distinguish the hypotheses.
For a later approved tuning trial, acceptance would require representative workload comparison, fewer relevant timeouts and no new downstream latency or fairness problem. Record original guest and host values separately and validate how each change is reversed, including any restart dependency. No such trial or reversal was performed here.
Read-only inspection itself changes no configuration. Retain the original logs rather than repeatedly generating load to provoke the fault.
The key lessons are that a reset's origin is not its root cause, device and controller queues are different limits, and buffering cannot create storage capacity. These distinctions prevent a virtual-controller problem from becoming an indiscriminate host-wide tuning exercise.
References
- A24-S1: Large-scale workloads with intensive I/O patterns might require queue depths significantly greater than Paravirtual SCSI default values
- A24-S2: High workload Windows VMs report PVSCSI-alert-(129)