On Thu, Feb 02, 2017 at 10:02:54 +0000, Daniel Berrange wrote:
On Thu, Feb 02, 2017 at 10:58:50AM +0100, Peter Krempa wrote:
> On Wed, Feb 01, 2017 at 18:11:28 +0000, Daniel Berrange wrote:
> > On Wed, Feb 01, 2017 at 07:04:54PM +0100, Peter Krempa wrote:
> > > On Wed, Feb 01, 2017 at 16:54:01 +0000, Daniel Berrange wrote:
[..]
> We can and we do, the problem is only if libvirt would not run
at that
> point, when it's hard to re-detect what's happening. We also don't
track
> which job we've started for non-active commit and block pull and thus
> can't infer from the backing chain which was dropped.
>
> > contain enough info to correlate back to libvirt's record of the job.
>
> Well it won't be that hard to fix for the active case. We need to track
> the backing chain fully anyways. The problem only remains in case when
> we need to infer whether it was or wasn't successful if we missed the
> event.
>
> I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=1405537 a while
> ago so that I don't forget about this issue.
>
> I'm currently working on the support for blockdev-add and friends so
> this work will be somewhat relevant to that. I'll let you know once all
> known locking issues are resolved.
So based on the above we only have a show stopper problem if libvirtd
is restarted while a job is running. IMHO if we can make job handling
Yes, if the block job finishes/fails while libvirtd is not running the
file will remain locked forever. I still consider that a serious problem
since you can't recover from that and the image stays locked.
The tracking of the block job is still required though and we don't do
that currently.
reliable while libvirtd is running that is good enough to let us
enable
Off topic: I'd rather not make "good enough" a sufficient measure for
adding stuff to libvirt ...
virtlockd by default, without needing to wait for QEMU improvements.
Peter