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