Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Dec 23, 2015 at 03:41:01PM +0300, Denis V. Lunev wrote:
> On 12/23/2015 03:29 PM, Daniel P. Berrange wrote:
> >On Wed, Dec 23, 2015 at 03:15:50PM +0300, Roman Kagan wrote:
> >>On Wed, Dec 23, 2015 at 10:47:22AM +0000, Daniel P. Berrange wrote:
> >>>On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote:
> >>>>As an alternative, can we introduce .bdrv_flock() in protocol drivers, with
> >>>>similar semantics to flock(2) or lockf(3)? That way all formats can benefit,
> >>>>and a program crash will automatically drop the lock.
> >>>FWIW, the libvirt locking daemon (virtlockd) will already attempt to take
> >>>out locks using fcntl()/lockf() on all disk images associated with a VM.
> >>Is it even possible without QEMU cooperating?  In particular in complex
> >>cases with e.g. backing chains?
> >Yes, libvirt already has to know & understand exactly what chains are
> >in use in order to grant correct permissions via SELinux/AppArmour.
> >Once it knows that it can also deal with acquiring suitable locks.
> >
> >>This was exactly the reason why we designed the "lock" option to take an
> >>argument describing the locking mechanism to be used (see the tentative
> >>patchset Denis posted in this thread).  The only one currently
> >>implemented is flock()-based; however it can be extended to other
> >>mechanisms like network / cluster / SAN lock managers, etc.  In
> >>particular, it can be made to talk to virtlockd.
> >NB flock() doesn't work reliably / portably on NFS. Many impls
> >would treat it as a no-op. Other impls would only acquire the
> >lock on the local NFS client, not the server. Apparently Linux
> >now[1] transparently converts flock() into fcntl() locks on NFS
> >only, so you now have the problem that any close() will release
> >the lock. So IMHO flock() is even less usable than fcntl() as
> >a result.
> >
> >Regards,
> >Daniel
> >
> >[1]http://0pointer.de/blog/projects/locking.html
> Do you suggest to implement connection FROM qemu-img etc stuff
> to libvirt and query libvirt about this?
> 
> This is absolutely fine actually, why not. We can made lock mechanics
> with type 'libvirt' exactly in the same way as flock. This approach
> should satisfy all needs and users.

You want libvirt to use its locking APIs any time it has to invoke
qemu-img.

For case where people are not using libvirt, but running qemu-img
directly having qemu-img call back into libvirt isn't going to
help IMHO. Those people are already not paying attention to the
docs, so they're also not going to remember to add the command
line to tell qemu-img to talk to libvirt. So its pretty pointless
to have qemu-img talk to libvirt IMHO, as well as adding complexity
by creating a mutual two-way dependancy which is undesirable.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|