From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBTmD-00077D-VK for qemu-devel@nongnu.org; Tue, 22 Dec 2015 15:43:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBTmC-0004CO-TP for qemu-devel@nongnu.org; Tue, 22 Dec 2015 15:43:21 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <1450802786-20893-6-git-send-email-kwolf@redhat.com> From: Eric Blake Message-ID: <5679B5DE.5070205@redhat.com> Date: Tue, 22 Dec 2015 13:43:10 -0700 MIME-Version: 1.0 In-Reply-To: <1450802786-20893-6-git-send-email-kwolf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QEWDcauk1UJ1Bg9XL72MfR8hll8TKro6l" Subject: Re: [Qemu-devel] [PATCH 05/10] block: Inactivate BDS when migration completes 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QEWDcauk1UJ1Bg9XL72MfR8hll8TKro6l Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/22/2015 09:46 AM, Kevin Wolf wrote: > So far, live migration with shared storage meant that the image is in a= > not-really-ready don't-touch-me state on the destination while the > source is still actively using it, but after completing the migration, > the image was fully opened on both sides. This is bad. >=20 > This patch adds a block driver callback to inactivate images on the > source before completing the migration. Inactivation means that it goes= > to a state as if it was just live migrated to the qemu instance on the > source (i.e. BDRV_O_INCOMING is set). You're then supposed to continue > either on the source or on the destination, which takes ownership of th= e > image. >=20 > A typical migration looks like this now with respect to disk images: >=20 > 1. Destination qemu is started, the image is opened with > BDRV_O_INCOMING. The image is fully opened on the source. >=20 > 2. Migration is about to complete. The source flushes the image and > inactivates it. Now both sides have the image opened with > BDRV_O_INCOMING and are expecting the other side to still modify it.= The name BDRV_O_INCOMING now doesn't quite match semantics on the source, but I don't have any better suggestions. BDRV_O_LIMITED_USE? BDRV_O_HANDOFF? At any rate, I fully agree with your logic of locking things down on the source to mark that the destination is about to take over write access to the file. >=20 > 3. One side (the destination on success) continues and calls > bdrv_invalidate_all() in order to take ownership of the image again.= > This removes BDRV_O_INCOMING on the resuming side; the flag remains > set on the other side. >=20 > This ensures that the same image isn't written to by both instances > (unless both are resumed, but then you get what you deserve). This is > important because .bdrv_close for non-BDRV_O_INCOMING images could writ= e > to the image file, which is definitely forbidden while another host is > using the image. And indeed, this is a prereq to your patch that modifies the file on close to clear the new 'open-for-writing' flag :) >=20 > Signed-off-by: Kevin Wolf > --- > block.c | 34 ++++++++++++++++++++++++++++++++++ > include/block/block.h | 1 + > include/block/block_int.h | 1 + > migration/migration.c | 7 +++++++ > qmp.c | 12 ++++++++++++ > 5 files changed, 55 insertions(+) >=20 > @@ -1536,6 +1540,9 @@ static void migration_completion(MigrationState *= s, int current_active_state, > if (!ret) { > ret =3D vm_stop_force_state(RUN_STATE_FINISH_MIGRATE); > if (ret >=3D 0) { > + ret =3D bdrv_inactivate_all(); > + } > + if (ret >=3D 0) { > qemu_file_set_rate_limit(s->file, INT64_MAX); Isn't the point of the rate limit change to allow any pending operations to flush without artificial slow limits? Will inactivating the device be too slow if rate limits are still slow? But offhand, I don't have any strong proof that a different order is required, so yours makes sense to me. You may want a second opinion, but I'm okay if you add: Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --QEWDcauk1UJ1Bg9XL72MfR8hll8TKro6l 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWebXeAAoJEKeha0olJ0NqL50H/1C1/jcHXJZGP8jlueEwE6Np WWcWZOfgIoAoYkUDkGxxwnJeDOJFtGa76Z7npya3hwdTHPZBdB2IIvvOMPk9g3Os Lc/rponw57l/jLx/W6jG62qhxANtXlnZnh8SUQkuGUaY3mbejb1atEFb2iCYEMy6 dSeCvz4hH1kzPrRwpZkGMLnd1/Cy0CqPgxexp5bVPgt3NxLPjfoo/GrtXlsZs5d+ /vqsSetmN3DHqsbYfZH+08N5zCxjADQfRxAq4mfIK3AW4k7cWxiBFgcO0hAr6UaA Z3EVqsUcoLBdmvXeX8Rn+4ZXaCmjadLfj0obkESt03aNpAD3LscmtFHp6U5Up5M= =RJJ6 -----END PGP SIGNATURE----- --QEWDcauk1UJ1Bg9XL72MfR8hll8TKro6l--