Self-hosted Embed: snapshot marked successful crashes on restore
Los mantenedores suelen responder en 3 días
@svalleru ya está trabajando en esto.
Desde el 23/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
On self-hosted Embed, a snapshot marked success crashes Firecracker on every restore attempt. The previous snapshot of the same sandbox restores normally.
Firecracker panicked at src/vmm/src/devices/mod.rs:34:9:
The number of available virtio descriptors 41919 is greater than queue size: 256!
Verified
- The runtime logged a successful upload and marked the snapshot build
success. - Restoring the saved snapshot through
Sandbox.create("<env>:default")on a fresh, healthy host with the same binaries produces the same panic 3 out of 3 times. The copied snapshot files and dependencies were hash-verified. - The previous snapshot, captured 42 minutes earlier, restores and runs guest commands on that host.
The original host logged repeated No space left on device errors before capture, but these logs do not establish the cause. The tests reproduce the restore failure using the preserved snapshot, not the original capture failure.
Expected result
A snapshot marked successful should be restorable. If saving it fails, report the failure and preserve a recovery path for the sandbox.
Environment
- Single-node Embed, local file storage; Ubuntu 26.04 ARM64 VM with nested virtualization
- Orchestrator
v0.16.202609130627-59497eb9134; APIv0.14.202609170000-908833e4c12 - Firecracker
v1.14-0.2.0(reports v1.14.4); hugepage-backed sandbox, 2 vCPU / 2048 MiB - Compose revision:
a065a4ddb3f2c6a4149634d9acb14b62f65839ac
Snapshot artifacts and logs are preserved. Related: #3658 covers losing a sandbox when pause reports an error.
- Lenguaje dominante
- Go
- Estrellas
- 1.6k
- Forks
- 448
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de e2b-dev/runtime
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 3 días
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running stateAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 3 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 86/100
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 3 días
Todos los issues de e2b-dev/runtime
Issues similares
-
Remove CAAPFAbiertokind/chore kind/cleanup needs-area
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
rancher/turtles#2848 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
priority: low 🌱 type: enhancement 💅🏼
Dificultad 2/5 Medio día Aptitud para principiantes 84/100
nebari-dev/llm-serving-pack#199 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
kedacore/keda#8225 · 1 comentario ·
Los mantenedores suelen responder en 1 día