Hi -
We have some folks looking into the implementation of events (just VM
state transition events, for now) in libvirtd. I've been assuming that
events will be XML strings, something like:
<event type="domain-state-transition" timestamp="xxxxx">
<domain-id>22</domain-id>
<old-state>nostate</old-state>
<new-state>running</new-state>
</event>
where the contents of the <event> element are determined by the event
type, and the attributes type and timestamp are required.
Originally, I was thinking one would listen for events by registering
a callback, something like:
int virConnectAddEventHandler(virConnPtr conn, char **filter,
virEventHandler handler, void *arg)
where filter is either NULL, indicating interest in all events, or else
a NULL-terminated vector of event type names, allowing filtering by
event type. void handler(conn, const char *eventXML, arg) would be
called for each matching event.
I'm a little concerned that a vector of event type names isn't really
adequate for specifying a filter. Does this need to be more general
(XPathString exprs??)
But my larger concern is that an asynchronous callback mechanism (as
proposed above) assumes the presence of some thread / process from which
to make the callbacks. This works fine in the libvirtd context, but
not outside of it. For instance, we build a "client only" version of
libvirt with ONLY the remote driver, which currently doesn't require
pthreads at all. Introducing asynchronous callbacks into the API means
pthreads is now required for this.
I'm not sure how much requiring this extra thread matters. If it does,
we could always define a synchronous delivery mechanism instead. For
instance, we could have a virDeliverEvents(conn) call to make the
callbacks for any outstanding events. Or we could just dispense with
callbacks altogether, and return a readable (pipe) fd from which the
client can read events.
Comments??
Dave
P.S. We'll also need an internal API for sending events (most likely, an
extension of the existing virEvent stuff), but let's get the basic shape
of the external interface agreed upon first.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list