[libvirt] [PATCH] add a default event handle, to passthough the new events come from qemu

ShaoHe Feng shaohef at linux.vnet.ibm.com
Fri Dec 2 10:52:31 UTC 2011

Hi Eric,

There's a question about register an Event.

When user starts an application call
remoteDispatchDomainEventsRegisterAny to register an event.
And for some reasons,  this application breaks down.
Will the libvirtd daemon know the application breaks down? And delete
the event?

if not,  then user restarts this  application, it will register an event

but the libvirtd daemon has already register this event, so it return error.

and then application did not know why this fails, And it will not
register this event again.

is this right?

, Eric Blake wrote:
> On 10/13/2011 08:53 PM, shu ming wrote:
>>> Also I think it would be better if we were able to connect to explicit
>>> JSON
>>> events, rather than a catch all. THe number of events from QEMU is only
>>> going to increase over time& as it does, a 'catch all' becomes
>>> increasingly
>>> bandwidth wasteful.
>> If I understand correctly, the idea behind these functions is: the
>> application developers know there is a new QEMU event not known by
>> libvirt library yet.
>> And the developer still requests to add a callback for the new event
>> without the upgrade of libvirt . The functions above provide a QEMU
>> specific way to
>> let the application register the callback by QEMU event without much
>> intervention of libvirt. Then later if we want to promote the QEMU
>> specific way to the libvirt,
>> we should warn the application developer that the QEMU specific way is
>> obsolete.
> Yes.  Whether or not the qemu registration continues to work after the
> official libvirt event is added is a different matter, since we've
> already documented that use of libvirt-qemu is unsupported, but if it
> is possible to cheaply provide the event through both means, then
> doing that will allow more clients using the older libvirt-qemu to
> continue working without recompiling to use the newer libvirt event.

More information about the libvir-list mailing list