[PATCH 0/2] libxl: Fire reboot event
The driver libxl already detects when the shutdown reason is to reboot, but it was not firing the "VIR_DOMAIN_EVENT_ID_REBOOT" when that happened. I added support for the event to be fired when the reasons are "restart" or "destroy", later explained in the commit messages why "destroy" is included" I have tested this patch series on Qubes OS with Xen 4.19.5. CI: https://gitlab.com/libvirt/libvirt/-/merge_requests/567 Ben Grande (2): libxl: Fire reboot event NEWS: Document libvirt event for Xen reboot NEWS.rst | 3 +++ docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 4 files changed, 21 insertions(+), 4 deletions(-) -- Benjamin Grande
Fired on "on_reboot" values "restart" and "destroy", so event listeners can react to this request. The value "destroy" is useful for applications that have routines run between restarts, therefore the reboot event is still fired in this case. If the value is set to "preserve" then it doesn't seem appropriate to fire reboot event. Resolves: https://github.com/QubesOS/qubes-issues/issues/8196 Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 3 files changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index e4eb2d9ba3..a5388c5d11 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2047,9 +2047,17 @@ Each of these states allow for the same four possible actions. The domain will be terminated and then restarted with a new name. (Only supported by the libxl hypervisor driver.) -QEMU/KVM/HVF supports the ``on_poweroff`` and ``on_reboot`` events handling the -``destroy`` and ``restart`` actions, but the combination of ``on_poweroff`` set -to ``restart`` and ``on_reboot`` set to ``destroy`` is forbidden. +QEMU/KVM/HVF/XEN supports the ``on_poweroff`` and ``on_reboot`` events handling +the ``destroy`` and ``restart`` actions, in which case, a notification is +available when the reboot fires, using the event ID +``VIR_DOMAIN_EVENT_ID_REBOOT``. + +Setting ``on_reboot`` to ``destroy``, prevents libvirt from restarting the +domain on its own, thus allowing a VMM that monitors +``VIR_DOMAIN_EVENT_ID_REBOOT``, to run their own stop and start procedures. + +The combination of ``on_poweroff`` set to ``restart`` and ``on_reboot`` set to +``destroy`` is forbidden. The ``on_crash`` event supports these additional actions :since:`since 0.8.4`. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index acd9ffc44b..95764ebd2b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1779,7 +1779,9 @@ virDomainShutdownFlags(virDomainPtr domain, unsigned int flags) * Note that the guest OS may ignore the request. * Additionally, the hypervisor may check and support the domain * 'on_reboot' XML setting resulting in a domain that shuts down instead - * of rebooting. + * of rebooting. Depending on the hypervisor and 'on_reboot' setting, + * VIR_DOMAIN_EVENT_ID_REBOOT might be emitted. For more information, see + * https://libvirt.org/formatdomain.html#events-configuration * * If @flags is set to zero, then the hypervisor will choose the * method of shutdown it considers best. To have greater control diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 51dc3edcc2..ab9df080ac 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -550,10 +550,14 @@ libxlDomainShutdownThread(void *opaque) VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN); switch ((virDomainLifecycleAction) vm->def->onReboot) { case VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm)); libxlDomainShutdownHandleDestroy(driver, vm); goto endjob; case VIR_DOMAIN_LIFECYCLE_ACTION_RESTART: case VIR_DOMAIN_LIFECYCLE_ACTION_RESTART_RENAME: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm)); libxlDomainShutdownHandleRestart(driver, vm); goto endjob; case VIR_DOMAIN_LIFECYCLE_ACTION_PRESERVE: -- Benjamin Grande
On 10/13/26 7:06 AM, Ben Grande wrote:
Fired on "on_reboot" values "restart" and "destroy", so event listeners can react to this request. The value "destroy" is useful for applications that have routines run between restarts,
It might be useful for your application, but IMO could be very confusing to others. More below...
therefore the reboot event is still fired in this case. If the value is set to "preserve" then it doesn't seem appropriate to fire reboot event.
Resolves: https://github.com/QubesOS/qubes-issues/issues/8196 Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index e4eb2d9ba3..a5388c5d11 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2047,9 +2047,17 @@ Each of these states allow for the same four possible actions. The domain will be terminated and then restarted with a new name. (Only supported by the libxl hypervisor driver.)
-QEMU/KVM/HVF supports the ``on_poweroff`` and ``on_reboot`` events handling the -``destroy`` and ``restart`` actions, but the combination of ``on_poweroff`` set -to ``restart`` and ``on_reboot`` set to ``destroy`` is forbidden. +QEMU/KVM/HVF/XEN supports the ``on_poweroff`` and ``on_reboot`` events handling +the ``destroy`` and ``restart`` actions, in which case, a notification is +available when the reboot fires, using the event ID +``VIR_DOMAIN_EVENT_ID_REBOOT``.
This sentence is a bit unclear IMO. It groups on_poweroff + on_reboot together, then says "notification is available when the reboot fires". I'd suggest two sentences, with the second one explicitly scoped. E.g. QEMU/KVM/HVF/XEN supports the on_poweroff and on_reboot events handling the destroy and restart actions. For on_reboot, a notification is available via VIR_DOMAIN_EVENT_ID_REBOOT when the guest-initiated reboot is detected.
+ +Setting ``on_reboot`` to ``destroy``, prevents libvirt from restarting the +domain on its own, thus allowing a VMM that monitors +``VIR_DOMAIN_EVENT_ID_REBOOT``, to run their own stop and start procedures.
This is an unrelated doc improvement and should be a separate patch IMO.
+ +The combination of ``on_poweroff`` set to ``restart`` and ``on_reboot`` set to +``destroy`` is forbidden.
The ``on_crash`` event supports these additional actions :since:`since 0.8.4`.
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index acd9ffc44b..95764ebd2b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1779,7 +1779,9 @@ virDomainShutdownFlags(virDomainPtr domain, unsigned int flags) * Note that the guest OS may ignore the request. * Additionally, the hypervisor may check and support the domain * 'on_reboot' XML setting resulting in a domain that shuts down instead - * of rebooting. + * of rebooting. Depending on the hypervisor and 'on_reboot' setting, + * VIR_DOMAIN_EVENT_ID_REBOOT might be emitted. For more information, see + * https://libvirt.org/formatdomain.html#events-configuration * * If @flags is set to zero, then the hypervisor will choose the * method of shutdown it considers best. To have greater control diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 51dc3edcc2..ab9df080ac 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -550,10 +550,14 @@ libxlDomainShutdownThread(void *opaque) VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN); switch ((virDomainLifecycleAction) vm->def->onReboot) { case VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm));
This seems misleading to me. An app monitoring these events will receive a REBOOT event, when in fact the domain will be destroyed, right? AFAICT, in this case the qemu driver emits a SHUTDOWN event with detail GUEST https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_process.c?ref... Regards, Jim
libxlDomainShutdownHandleDestroy(driver, vm); goto endjob; case VIR_DOMAIN_LIFECYCLE_ACTION_RESTART: case VIR_DOMAIN_LIFECYCLE_ACTION_RESTART_RENAME: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm)); libxlDomainShutdownHandleRestart(driver, vm); goto endjob; case VIR_DOMAIN_LIFECYCLE_ACTION_PRESERVE:
On 10/13/26 8:15 PM, Jim Fehlig wrote:
On 10/13/26 7:06 AM, Ben Grande wrote:
Fired on "on_reboot" values "restart" and "destroy", so event listeners can react to this request. The value "destroy" is useful for applications that have routines run between restarts,
It might be useful for your application, but IMO could be very confusing to others. More below...
therefore the reboot event is still fired in this case. If the value is set to "preserve" then it doesn't seem appropriate to fire reboot event.
Resolves: https://github.com/QubesOS/qubes-issues/issues/8196 Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index e4eb2d9ba3..a5388c5d11 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2047,9 +2047,17 @@ Each of these states allow for the same four possible actions. The domain will be terminated and then restarted with a new name. (Only supported by the libxl hypervisor driver.) -QEMU/KVM/HVF supports the ``on_poweroff`` and ``on_reboot`` events handling the -``destroy`` and ``restart`` actions, but the combination of ``on_poweroff`` set -to ``restart`` and ``on_reboot`` set to ``destroy`` is forbidden. +QEMU/KVM/HVF/XEN supports the ``on_poweroff`` and ``on_reboot`` events handling +the ``destroy`` and ``restart`` actions, in which case, a notification is +available when the reboot fires, using the event ID +``VIR_DOMAIN_EVENT_ID_REBOOT``.
This sentence is a bit unclear IMO. It groups on_poweroff + on_reboot together, then says "notification is available when the reboot fires". I'd suggest two sentences, with the second one explicitly scoped. E.g.
QEMU/KVM/HVF/XEN supports the on_poweroff and on_reboot events handling the destroy and restart actions. For on_reboot, a notification is available via VIR_DOMAIN_EVENT_ID_REBOOT when the guest-initiated reboot is detected.
+ +Setting ``on_reboot`` to ``destroy``, prevents libvirt from restarting the +domain on its own, thus allowing a VMM that monitors +``VIR_DOMAIN_EVENT_ID_REBOOT``, to run their own stop and start procedures.
This is an unrelated doc improvement and should be a separate patch IMO.
+ +The combination of ``on_poweroff`` set to ``restart`` and ``on_reboot`` set to +``destroy`` is forbidden. The ``on_crash`` event supports these additional actions :since:`since 0.8.4`. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index acd9ffc44b..95764ebd2b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1779,7 +1779,9 @@ virDomainShutdownFlags(virDomainPtr domain, unsigned int flags) * Note that the guest OS may ignore the request. * Additionally, the hypervisor may check and support the domain * 'on_reboot' XML setting resulting in a domain that shuts down instead - * of rebooting. + * of rebooting. Depending on the hypervisor and 'on_reboot' setting, + * VIR_DOMAIN_EVENT_ID_REBOOT might be emitted. For more information, see + * https://libvirt.org/formatdomain.html#events-configuration * * If @flags is set to zero, then the hypervisor will choose the * method of shutdown it considers best. To have greater control diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 51dc3edcc2..ab9df080ac 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -550,10 +550,14 @@ libxlDomainShutdownThread(void *opaque) VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN); switch ((virDomainLifecycleAction) vm->def->onReboot) { case VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm));
This seems misleading to me. An app monitoring these events will receive a REBOOT event, when in fact the domain will be destroyed, right? AFAICT, in this case the qemu driver emits a SHUTDOWN event with detail GUEST
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_process.c? ref_type=heads#L775
After sending, I noticed the following proposed patch adds a new SHUTDOWN event detail 'VIR_DOMAIN_EVENT_SHUTDOWN_GUEST_RESET' https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NFMQ3... Sounds appropriate for your use-case, assuming it's possible to detect a guest-initiated reboot/reset. Regards, Jim
On 26-10-13 20:34:07, Jim Fehlig wrote:
On 10/13/26 8:15 PM, Jim Fehlig wrote:
On 10/13/26 7:06 AM, Ben Grande wrote:
Fired on "on_reboot" values "restart" and "destroy", so event listeners can react to this request. The value "destroy" is useful for applications that have routines run between restarts,
It might be useful for your application, but IMO could be very confusing to others. More below...
therefore the reboot event is still fired in this case. If the value is set to "preserve" then it doesn't seem appropriate to fire reboot event.
Resolves: https://github.com/QubesOS/qubes-issues/issues/8196 Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index e4eb2d9ba3..a5388c5d11 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2047,9 +2047,17 @@ Each of these states allow for the same four possible actions. The domain will be terminated and then restarted with a new name. (Only supported by the libxl hypervisor driver.) -QEMU/KVM/HVF supports the ``on_poweroff`` and ``on_reboot`` events handling the -``destroy`` and ``restart`` actions, but the combination of ``on_poweroff`` set -to ``restart`` and ``on_reboot`` set to ``destroy`` is forbidden. +QEMU/KVM/HVF/XEN supports the ``on_poweroff`` and ``on_reboot`` events handling +the ``destroy`` and ``restart`` actions, in which case, a notification is +available when the reboot fires, using the event ID +``VIR_DOMAIN_EVENT_ID_REBOOT``.
This sentence is a bit unclear IMO. It groups on_poweroff + on_reboot together, then says "notification is available when the reboot fires". I'd suggest two sentences, with the second one explicitly scoped. E.g.
QEMU/KVM/HVF/XEN supports the on_poweroff and on_reboot events handling the destroy and restart actions. For on_reboot, a notification is available via VIR_DOMAIN_EVENT_ID_REBOOT when the guest-initiated reboot is detected.
+ +Setting ``on_reboot`` to ``destroy``, prevents libvirt from restarting the +domain on its own, thus allowing a VMM that monitors +``VIR_DOMAIN_EVENT_ID_REBOOT``, to run their own stop and start procedures.
This is an unrelated doc improvement and should be a separate patch IMO.
+ +The combination of ``on_poweroff`` set to ``restart`` and ``on_reboot`` set to +``destroy`` is forbidden. The ``on_crash`` event supports these additional actions :since:`since 0.8.4`. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index acd9ffc44b..95764ebd2b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1779,7 +1779,9 @@ virDomainShutdownFlags(virDomainPtr domain, unsigned int flags) * Note that the guest OS may ignore the request. * Additionally, the hypervisor may check and support the domain * 'on_reboot' XML setting resulting in a domain that shuts down instead - * of rebooting. + * of rebooting. Depending on the hypervisor and 'on_reboot' setting, + * VIR_DOMAIN_EVENT_ID_REBOOT might be emitted. For more information, see + * https://libvirt.org/formatdomain.html#events-configuration * * If @flags is set to zero, then the hypervisor will choose the * method of shutdown it considers best. To have greater control diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 51dc3edcc2..ab9df080ac 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -550,10 +550,14 @@ libxlDomainShutdownThread(void *opaque) VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN); switch ((virDomainLifecycleAction) vm->def->onReboot) { case VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm));
This seems misleading to me. An app monitoring these events will receive a REBOOT event, when in fact the domain will be destroyed, right? AFAICT, in this case the qemu driver emits a SHUTDOWN event with detail GUEST
Didn't post before but previous discussion about either firing the event or sending the reboot reason on shutdown: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ZB5AL... So yes, I can deal with using a shutdown reason.
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_process.c? ref_type=heads#L775
After sending, I noticed the following proposed patch adds a new SHUTDOWN event detail 'VIR_DOMAIN_EVENT_SHUTDOWN_GUEST_RESET'
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NFMQ3...
Would it be acceptable to create the event detail `VIR_DOMAIN_EVENT_STOPPED_RESET`? Only VMMs that use `VIR_DOMAIN_EVENT_SHUTDOWN` are 'qemu' and 'ch'.
Sounds appropriate for your use-case, assuming it's possible to detect a guest-initiated reboot/reset.
For reset/reboot request originating from the guest or host, Xen emits LIBXL_SHUTDOWN_REASON_REBOOT, so no distinction. -- Best regards, Benjamin Grande Invisible Things Lab
On 10/14/26 7:20 AM, Ben Grande wrote:
On 26-10-13 20:34:07, Jim Fehlig wrote:
On 10/13/26 8:15 PM, Jim Fehlig wrote:
On 10/13/26 7:06 AM, Ben Grande wrote:
Fired on "on_reboot" values "restart" and "destroy", so event listeners can react to this request. The value "destroy" is useful for applications that have routines run between restarts,
It might be useful for your application, but IMO could be very confusing to others. More below...
therefore the reboot event is still fired in this case. If the value is set to "preserve" then it doesn't seem appropriate to fire reboot event.
Resolves: https://github.com/QubesOS/qubes-issues/issues/8196 Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- docs/formatdomain.rst | 14 +++++++++++--- src/libvirt-domain.c | 4 +++- src/libxl/libxl_domain.c | 4 ++++ 3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index e4eb2d9ba3..a5388c5d11 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2047,9 +2047,17 @@ Each of these states allow for the same four possible actions. The domain will be terminated and then restarted with a new name. (Only supported by the libxl hypervisor driver.) -QEMU/KVM/HVF supports the ``on_poweroff`` and ``on_reboot`` events handling the -``destroy`` and ``restart`` actions, but the combination of ``on_poweroff`` set -to ``restart`` and ``on_reboot`` set to ``destroy`` is forbidden. +QEMU/KVM/HVF/XEN supports the ``on_poweroff`` and ``on_reboot`` events handling +the ``destroy`` and ``restart`` actions, in which case, a notification is +available when the reboot fires, using the event ID +``VIR_DOMAIN_EVENT_ID_REBOOT``.
This sentence is a bit unclear IMO. It groups on_poweroff + on_reboot together, then says "notification is available when the reboot fires". I'd suggest two sentences, with the second one explicitly scoped. E.g.
QEMU/KVM/HVF/XEN supports the on_poweroff and on_reboot events handling the destroy and restart actions. For on_reboot, a notification is available via VIR_DOMAIN_EVENT_ID_REBOOT when the guest-initiated reboot is detected.
+ +Setting ``on_reboot`` to ``destroy``, prevents libvirt from restarting the +domain on its own, thus allowing a VMM that monitors +``VIR_DOMAIN_EVENT_ID_REBOOT``, to run their own stop and start procedures.
This is an unrelated doc improvement and should be a separate patch IMO.
+ +The combination of ``on_poweroff`` set to ``restart`` and ``on_reboot`` set to +``destroy`` is forbidden. The ``on_crash`` event supports these additional actions :since:`since 0.8.4`. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index acd9ffc44b..95764ebd2b 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1779,7 +1779,9 @@ virDomainShutdownFlags(virDomainPtr domain, unsigned int flags) * Note that the guest OS may ignore the request. * Additionally, the hypervisor may check and support the domain * 'on_reboot' XML setting resulting in a domain that shuts down instead - * of rebooting. + * of rebooting. Depending on the hypervisor and 'on_reboot' setting, + * VIR_DOMAIN_EVENT_ID_REBOOT might be emitted. For more information, see + * https://libvirt.org/formatdomain.html#events-configuration * * If @flags is set to zero, then the hypervisor will choose the * method of shutdown it considers best. To have greater control diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 51dc3edcc2..ab9df080ac 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -550,10 +550,14 @@ libxlDomainShutdownThread(void *opaque) VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN); switch ((virDomainLifecycleAction) vm->def->onReboot) { case VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY: + virObjectEventStateQueue(driver->domainEventState, + virDomainEventRebootNewFromObj(vm));
This seems misleading to me. An app monitoring these events will receive a REBOOT event, when in fact the domain will be destroyed, right? AFAICT, in this case the qemu driver emits a SHUTDOWN event with detail GUEST
Didn't post before but previous discussion about either firing the event or sending the reboot reason on shutdown:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ZB5AL...
Ah, it would have been helpful to reference this in the cover letter :-).
So yes, I can deal with using a shutdown reason.
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_process.c? ref_type=heads#L775
After sending, I noticed the following proposed patch adds a new SHUTDOWN event detail 'VIR_DOMAIN_EVENT_SHUTDOWN_GUEST_RESET'
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NFMQ3...
Would it be acceptable to create the event detail `VIR_DOMAIN_EVENT_STOPPED_RESET`? Only VMMs that use `VIR_DOMAIN_EVENT_SHUTDOWN` are 'qemu' and 'ch'.
Yes, that would be fine too IMO. VIR_DOMAIN_EVENT_STOPPED is used by bhyve, ch, libxl, lxc, qemu and vz. A new VIR_DOMAIN_EVENT_STOPPED_RESET detail would ride on a universally-emitted event, whereas a new SHUTDOWN reason means libxl must adopt a lifecycle event type it's never handled before. Peter, do you have an opinion on this? BTW, to bikeshed a bit, perhaps VIR_DOMAIN_EVENT_STOPPED_REBOOT is a better name for the new detail? The related config knob is called 'on_reboot'. And REBOOT might avoid the (remote) possibility of falsely associating it with QEMU's monitor RESET event. Regards, Jim
Signed-off-by: Ben Grande <ben@invisiblethingslab.com> --- NEWS.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 6ffc803118..c40d92af28 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -19,6 +19,9 @@ v12.9.0 (unreleased) * **Improvements** + * xen: Fire ``VIR_DOMAIN_EVENT_ID_REBOOT`` on ``destroy`` and ``restart`` + ``<on_reboot>`` flags for Xen domains. + * **Bug fixes** -- Benjamin Grande
participants (2)
-
Ben Grande -
Jim Fehlig