Re: [libvirt] [PATCH 7/8] block: add witness argument to drive-reopen
[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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
participants (2)
-
Eric Blake -
Michal Privoznik