bug(vm-driver): VM sandbox cold start stalls ~5 s repeatedly on "Waiting for VM supervisor"
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 82/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- infrastructure
Hướng nghiên cứu
Bắt đầu với crates/openshell-driver-vm/runtime/pins.env và kiểm tra cách runtime VM ghim libkrun. Cập nhật ghim sang một bản phát hành chứa bản sửa lỗi kết nối bị từ chối từ upstream, sau đó tạo sandbox VM bằng bước tái tạo được báo cáo. Hoàn thành có nghĩa là runtime sử dụng bản phát hành đã sửa lỗi và việc tạo sandbox không còn bị treo khoảng 5 giây trong khi chờ giám sát viên VM.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
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)
- Ngôn ngữ chính
- Rust
- Star
- 13.2k
- Fork
- 1.6k
- Merge trung bình
- 1 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 343
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
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 NVIDIA/OpenShell
-
docs: document workspace and provider label capabilitiesCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởarea:docs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Sandbox-side proposal audit (CONFIG:PROPOSED and /wait decisions) names only the first endpointĐang mởstate:triage-needed
Độ 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
-
bug(driver-mxc): test helper fails to compile after gateway-name argumentCó thể đã có người làm @feloy đã nhận 2 ngày trước. Đang mởstate:triage-needed
Độ khó 1/5 Dưới một 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
-
bug: install.sh ignores XDG_CONFIG_HOME for the local gateway configCó thể đã có người làm @fede-kamel đã nhận 6 ngày trước. Đang mởarea:cli os:linux os:macos state:validated
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
NVIDIA/OpenShell#4042 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
state:triage-needed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
NVIDIA/OpenShell#3995 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của NVIDIA/OpenShell
Issue tương tự
-
Độ 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 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Update dusk-bls12_381 to 0.16Có thể đã có người làm @HDauven đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ 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 72/100
googlefonts/fontquant#43 ·