From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCcYQ-0000EU-Sk for qemu-devel@nongnu.org; Thu, 01 Dec 2016 20:22:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCcYQ-0002uB-6D for qemu-devel@nongnu.org; Thu, 01 Dec 2016 20:22:22 -0500 References: <1477928314-11184-1-git-send-email-famz@redhat.com> <1477928314-11184-7-git-send-email-famz@redhat.com> From: Max Reitz Message-ID: Date: Fri, 2 Dec 2016 02:22:13 +0100 MIME-Version: 1.0 In-Reply-To: <1477928314-11184-7-git-send-email-famz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SkARFWWNTxkTRHrllKFCUTHTljs4SNPSM" Subject: Re: [Qemu-devel] [PATCH 06/14] block: Set "share-rw" flag for incoming migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , qemu-devel@nongnu.org Cc: "Daniel P. Berrange" , Kevin Wolf , qemu-block@nongnu.org, rjones@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SkARFWWNTxkTRHrllKFCUTHTljs4SNPSM From: Max Reitz To: Fam Zheng , qemu-devel@nongnu.org Cc: "Daniel P. Berrange" , Kevin Wolf , qemu-block@nongnu.org, rjones@redhat.com Message-ID: Subject: Re: [PATCH 06/14] block: Set "share-rw" flag for incoming migration References: <1477928314-11184-1-git-send-email-famz@redhat.com> <1477928314-11184-7-git-send-email-famz@redhat.com> In-Reply-To: <1477928314-11184-7-git-send-email-famz@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 31.10.2016 16:38, Fam Zheng wrote: > In this way the source side QEMU is writing to the image. We need to > open it, so share-rw is required. >=20 > Signed-off-by: Fam Zheng > --- > blockdev.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Should we make some effort to clear the flag once migration is done (i.e. via bdrv_reopen())? Also, should we set it everywhere where BDRV_O_INACTIVE is set (e.g. in postcopy migration, too)? Is it possible for these images to be opened R/W? If so, we have to make sure the source has also opened the image in shared mode, otherwise opening it will fail despite of BDRV_O_SHARE_RW. Max --SkARFWWNTxkTRHrllKFCUTHTljs4SNPSM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFGBAEBCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAlhAzMUSHG1yZWl0ekBy ZWRoYXQuY29tAAoJEPQH2wBh1c9AJ7IH/RhlUtbuWkOZQd4jCCQtLahZM9p4cIGC 6KRpkeVj/efXEx7AqqFdqG8BdlUSNDrgyBLrL7i8A7WkwfqAUxbBJ2xTwbjVU+ES 8JsWcfofZhCladifpFNfvUk5jq+IKUykYI2ZwTCPjd7cji7VuHESw25UynOb9maI 8+wNhaFKEK4MGqPj1limIsjr2UPGdlr+NwCCt+vfhxDdg/jUvYUI156c+k6rrb60 Qc35qNhD3wb1Y/f7SYDWAPLhbZ4Iqm3s1Afkm3r7Wwvynn9/OkBUpdROqDeqO1Xn sLM9nY893hvEQkHY0XkY4tGHC2Tb/UA34Un9yhK+dWWbru1shAopYlE= =mthX -----END PGP SIGNATURE----- --SkARFWWNTxkTRHrllKFCUTHTljs4SNPSM--