By "REBOOTED", do you mean VIR_DOMAIN_EVENT_STARTED_REBOOTED ?

If yes, do you suggest adding this detail/reason to each lifecycle event caused by a reboot ?

Then, we will also have :
- VIR_DOMAIN_EVENT_SHUTDOWN_REBOOTED
- VIR_DOMAIN_EVENT_STOPPED_REBOOTED
- VIR_DOMAIN_EVENT_RESUMED_REBOOTED

Best regards,

On Mon, Oct 21, 2024 at 2:40 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Mon, Oct 21, 2024 at 12:34:23PM -0000, hector.cao@canonical.com wrote:
> Hello Zhenzhong and Daniel,
>
> With this implementation, upon TD reboot, some events VIR_DOMAIN_EVENT_ID_LIFECYCLE are emitted (STARTED, STOPPED and probably SHUTDOWN and RESUMED).
>
> For normal VM, only the event VIR_DOMAIN_EVENT_ID_REBOOT is emitted.
>
> Do you think it is good to align the API for TD VM and normal VM ? So the reboot of a TD VM will be transparent to existing control plane software ?
>
> I would like to ask because we have a complaint about control plane software being broken because it only expects to receive the event VIR_DOMAIN_EVENT_ID_REBOOT.

I think the difference in events, while annoying, is the right thing
to have, becasue the fact that QEMU is shutoff & re-spawned can have
implications for integration into the system & thus should be reflected.

To make it slightly nicer though, we should make sure that the lifecycle
event "reason" detail, reports "REBOOTED" as the cause. That would let
control plane software understand that these events are from a fake
reboot.

With regards,
Daniel
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



--
Hector CAO
Software Engineer – Partner Engineering Team
hector.cao@canonical.com
https://launchpad.net/~hectorcao