[libvirt] [RFC] events scripts support

[Daniel P. Berrange]

On Tue, Mar 23, 2010 at 03:15:27PM +0100, Daniel Veillard wrote:
> 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"

It is fine if different drivers implement a similar scheme, just that
the hook location must be separate for each driver. For example, consider
someone sets up a hook for QEMU

   /etc/libvirt/events/myhook.sh

then in the next release we enable these hooks for LXC too. The myhook.sh
script they provided cannot be assumed to work with the LXC driver.

Thus we need to have separate hook directoriess for each driver. They should
of course all follow the same design for sake of consistency. In the
same way that we standardized on /etc/libvirt/$DRIVERNAME/ for XML config
files, we should standardize on /etc/libvirt/hooks/$DRIVERNAME/ for the
hook scripts directory location. We don't need to make this directory
configurable in the libvirtd.conf - it should be a fixed location & on by
default - no config required.

> 
> > >    - 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.

UUID is worthwhile, but I think driver name should be used to set the 
actual directory in which the hook lives, rather than being a parameter.

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