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:
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
On Mon, Oct 21, 2024 at 12:34:23PM -0000, hector.cao@canonical.com wrote: 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://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>