From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBl2E-0004bO-7e for qemu-devel@nongnu.org; Wed, 23 Dec 2015 10:09:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBl2A-0008Fa-4g for qemu-devel@nongnu.org; Wed, 23 Dec 2015 10:09:02 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> From: "Denis V. Lunev" Message-ID: <567AB8FD.2080600@parallels.com> Date: Wed, 23 Dec 2015 18:08:45 +0300 MIME-Version: 1.0 In-Reply-To: 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: Vasiliy Tolstov , Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com On 12/23/2015 05:57 PM, Vasiliy Tolstov wrote: > 2015-12-22 19:46 GMT+03:00 Kevin Wolf : >> 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. > > This breaks ability to create disk only snapshot while vm is running. > Or i miss something? > you should do this by asking running QEMU not by qemu-img, which is badly wrong. Den