Harden VMM lifecycle consistency across update, reload, and removal
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 重构
- 描述清晰度
- 需要澄清
- 活跃度
- 冷清
- 技术栈
- rust
调研方向
首先定位 issue 中描述的 UpdateVm、reload、removal、lifecycle serialization、manifest、disk-resize 和 CID-allocation 入口点。先跟踪它们的变更和恢复路径,然后定义一致性行为,并添加涵盖部分写入、CID 重用、reload/removal 竞争以及重启恢复的故障注入测试和并发操作测试。
由索引模型根据 Issue 内容生成。
描述
Problem
VMM lifecycle operations update files, disk metadata, in-memory state, the CID pool, and supervisor processes across multiple steps. These steps are not consistently validated, serialized, or rolled back.
Review of #766 exposed the following independent issues. They are not part of the no-TEE feature and should be addressed separately.
Findings
UpdateVmwrites the compose file, encrypted environment, and user config before later resource and manifest operations complete. A later failure leaves a partial update.- Disk resize occurs before manifest persistence and VM reload. A later failure can leave the qcow2 virtual size inconsistent with the manifest.
- Manifest writes use a direct file write, so interruption can leave a truncated manifest.
storage_fsis derived from the image command line and app compose on each load. Changing either can change the expected filesystem for an existing disk.- Start, stop, update, reload, and removal are not serialized per VM. Concurrent operations can observe or overwrite intermediate state.
- Reload rebuilds CID occupancy from running supervisor processes but does not preserve CIDs owned by stopped in-memory VMs. A new VM can reuse an existing CID. Supervisor processes excluded by annotation parsing may also fail to reserve their CIDs.
- User removal awaits port-forward cleanup after writing
.removingbut before spawning background cleanup. Cancellation of the RPC future can leave removal marked but not progressing until reload or restart. - Orphan cleanup and reload can race: cleanup may finalize after reload has recreated state for the same VM and CID.
The existing .removing marker already provides restart recovery and should remain the durable source of removal intent.
Suggested direction
- Validate the complete update before the first mutation.
- Define transactional file and disk update behavior, including rollback or an ordering that cannot expose inconsistent state.
- Serialize lifecycle operations per VM and define lock ordering for reload and CID allocation.
- Rebuild CID ownership from both supervisor state and loaded stopped VMs, rejecting ownership conflicts.
- Spawn removal cleanup before the RPC can be cancelled, while preserving
.removingrecovery. - Add failure-injection and concurrent-operation tests for partial writes, disk resize failure, CID reuse, reload/removal races, and process restart.
Context
These findings came from review of #766. The experimental fixes were removed from that PR to keep it scoped to development-only no-TEE support.
- 主要语言
- Rust
- 星标
- 551
- 派生
- 97
- 平均合并
- 1 天 8 小时
- 30 天内合并 PR
- 182
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Dstack-TEE/dstack 的其他 Issue
-
难度 5/5 一周以上 新手友好度 35/100
Dstack-TEE/dstack#1384 ·
-
难度 5/5 一周以上 新手友好度 30/100
Dstack-TEE/dstack#1301 ·
-
难度 3/5 1-2 天 新手友好度 55/100
Dstack-TEE/dstack#1300 ·
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1299 ·
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1298 ·
查看 Dstack-TEE/dstack 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
BurntSushi/jiff#653 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
ZcashFoundation/zeeder#106 ·
-
难度 2/5 1-3 小时 新手友好度 76/100
oxidize-rb/rb-sys#807 ·
-
难度 2/5 1-3 小时 新手友好度 88/100
-
todo:ticket
难度 2/5 1-2 天 新手友好度 74/100