Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

bug(vm-driver): VM sandbox cold start stalls ~5 s repeatedly on "Waiting for VM supervisor"

Open Beginner friendly
  • Is something wrong?
#4,259 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
infrastructure

Research direction

Start with crates/openshell-driver-vm/runtime/pins.env and check how the VM runtime pins libkrun. Update the pin to a release containing the upstream refused-connection fix, then create a VM sandbox using the reported reproduction step. Done means the runtime uses the fixed release and sandbox creation no longer stalls for about five seconds while waiting for the VM supervisor.

Written by the indexing model from the issue text.

Description

state:triage-needed
User Story

I use OpenShell for running ephemeral sandboxes. I directly encountered repeatedly a 5 second wait on "Waiting for VM supervisor". I need sandboxes to become ready without this wait, so that they start faster and the task can be done quicker.

⠐ Starting sandbox... Waiting for VM supervisor (0s)
⠐ Starting sandbox... Waiting for VM supervisor (5s)

Problem Statement

Analysis by Claude:

VM sandbox startup can stall for about 5 seconds while the host waits to reach the guest over the boundary control connection.

The VM driver maps its boundary control port with krun_add_vsock_port2(..., listen=true). libkrun accepts the host-side Unix socket connection immediately, before anything in the guest listens on that port. In libkrun v1.19.4 and earlier, when the guest refuses that connection, libkrun keeps the host socket open until its reaper reclaims it 5 s later. connect_boundary_with_retry in openshell-sandbox-backend therefore blocks for that window instead of retrying every 25 ms.

Upstream fixed this in libkrun/libkrun@d2d8dd6 ("virtio/vsock: remove refused connections without waiting for the reaper"), first released in v1.19.5 (upstream issue containers/libkrun#684). OpenShell pins libkrun v1.19.4 in crates/openshell-driver-vm/runtime/pins.env.

Impact / Why This Matters

Analysis by Claude:

Every VM sandbox whose host-side probe reaches the control socket before the guest is listening pays up to ~5 s of extra startup time. The delay dominates cold start for short-lived sandboxes. There is no workaround in OpenShell configuration. Upstream measured time to first round trip after VM start at 5338 ms before the fix and 415 ms after, with a blocking probe.

Acceptance Criteria
  • The VM driver runtime is built with a libkrun release that contains libkrun/libkrun@d2d8dd6. (1.19.5 or 1.19.6 atm)
  • VM sandbox creation no longer includes a ~5 s stall
Reproduction Steps
  1. openshell sandbox create --name sandbox
Created sandbox: sandbox

✓ Sandbox allocated (0s)
✓ Image pulled (512 MB) (0s)
⠤ Starting sandbox... Waiting for VM supervisor (5s)
Suggested UX (if applicable)

No response

Environment
  • OpenShell: openshell 0.1.2
  • OS: macOS 26.6.2 (Apple silicon)
  • OpenShell deployment mode and runtime: local gateway, VM compute driver (libkrun v1.19.4)
Logs
Created sandbox: sandbox

✓ Sandbox allocated (0s)
✓ Image pulled (512 MB) (0s)
⠤ Starting sandbox... Waiting for VM supervisor (5s)
Dominant language
Rust
Stars
13.2k
Forks
1.6k
Avg merge
1d 19h
Merged PRs (30d)
343

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/OpenShell

All issues in NVIDIA/OpenShell

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.