From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJHSx-00023b-PS for qemu-devel@nongnu.org; Wed, 13 Jan 2016 04:11:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJHSw-0007mT-NY for qemu-devel@nongnu.org; Wed, 13 Jan 2016 04:11:43 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> <20151223104722.GB20028@redhat.com> <20160111171415.GK9454@noname.redhat.com> <87oacpoo2l.fsf@blackfin.pond.sub.org> From: "Denis V. Lunev" Message-ID: <569614AE.1000200@parallels.com> Date: Wed, 13 Jan 2016 12:11:10 +0300 MIME-Version: 1.0 In-Reply-To: <87oacpoo2l.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; 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: Markus Armbruster , Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com On 01/13/2016 11:56 AM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 23.12.2015 um 11:47 hat Daniel P. Berrange geschrieben: >>> On Wed, Dec 23, 2015 at 11:14:12AM +0800, Fam Zheng wrote: >>>> On Tue, 12/22 17:46, Kevin Wolf wrote: >>>>> Enough innocent images have died because users called 'qemu-img >>>>> snapshot' while >>>>> the VM was still running. Educating the users doesn't seem to be a working >>>>> strategy, so this series adds locking to qcow2 that refuses to >>>>> access the image >>>>> read-write from two processes. >>>>> >>>>> Eric, this will require a libvirt update to deal with qemu >>>>> crashes which leave >>>>> locked images behind. The simplest thinkable way would be to >>>>> unconditionally >>>>> override the lock in libvirt whenever the option is present. In that case, >>>>> libvirt VMs would be protected against concurrent non-libvirt >>>>> accesses, but not >>>>> the other way round. If you want more than that, libvirt would >>>>> have to check >>>>> somehow if it was its own VM that used the image and left the >>>>> lock behind. I >>>>> imagine that can't be too hard either. >>>> The motivation is great, but I'm not sure I like the side-effect that an >>>> unclean shutdown will require a "forced" open, because it makes >>>> using qcow2 in >>>> development cumbersome, and like you said, management/user also >>>> needs to handle >>>> this explicitly. This is a bit of a personal preference, but it's >>>> strong enough >>>> that I want to speak up. >>> Yeah, I am also not really a big fan of locking mechanisms which are not >>> automatically cleaned up on process exit. On the other hand you could >>> say that people who choose to run qemu-img manually are already taking >>> fate into their own hands, and ending up with a dirty image on unclean >>> exit is still miles better than loosing all your data. >>> >>>> 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. >> Does this actually mean that if QEMU did try to use flock(), it would >> fail because libvirt is already holding the lock? >> >> I considered adding both locking schemes (the qcow2 flag for qcow2 on >> any backend; flock() for anything else on local files), but if this is >> true, that's game over for any flock() based patches. > "Game over" for any patches that use the same locking mechanism as > libvirt without coordinating with libvirt. > > Of course, patches that use a new locking mechanism will almost > certainly need some libvirt work, too. > > Can we come up with a more integrated solution where QEMU cooperates > with libvirt on locking when libvirt is in play, and does a more limited > job itself when libvirt isn't in play? > for me this seems viable. But this requires a serious efforts to do and serious coordination. How this could be done and how this could be coordinated with the current state of uncertainty. Den