[libvirt] RFC: Add a 'reason' argument for domain events ?

Ben Guthro bguthro at virtualiron.com
Fri Nov 14 12:28:09 UTC 2008

To revisit the DEFINED, UNDEFINED topic - I have been giving this some thought, and it seems like it is redundant information to me.

Doesn't the existence of a config file define the difference between a transient and a persistent domain?
Therefore this could be tracked solely with the enum values we have? 
If a transient domain becomes persistent via adding a config file, the ADDED event would be emitted, denoting a config file came into being, and by definition changing this domain from transient, to persistent.
I'm not sure I understand the need for these events.

Moving on to the shutdown reason discussion - 
I can certainly see the need to know why a domain stopped.
That said - would it not be more consistent with the API to introduce an event "sub-type" enum to be passed alongside of the event-type, passed as a second integer?
This would reduce the size of the wire protocol, not needing to pass the full character string, as well.

This would trivially allow us finer grained notifications within a particular event.

A downside is that it may become a bit noisy for clients who may not be interested in all of the sub-events.
Perhaps we should add some sort of filtering mechanism?

-----Original Message-----
From: libvir-list-bounces at redhat.com on behalf of Daniel P. Berrange
Sent: Fri 11/14/2008 6:18 AM
To: libvir-list at redhat.com
Subject: [libvirt] RFC: Add a 'reason' argument for domain events ?
We currently have a set of domain lifecycle events


And a couple more I proposed last week to allow distinguishing of new
domains which are transient vs persistent


Previously Stefan has suggested we should consider having an event for
migration, and though I rejected that at the time, I'm now inclined to
agree that this info would be useful here. I'm also thinking I'd like
to have more information about STOPPED & STARTED events in general.

eg, there are a number of reasons why an domain may have started

 - explicitly booted on the host
 - restored from a saved image
 - incoming migration operation

and there are a number of reasons why a domain might have stopped

 - forcably destroyed by host admin
 - shutdown by host admin
 - shutdown by guest admin
 - host emulator process crashed
 - killed by mgmt after host emulation hung
 - migrated to another host
 - saved to a memory image

We have explicit events for the SAVED/RESTORED reasons, but what should
we do about the other reasons ?

One option is to add alot more events

  VIR_DOMAIN_MIGRATED_IN   (migrated to another node)
  VIR_DOMAIN_MIGRATED_OUT  (migrated from another node)
  VIR_DOMAIN_SHUTDOWN      (graceful shutdown by host admin)
  VIR_DOMAIN_DESTROYED     (force destroyed by host admin)
  VIR_DOMAIN_CRASHED       (guest kernel crashed)
  VIR_DOMAIN_HUNG          (host emulator hung)

leaving STOPPED to just be a generic stop event, with no particular

The downside with this, is if an application just wants to know about 
whether a domain shutdown, not why, then they have to track lots and
lots of events.

Also, not every driver  would be able to provide all of these events,
so would often have to fallback on a generic STOPPED event 

So one alternative is to provide a generic 'char * reason' with each 
event with provides scope on the cause of the lifecycle operation.
So you'd get

  VIR_DOMAIN_STOPPED  ("crashed", "shutdown", "destroyed",
                       "quit", "hung", "migrated", "saved")
  VIR_DOMAIN_STARTED  ("booted", "migrated", "restored")

nb, we could remove the explicit SAVED and RESTORED events in this style.

With such a 'reason' arg, we could possibly avoid adding the DEFINED
and UNDEFINED events I suggested. Instead, adding a reason for ADDED
and REMOVED events,

   VIR_DOMAIN_ADDED    ("started", "defined")
   VIR_DOMAIN_REMOVED  ("shutdown", "undefined")

which lets you distinguish transient from persistent domains. The downside
of this though, is that we can't explicitly track when a configuration
file is 're-defined', eg adding a config file for an existing running

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Libvir-list mailing list
Libvir-list at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20081114/67136448/attachment-0001.htm>

More information about the libvir-list mailing list