From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBici-0000KH-LN for qemu-devel@nongnu.org; Wed, 23 Dec 2015 07:34:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBice-0002xT-HX for qemu-devel@nongnu.org; Wed, 23 Dec 2015 07:34:32 -0500 Date: Wed, 23 Dec 2015 12:34:19 +0000 From: "Daniel P. Berrange" Message-ID: <20151223123419.GK20028@redhat.com> References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> <20151223104722.GB20028@redhat.com> <20151223121549.GA6247@rkaganb.sw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151223121549.GA6247@rkaganb.sw.ru> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Kagan , Fam Zheng , Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@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 :|