调度先检查能力，再检查容量#

普通容器主要检查节点资源和调度策略。microVM 还可能要求 KVM、特定 CPU 特性、内核模块、块设备与快照缓存。

因此调度分成两层：

1. 节点是否具备运行该引擎的能力；
2. 具备能力的节点是否仍有 CPU、内存和设备容量。

异构节点池会降低可用容量的可互换性。总资源看似充足，满足特定引擎条件的子集仍可能耗尽。

本地状态限制迁移#

容器本身通常不做运行中迁移，而是在其他节点重建并重新挂载外部状态。microVM 快照能够恢复 CPU、内存和设备状态，但快照文件、RootFS 与 Workspace 必须在目标节点可用且版本匹配。

快照因此是“可恢复材料”，不是自动迁移协议。平台仍需传输或共享文件、重新配置网络，并处理源实例与目标实例的唯一执行权。

Guest 内外需要两条观测链#

宿主侧可以看到 VMM 进程、资源占用、创建阶段和设备错误，却无法自动解释 Guest 内进程为何退出。Guest 内可以记录应用日志与 OOM，却不知道宿主调度和虚拟设备发生了什么。

完整故障定位需要关联：

1
控制面生命周期与调度
2
↕ Sandbox ID / Session ID
3
VMM 与宿主资源
4
↕ Guest 标识
5
Guest 内进程、内核与应用

容器共享宿主内核，部分信息天然可见；microVM 默认黑盒更多，必须主动建设 Guest Agent 或日志出口。

我的选择：把运营成本写入引擎合同#

我会让每个引擎明确声明节点要求、快照可移植条件和观测能力，并把 Ready 延迟拆成调度、资源、启动、挂载与应用初始化。

强隔离适合高风险任务，但需要专用节点池、快照分发和双层观测。若任务风险较低、迁移与弹性优先，容器运营成本更低。选型时只比较启动毫秒数，会遗漏真正长期支付的调度与排障成本。