On Wed, May 27, 2026 at 13:03:36 +0200, Marek Marczykowski-Górecki wrote: > On Wed, May 27, 2026 at 11:46:35AM +0200, Peter Krempa wrote: > > On Thu, May 21, 2026 at 12:43:13 +0200, Marek Marczykowski-Górecki wrote: > > > Hi, > > > > > > What should be the events fired when VM requests reboot? Currently the > > > libxl driver fires VIR_DOMAIN_EVENT_STOPPED, and if on_reboot is set to > > > restart, it fires VIR_DOMAIN_EVENT_STARTED next to it (in fact, _STARTED > > > > So that is VIR_DOMAIN_EVENT_ID_LIFECYCLE. > > > > That one should be emitted only when the state of the VM changes, so > > usually not only on guest OS reboot. The question though is if that is > > the case e.g. in the xen paravirt cases where I'm not sure if it's > > considered to still be the same instance. (e.g. if the domain ID > > changed). > > > > If it did change there isn't much we can do. We could have a better > > 'reason' value for it. > > Yes, guest reboot in Xen does change domain ID (technically, it's > possible to make it not change, but that's a bad idea for many reasons). > > > Currently the supported reasons are: > > > > VIR_DOMAIN_EVENT_SHUTDOWN_FINISHED < on action (e.g. via virsh) > > VIR_DOMAIN_EVENT_SHUTDOWN_GUEST < when the guest OS initiated it > > VIR_DOMAIN_EVENT_SHUTDOWN_HOST < when it was e.g. killed > > > > > gets fired before _STOPPED here, but it's another issue). What I'd like > > > to do, is to set on_reboot to destroy, but still receive information > > > whether VM requested just shutdown or reboot, so my application (qubesd > > > daemon) can act on it. > > > > > > I see VIR_DOMAIN_EVENT_ID_REBOOT, but it's not used in libxl. What's the > > > intended semantic of it? Should it be fired next to the lifecycle event > > > (VIR_DOMAIN_EVENT_STOPPED/VIR_DOMAIN_EVENT_STARTED)? Or instead? Is it > > > okay to fire it even if on_reboot=destroy? > > > > So in the 'qemu' driver when the VM reboots and is configured to run > > VIR_DOMAIN_EVENT_ID_REBOOT is emitted: > > > > event 'reboot' for domain 'cd' > > > > On the other hand if onReboot is set to destroy the VM only the > > LIFECYCLE events will be emitted: > > > > event 'lifecycle' for domain 'cd': Shutdown Finished after guest request > > event 'lifecycle' for domain 'cd': Stopped Shutdown > > > > If onReboot is set to 'destroy' though the events are the same if the > > guest OS invokes a shutdown. > > > > Thus it's not possible currently to differentiate the situations. In > > case of the qemu driver we don't even get the 'RESET' event if the > > action is to terminate the VM so I don't think it's technically feasible > > to do what you want at least in the qemu driver. > > Hm, I see. Would it be okay to to emit VIR_DOMAIN_EVENT_ID_REBOOT in > libxl (Xen) driver when domain requested reboot (so, differently to qemu > driver), even if it got destroyed (based on onReboot=destroy)? Or maybe
The documentation for 'VIR_DOMAIN_EVENT_ID_REBOOT' is basically non-existant. I think it could make sense to have that event even when it's followed by an event stating that the VM was stopped. > introduce another shutdown reason (VIR_DOMAIN_EVENT_SHUTDOWN_REBOOT? > _REBOOT_REQUEST?), so the application can distinguish this case? Adding a new reason works too; specifically you can document the expected behaviour; if you want to take this route please consider fixing at least the qemu driver along with xen. > > The reason I don't want onReboot=restart is, qubesd needs to do a few > extra steps before domain can start again, and doing that in parallel > with already starting domain would be racy. That makes sense.
