Cloud Hypervisor reboots in-process: intentional guest reboots bypass fcvm's reboot-in-place path

[ejc3]

Summary

Follow-up to the shutdown-contract fix (PR #706 / #687): fcvm's reboot-in-place handling in run_vm_loop (src/commands/podman/mod.rs:~1289) assumes the hypervisor process exits when the guest reboots (true for Firecracker: triple-fault/PSCI reset ends the process, fcvm relaunches). Cloud Hypervisor instead performs guest resets in-process (vm_reboot() logs "Rebooting." and boots the same VM again in the same process), so an intentional guest reboot under CH never reaches fcvm's relaunch logic — the guest silently boot-cycles inside the same CH process while fcvm keeps waiting in vm_manager.wait().

PR #706 removed the shutdown path from this hazard (fcvm_shutdown=acpi makes CH guests power off, which does exit the process). This issue tracks the remaining reboot path: either drive CH reboots through its API (shutdown + relaunch to converge with the Firecracker-style lifecycle), or watch for CH's reboot event via its API socket and run the reboot-in-place bookkeeping then.

Not currently test-visible: no test intentionally reboots a CH guest. Worth closing before anything relies on guest-initiated reboot semantics under --hypervisor cloud-hypervisor.

https://claude.ai/code/session_01QBekRuBULNUgUSGYmgkjyd

[ejc3]

Still valid on main as of dfd7b3b. None of the work that landed 2026-08-16..18 touched this path.

Current state: run_vm_loop still reaches the reboot-in-place branch only after vm_manager.wait() returns, i.e. after the VMM process exits (src/commands/podman/mod.rs:1966-1998). The CH backend's wait() is a plain child wait (src/hypervisor/cloud_hypervisor/mod.rs:399) and ChClient has no reboot or event verb, only ping, vm.create/boot/pause/resume, snapshot/restore, and vmm.shutdown. The backend's own doc comment states the hazard: CH treats a guest reset as an in-process reboot and vm_manager.wait() never returns (mod.rs:152-154). PR #706's fcvm_shutdown=acpi token fixed only the shutdown verb.

Two additional data points since filing. First, the guest side is hypervisor-agnostic: the shutdown hook still sends "reboot" over vsock (fc-agent/src/vsock.rs:438), so under CH that arms reboot_requested and nothing consumes it. Beyond the silent boot-cycle, a later genuine ACPI poweroff exit gets classified as a reboot by wait_for_reboot_decision and fcvm relaunches a VM that meant to terminate. Second, the bot auto-fix (41f7f94) that set platform.on_reboot=shutdown never merged, and rightly so: upstream Cloud Hypervisor's PlatformConfig has no on_reboot field.

Plan: spawn CH with --event-monitor path=<vm_dir>/ch-events.json, tail it from the backend the same way the console tail works, and on the vm "rebooting" event call the existing ChClient::shutdown_vmm(). The process then exits at the reset boundary, wait() returns, and the already-set reboot_requested drives the existing relaunch path, which the CH backend's minimal-spec respawn (mod.rs:302, 613) already supports. No trait or run-loop change. Pin it with a CH variant of tests/test_reboot.rs, gated on find_cloud_hypervisor() like the sanity tests: reboot the guest, require health and the container back on the same fcvm PID, then a clean exit on container stop. On today's main that test wedges in the in-process boot-cycle. Needs a KVM box with a cloud-hypervisor binary to watch it fail first, so keeping this open until it can be run there.

Test coverage note: tests/test_reboot.rs exists now but only exercises Firecracker; the CH tests in test_sanity.rs never reboot, so the issue's "not currently test-visible" claim still holds.