[libvirt] [PATCH 7/8] block: add witness argument to drive-reopen

[Michal Privoznik]

On 17.04.2012 14:09, Eric Blake wrote:
> [adding libvir-list for some interesting discussions on potential
> libvirt design issues]
> 
> On 04/17/2012 12:47 AM, Paolo Bonzini wrote:
>> Il 16/04/2012 23:55, Eric Blake ha scritto:
>>>> Do transient guests have persistent storage for them in /var while they
>>>> are running?
>>>
>>> Yes - that's how libvirt tracks the pid of the qemu process that it
>>> should be re-attaching to on a libvirtd restart, as well as several
>>> other aspects (for example, the capabilities of the qemu binary running
>>> that pid, in case qemu has been upgraded in the meantime).  It's just
>>> that right now, the files that libvirt stores in /var are intended to be
>>> internal to libvirt, so management apps shouldn't be poking around in
>>> there, so much as having an interface to ask libvirt what state things
>>> are in.
>>
>> Can libvirtd report the block-job-completed event to vdsm before the
>> transient-domain-died event?
> 
> Yes, it should be possible to organize the code so that on libvirtd
> restart, libvirt is careful to emit all other events, such as block-job
> completed/failed, prior to the final domain died event as libvirt cleans
> out its records of the dead domain.  But it probably involves quite a
> bit of code cleanup on libvirt's side to reach that state.  There's also
> the question of whether vdsm will be listening to the events soon
> enough; after all, when libvirtd restarts, libvirt is doing quite a bit
> of bookkeeping before even accepting connections, and if vdsm isn't
> connected to the restarted libvirt at the time libvirt queues up an
> event to be sent, then the event is lost.  Maybe that implies that
> libvirt needs to have a configurable-depth array of prior events that
> can be played back to the user on request.

That imply we need an API to hold up emitting events so user can
re-register callbacks. That is - store tem in a internal array. And
another to replay events = flushing the internal array.
Or even better, substitute 1st API with new switch to be passed to the
daemon. Because on libvirtd reconnection to qemu sockets we will
instantly get all pending events. So it gives really short time for user
apps to issue such API (if any).

What I mean:
1. libvirtd --listen --hold-up-events
2. conn = virConnectOpen*(...);
3. virConnectDomainEventRegister*(conn, ...);
4. virConnectReplayEvents(conn);

Michal