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