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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list