From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJiSj-00086Y-Ef for qemu-devel@nongnu.org; Thu, 14 Jan 2016 09:01:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJiSd-0005jc-Iu for qemu-devel@nongnu.org; Thu, 14 Jan 2016 09:01:17 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> From: Max Reitz Message-ID: <5697AA1D.5020007@redhat.com> Date: Thu, 14 Jan 2016 15:01:01 +0100 MIME-Version: 1.0 In-Reply-To: <1450802786-20893-1-git-send-email-kwolf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="voapm2OdT0XKL0JunbekknxC6h3kQeEQf" 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --voapm2OdT0XKL0JunbekknxC6h3kQeEQf Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 22.12.2015 17:46, Kevin Wolf wrote: > Enough innocent images have died because users called 'qemu-img snapsho= t' while > the VM was still running. Educating the users doesn't seem to be a work= ing > strategy, so this series adds locking to qcow2 that refuses to access t= he image > read-write from two processes. >=20 > Eric, this will require a libvirt update to deal with qemu crashes whic= h leave > locked images behind. The simplest thinkable way would be to unconditio= nally > override the lock in libvirt whenever the option is present. In that ca= se, > 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 behi= nd. I > imagine that can't be too hard either. >=20 > Also note that this kind of depends on Max's bdrv_close_all() series, b= ut 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 appa= rent > when qemu fails to unlock an image due to this bug. Max's series fixes = this. Here's another crazy idea around the issue which kind of locking to choose: We could implement both. Our main issue is that we currently do not protect users not using any management stack against wrongly invoking a second qemu/qemu-img instance on a qcow2 image that's already in use. We have to assume that these users will not specify any locking option, so our default choice needs to work here. Both flock() and format locking would work here fine.= Then there are users which use old libvirt versions and new qemu versions. I know Eric doesn't care about this, but I do, because if I had a full-blown management stack, I'd rather update qemu for better performance or security fixes or whatever than the rest of the whole stack. Also, if we need coordination between libvirt and qemu, that will delay release of whatever implementation we do, which is not horrible, but not desirable either. Therefore, it would be nice if the default choice would work with libvirt today, which only leaves format locking. Then there are users for whom format locking is not the right choice. They often do have a management layer, so they don't actually need the features provided by a locking mechanism in qemu (libvirt does it anyway), and I do think we can assume them willing to set some runtime options. Therefore, the default does not matter here, but we should implement flock() because once libvirt can cope with qemu invoking that by itself, it may offer them better protection. This is why I think implementing both format and protocol locking may be a good idea. I think we should enable format locking and disable flock() by default, but of course you should be able to override this choice at runtime. Thoughts? Max --voapm2OdT0XKL0JunbekknxC6h3kQeEQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWl6odAAoJEDuxQgLoOKyttUYH/2Q/Li2UbqZLH3AdkZSjN78B 1WZs3yRTbw8027ePZf6qg1TJXLtHksNhP/mkZERxP0ccm8kIJCpguxxm5Bme+OJe pwrDNwk48K+H+JuS8NYWFB5HTatHmfy5pd0ZYoj+2cPF8iCFte7+aUQ19uwlPbVd 4zGRrJBkyArLQ5z5HDuibiCkcc2CNP0X8+qojG9wm/k5sG96dlaIKWN1XcN6SkIa /Qt7FxNAtaRN/eO8xxJngRPZY3MxiaxcSolxOTW7OCxzLOHTqPq8Rm/W3u41xs6o UB+PC1/CaZy+eW9DmpBr0kzEEgAHwGk4gkSAkDak3T3BreUXaVII4fEKgMjhNzM= =yWHi -----END PGP SIGNATURE----- --voapm2OdT0XKL0JunbekknxC6h3kQeEQf--