Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado Apto para principiantes
#4,259 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #4282 de @benoitf — fusionado

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust

Línea de trabajo

Empieza con crates/openshell-driver-vm/runtime/pins.env y comprueba cómo el runtime de la VM fija libkrun. Actualiza el pin a una release que contenga el fix de conexión rechazada de upstream, luego crea una sandbox de VM usando el paso de reproducción reportado. Hecho significa que el runtime usa la release corregida y la creación de la sandbox ya no se detiene durante aproximadamente cinco segundos mientras espera al supervisor de la VM.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

state:triage-needed

Note: I have observed the behaviour, but due to lacking Rust knowledge and the codebase in general I have instructed Claude Opus 5.5 to use the skills in this repo and analyze for potential cause of the 5s wait. "Analysis by Claude" is added where the statements are from Claude, and I have verified the parts I am able to (commit references etc).

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)
Lenguaje dominante
Rust
Estrellas
15.4k
Forks
1.7k
Merge medio
1 d 21 h
PR fusionados (30 d)
363

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NVIDIA/OpenShell

Todos los issues de NVIDIA/OpenShell

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.