Self-hosted Embed: snapshot marked successful crashes on restore
Maintainer thường phản hồi trong vòng 1 ngày
@svalleru đang làm issue này rồi.
Từ ngày 23/9/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 1.6k
- Fork
- 438
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của e2b-dev/runtime
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running stateĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của e2b-dev/runtime
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
volodya-lombrozo/aidy#333 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
rossoctl/context-guru#314 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
OwO-Network/DLX#236 · 1 bình luận · 1 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100