9:15 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/