Re: [libvirt] [PATCH] qemu: turn on virtlockd by default

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