From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBip6-0006Pf-8F for qemu-devel@nongnu.org; Wed, 23 Dec 2015 07:47:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBip5-0007KW-BP for qemu-devel@nongnu.org; Wed, 23 Dec 2015 07:47:20 -0500 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> <20151223123419.GK20028@redhat.com> From: "Denis V. Lunev" Message-ID: <567A97C4.2020201@parallels.com> Date: Wed, 23 Dec 2015 15:47:00 +0300 MIME-Version: 1.0 In-Reply-To: <20151223123419.GK20028@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Roman Kagan , Fam Zheng , Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com On 12/23/2015 03:34 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? >> >> 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 this is not the case we are trying to solve here. Here customer accidentally called 'qemu-img snapshot' and face his doom in ruined image. How can we will be able to find proper libvirtd in the case of network filesystem inside client swarm? This daemon is local to the host. Filesystem locking can be used in the hope that setup is consistent. Den