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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)