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: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?
> 
> 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, libvirt generally considers QEMU to be untrustworthy, which is
another reason why we use virtlockd to acquire the locks *prior*
to granting QEMU any access to the file(s). On this basis we would
not really trust QEMU to do acquire/release locks itself by talking
to virtlockd. Indeed, we'd not really trust QEMU locking at all, no
matter what mechanism it used - we want strong guarantee of locking
regardless of whether QEMU is broken / compromised.

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