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 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. This is quite distinct from what the libvirt API refers to as events, which are asynchronous wrt the operation that occurred. The plus side of these type of events is that (from an architectural point of view) they can be implemented for pretty any of the libvirt hypervisor drivers. I think it would be useful to have a libvirt-events daemon that listened for these async events via our public API & invoked scripts upon certain scenarios. This is obviously separate from the synchronous hooks. 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 async scripts would have freedom for long running operations & calling back into libvirt. 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. > 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. > The script aruguments would be > > - the object kind: e.g. "domain" If this is considered QEMU specific, we don't need 'domain' here > - 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 > > 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. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list