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@xxxxxxxxxx> > > --- > > 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 contain enough info to correlate back to libvirt's record of the job. This would avoid reliance on a new QEMU release Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
