vmm: keep VMM running on guest shutdown with --no-shutdown - #8025
Conversation
c15ddc0 to
5b6f396
Compare
phip1611
left a comment
There was a problem hiding this comment.
Very good to have that upstream soon!
nit: the commit messages should speak about management software in general (e.g. libvirt) and that this streamlines the behavior with QEMU.
Introduce a dedicated guest_exit_evt and a matching epoll dispatch path for guest-triggered shutdowns. This series is needed because managment software such as libvirt may still need the Cloud Hypervisor process to stay alive after the guest has shut down. Today a guest-triggered shutdown can make the VMM disappear immediately, which means the managment software can lose track of the VM run-state. This must only apply to guest-triggered shutdowns. Fatal error paths and other internal exit paths must keep using the existing VMM exit handling. For now GuestExit still calls vmm_shutdown(), so this commit only adds the separate plumbing and keeps the current behavior unchanged. On-behalf-of: SAP [email protected] Signed-off-by: Leander Kohler <[email protected]>
Plumb ACPI S5 shutdown through guest_exit_evt instead of the shared exit path. This keeps guest-triggered shutdown separate from fatal VMM exit handling. Management software, for example libvirt, expects that distinction, and making it explicit aligns Cloud Hypervisor more closely with QEMU. Only the guest shutdown path is moved here. Reboot handling stays on reset_evt and non-guest exit paths are left unchanged. On-behalf-of: SAP [email protected] Signed-off-by: Leander Kohler <[email protected]>
Add a CLI-only --no-shutdown flag that keeps the VMM process alive after a guest-triggered shutdown. Management software may still need the Cloud Hypervisor process after the guest has powered off. Exposing this separately lets management software, for example libvirt, keep the VMM around in a way that is closer to QEMU. The flag only affects the GuestExit path. Fatal exits and other existing VMM shutdown paths remain unchanged. On-behalf-of: SAP [email protected] Signed-off-by: Leander Kohler <[email protected]>
5b6f396 to
20ce194
Compare
|
I feel like this a good solution to #8005 ? |
Great, I didn't even see the open issue. @EpicStep do you have any remarks? |
|
Can you comment on that issue (or here) using the same style table with your option as additional variable |
|
@Coffeeri Thanks for this! The solution looks good to me - it should fix the issue I was experiencing 👍 |
This PR introduces a
--no-shutdownflag to the CLI, allowing higher-level management layers such as libvirt to handle guest-triggered shutdowns without losing VM state tracking. This behavior is analogous to QEMU's-no-shutdown. When the flag is set and the guest triggers a shutdown, the CH process remains running, allowing the management layer to gracefully clean up and track the shutdown VM state.We do the following:
EpollDispatch::Exitinto a newEpollDispatch::GuestExit.--no-shutdownCLI flag.vm_shutdown()instead ofvmm_shutdown(), allowing the VMM to remain active and preserving VM state for external management.This PR upstreams most of cyberus-technology#104 from our fork, with the exception of cyberus-technology@6416bbf, as the full migration implementation is not upstreamed yet.
It also closes #8005.