[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.