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

[Peter Krempa]

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:
> > > The virtlockd daemon has existed for years now, but we have never
> > > turned it on by default, requiring explicit user opt-in. This leaves
> > > users unprotected against accidents out of the box.
> > > 
> > > By turning it on by default, users will at least be protected for
> > > mistakes involving local files, and files on shared filesystems
> > > that support fcntl() (eg NFS).
> > > 
> > > In turning it on the various services files are updated to have
> > > the same dependancies for virtlockd as we have for virtlogd
> > > now, since turning the latter on exposed some gaps.
> > > 
> > > Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> > > ---
> > 
> > Unfortunately ... NACK, while I fixed quite some bugs with locking and
> > block jobs few of them are still present. Mostly non-active layer block
> > commit where we will leak the locked file once we finish the job as we
> > are not tracking the job progress ( and nor can we properly do so since
> > qemu jobs vanish right after finishing). I discussed it today with Kevin
> > Wolf and John Snow and they plan to add a way for the jobs to linger.
> 
> Can't we detrect completion / error via the the block job events, even
> if the actual job object itself vanishes ? The events look like that

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.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170202/c8e8d820/attachment-0001.sig>