Daniel P. Berrangé <[email protected]> writes: > On Mon, Jul 13, 2026 at 03:57:25PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <[email protected]> writes:
[...] >> > When libvirt see a GUEST_PANICKED, it will transition the state to >> > "CRASHED" and assign a reason of "PANICKED" as the trigger / cause. >> > >> > Then depending on the guest XML config for <on_crash> it will do one >> > of >> > >> > * Take a core dump of QEMU >> > * Terminate QEMU >> > * Restart QEMU >> > * Take a core dump of QEMU and restart >> > * Leave it in crashed state (to allow a debugger to attach) >> > >> > >> > The "machine check" and "unknown VM exit" scenarios, would still map >> > to libvirt's "CRASHED" state, but we would want to assign distinct >> > "cause" for each of them. >> >> Say we add event GUEST_MACHINE_CHECK, then send it instead of >> GUEST_PANICKED on a machine check. >> >> With an updated version of libvirt, this changes exactly the "cause" >> recorded for a machine check in the "CRASHED" state. This change is >> desirable. >> >> Older versions of libvirt ignore the unknown GUEST_MACHINE_CHECK event. >> They therefore no longer take the <on_crash> action. This is >> undesirable, I'm afraid. Is it? >> >> An orderly transition could look like this: >> >> 1. Add a new event for each distinct cause, and emit the appropriate >> event in addition to GUEST_PANICKED. >> >> 2. Deprecate GUEST_PANICKED. >> >> 3. Remove GUEST_PANICKED after a suitable grace period. > > Another option is to accept "GUEST_PANICKED" as a sub-optimal name > forever and add a "source" field to the event to explain what actually > triggered it, where "source" can be "guest-os", "machine-check", ... > etc... Yes, that's a compatible extension. > Which would probably be better compatible with libvirt too > > With regards, > Daniel
