From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBygw-0002tS-Mo for qemu-devel@nongnu.org; Thu, 24 Dec 2015 00:43:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBygv-00022S-QG for qemu-devel@nongnu.org; Thu, 24 Dec 2015 00:43:58 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> From: "Denis V. Lunev" Message-ID: <567B860F.5080902@parallels.com> Date: Thu, 24 Dec 2015 08:43:43 +0300 MIME-Version: 1.0 In-Reply-To: <1450802786-20893-1-git-send-email-kwolf@redhat.com> 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: Kevin Wolf , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, mreitz@redhat.com On 12/22/2015 07:46 PM, 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. > > Also note that this kind of depends on Max's bdrv_close_all() series, but only > in order to pass test case 142. This is not a bug in this series, but a > preexisting one (bs->file can be closed before bs), and it becomes apparent > when qemu fails to unlock an image due to this bug. Max's series fixes this. > > This approach has a hole with qcow2_invalidate_cache() The lock is released (and can't be kept by design) in between qcow2_close()/qcow2_open() sequences if I understand this correctly. Den