[libvirt] [RFC] events scripts support

[Daniel Veillard]

On Tue, Mar 23, 2010 at 12:12:57PM +0000, Daniel P. Berrange wrote:
> On Tue, Mar 23, 2010 at 12:17:50PM +0100, Daniel Veillard wrote:
> >   We would like to introduce a way to configure system wide a script
> > which would be called when some event happens. The script is a single
> > executable set as a libvirtd option by the system administrator
> > (assuming one runs the system libvirtd) or the user (assuming a
> > user run libvirtd).
> >   The script could be invoked on daemon events, for example starting
> > stopping, or reloading (SIGHUP), on domain events for example before
> > a domain starts, or after its stops, and possibly on other kind of
> > events detected by the daemon (storage or interface ...)
> 
> I'd really like to avoid calling this events. This is really a means

  okay that's confusing and 'hook' is a better term

> to insert synchronous hooks into certain key places like domain startup.
> This is only really going to be usable for hypervisors/drivers where 
> libvirt is in total control of guest startup, which means QEMU, LXC &
> UML. It'll never work for things like VMWare, Xen, VirtualBox, etc
> and it will also be fairly limited in interactions with the network,
> node device drivers, and possibly even storage.

  I would not presume too much about storage and network. I'm just
opening the idea that some hooks may come from there in the future.

> The synchronous hooks will also be limited in that they must be fast
> to execute, and must not call back into libvirt - that would likely
> deadlock since this is synchronous.  The separate events daemon providing

  Yeah the deadlocking problem is something I raised in my mail.

> I think we do need to support both approaches long term, but with the
> async events being the general purpose option, and the sync hook here
> being driver specific limited use cases. 

  Still that's something I would like to see exposed for LXC too.

> >   My current thinking is to add the following two variables to
> > libvirtd.conf:
> > 
> >   # Event scripts
> >   # An optional path to a script handling various kind of events like
> >   # domain start, domain end, pre and post migration, etc...
> >   # The events_script must be a path to the script or binary handling
> >   # the
> >   # events.
> >   # The events_set is a list of space separated name for the event type
> >   # the script should receive
> >   #
> >   # events_script="/etc/libvirt/events"
> >   # events_set="daemon domain"
> 
> I think this really belongs in the QEMU driver, since I don't think this
> can be generalized to other drivers.

  I disagree, this can be used for generic daemon events as I suggested
like shutdown or restart, plus usable for lxc at least.

> > The script aruguments would be
> > 
> >    - the object kind: e.g. "domain"
> 
> If this is considered QEMU specific, we don't need 'domain' here

  I don't want this to be QEmu specific.
But I think we need to provide the driver in case of qemu/lxc/...
I think the first string should match one of the values registered in
hooks_set="daemon domain"

> >    - the object name: e.g. the domain name
> >    - the event itself: e.g. "start"
> >    - sub event qualifier: e.g. "before"
> >    - an optional extra information for example in case of migration
> >      the destination or source
> 
> That sounds sufficient. Since this is synchronous

  we probably need the uuid of the object if available ('-' otherwise)
and the driver name in case of a domain (or future network/storage)
alternatively passing the object XML as the hook script stdin is
probably the simplest way to convey a complete set of informations.

> > 
> > So for example if the two variables as set as sugegsted, 
> > 
> >   /etc/libvirt/events domain foo start before
> > 
> > would be run by the daemon before the lunch of a domain which could
> > have been initiated by the user when running "virsh foo start".
> > 
> > The script exec return value is expected to be 0 unless indicating an
> > error, in that case the libvirtd command would fail, for example
> > if the command launched for "virsh foo start" failed with an error value
> > the domain won't be started.
> > 
> > This is a new kind of API in libvirt(d) so I'm submitting this for
> > review. There could be some challenging issues, for example naming
> > i.e. is the object "external" name like 'foo' the right thing to pass
> > or should we also provide the uuid, making sure the arguments for the
> > scripts and the behaviour is generic enough, and also how to handle
> > potential recursion and avoid deadlock if the events script happen to
> > use libvirt.
> 
> You have to mandate that synchronous hooks never call back into libvirt,
> allowing them todo so will be unfeasible.

  yeah, it's getting clear that going back to libvirt will untenable.

Daniel

--
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/