[Pedro Henrique Penna (ppenna)]

Refs #170. Pins microsoft/openvmm#4773 at b92daa350c93914b2eb556acf47886cc313d396b, which bounds every request of OpenVMM's HTTP blob disk in time, retries the ones that fail transiently on a new connection, and shows them in inspect, so that a network path that silently stops delivering a connection's packets no longer hangs a guest's disk read until petri's ten-minute watchdog fails the test. That hang is the root cause of #170's intermittent Linux/KVM OpenVMM VMM-test stalls. #170 stays open until the Linux/KVM lane has run clean with this pin.

Based on dev at b855c4d55. microsoft/openvmm#4773 is three commits directly on d2338ea22, the head of feature/microvm/dev and the revision that dev pins, and the pin is that pull request's head commit itself, so this branch's two commits are its whole diff.

Change

Commit	Files	Change
351d2d45f openvmm	openvmm	d2338ea22 → b92daa350: the three commits of microsoft/openvmm#4773
538399841 doc	doc/openvmm-upstream-roadmap.md	Records them as positions 350-352, unassigned, with a remark that they change only disk_blob, which upstream main and the fork base have alike, so they can go upstream on their own; moves the NVX pin; and records that microsoft/openvmm#4769 merged positions 348 and 349 into feature/microvm/dev

No other NVX change is needed: OpenVMM's control-session protocol vectors and built-in CPU profiles are unchanged at the pin.

OpenVMM changes

• Bound every request in time (8c1772d83). A 10 s connect timeout, a 20 s response-header timeout, a 20 s body inactivity timeout, which never cuts off a slow body that is still arriving, and a 120 s operation deadline, with TCP keepalive after 30 s idle. A request that runs out of time fails with TimedOut, which the guest sees as a failed read rather than one that never completes. HttpBlob::new's HEAD probe is bounded the same way, and a read whose last byte would lie past u64::MAX is refused without a request.
• Retry transient failures (b47786f2a). Timeouts, lost connections, and statuses 408, 429, 500, 502, 503, and 504 are retried for up to four attempts, after a backoff from 250 ms that doubles up to 4 s, each retry on a new connection; other failures are returned at once. A transient stall now costs about 20 s instead of the test, and a persistent one fails the read after about 82 s. Each retry is a rate-limited warning.
• Show requests in inspect (b92daa350). The blob's inspect node lists each request in progress, with its range, attempt, state, and age, and counts attempts, retries, timeouts, and failures, so that the next watchdog dump shows whether a stuck read is waiting on HTTP.

NVX's microVMs do not use blob disks, so NVX's runtime is unaffected. The change matters to the OpenVMM VMM tests that NVX's CI runs on KVM, MSHV, and WHP, whose UEFI guests boot from VHDs that petri streams from hvlitetestvhds.blob.core.windows.net.

Evidence

• Still occurring before this change. Of 697 Linux/KVM VMM-test jobs from October 10 to 27, four on October 20 (runs 39489655796, 39490938890, 39492370835, and 39497552073, on azure-kvm-2, azure-kvm-4, and azure-kvm-5) timed out seven UEFI tests with a guest READ in flight on the blob-backed LUN 0:0:0; in 39490938890, two VMs stopped 4 ms apart on the same blob, and 39492370835 also logged Connection reset by peer (os error 104) from the blob client.
• Deterministic reproduction. [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures openvmm#4773's tests serve HttpBlob from a loopback server that goes silent, as a dead network path does, or resets the connection. With HttpBlob as it was, the stall, reset, 503, and inspect tests fail, the same 13 in each of 5 runs, the stalls on the tests' 10 s limit; with the change, the suite passes repeatedly on Linux and Windows.
• End to end, on the bare-metal Linux/KVM host prometheus32, booting petri's Alpine 3.23 UEFI image through petri's disk layering and a loopback proxy to the real blob container that injects faults: with HttpBlob as it was, one stalled range request froze the guest in GRUB's initramfs load, or after * Cleaning /tmp directory ... [ ok ], for over 10 minutes with a READ in flight, the signature of the CI dumps; with the change, the same faults were retried about 20 s later and the guest booted, resets were retried within a second and a half with no error reaching the guest, and normal reads took no longer. These runs used a revision of [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures openvmm#4773 that lacked only its range check, the classification of connect timeouts, and the cap on the first backoff, which none of these paths reach.

Validation

• OpenVMM, each commit of [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures openvmm#4773 on Windows: cargo clippy --all-targets, cargo doc --no-deps, and cargo nextest run --profile agent for disk_blob (13, 22, and 23 passed), and cargo xtask fmt --fix, all clean.
• NVX at 351d2d45f: python scripts\nvx.py verify (consistent); the openvmm_vectors and openvmm_cpu_profiles comparisons with --ignored (3 and 1 passed), against the pinned revision; and, at 538399841, python scripts\check_markdown_links.py.
• Every commit is signed, both these and [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures openvmm#4773's.
• Pending CI: the OpenVMM builds and VMM tests on Linux/KVM, Linux/MSHV, and Windows/WHP, the microVM suites, and the benchmarks, at head 538399841ee4bed99d6ae55bd75d793b1d5b8d07.
• Rebuilt on b855c4d55 after openvmm: pin amd.genoa.v2 for Genoa hosts without the TSA immunities #935 moved dev's pin to d2338ea22: [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures openvmm#4773 was rebased onto that revision without conflicts (git range-diff shows its three patches unchanged), and this branch's two commits were made again on dev. The previous head, 3c8bf5544, passed the full CI matrix with the same OpenVMM patches on 57d0a18b3.

[Copilot]

🔵 Needs a closer look

The pinned asynchronous HTTP disk changes need final human review, with exact-head cross-platform VMM validation still reported as pending.

No open issues 🎉

What changed in this PR

This PR advances the OpenVMM pin to address #170’s intermittent blob-backed disk stalls through bounded HTTP requests, transient-failure retries, and request diagnostics. The reviewed documentation records the new revision and its upstream integration plan.

Changes:

• Updates the documented NVX pin to 8f1c28253, at chain position 350.
• Records the three HTTP blob commits and their eligibility for independent upstream submission.
• Updates the branch diagram and records the merge of positions 346–347.

File	Description
doc/​openvmm-upstream-roadmap.md	Updates the pin, commit mapping, and upstream status for the HTTP blob fixes.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The OpenVMM pin imports substantial HTTP timeout, retry, and cancellation changes with no recorded source reviews and pending exact-head KVM/MSHV/WHP validation, requiring human review and platform results before promotion.

No open issues 🎉

_{Review effort: Balanced}