From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0V81-0004DP-MS for qemu-devel@nongnu.org; Tue, 18 Apr 2017 11:33:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0V80-0003XJ-EV for qemu-devel@nongnu.org; Tue, 18 Apr 2017 11:33:17 -0400 Date: Tue, 18 Apr 2017 17:32:56 +0200 From: Kevin Wolf Message-ID: <20170418153256.GE9236@noname.redhat.com> References: <20170412091819.GB4955@noname.str.redhat.com> <20170418144725.GJ21261@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20170418144725.GJ21261@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] [Qemu-block] migrate -b problems List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-block@nongnu.org, dgilbert@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, quintela@redhat.com --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 18.04.2017 um 16:47 hat Stefan Hajnoczi geschrieben: > On Wed, Apr 12, 2017 at 11:18:19AM +0200, Kevin Wolf wrote: > > after getting assertion failure reports for block migration in the last > > minute, we just hacked around it by commenting out op blocker assertions > > for the 2.9 release, but now we need to see how to fix things properly. > > Luckily, get_maintainer.pl doesn't report me, but only you. :-) > >=20 > > The main problem I see with the block migration code (on the > > destination) is that it abuses the BlockBackend that belongs to the > > guest device to make its own writes to the image file. If the guest > > isn't allowed to write to the image (which it now isn't during incoming > > migration since it would conflict with the newer style of block > > migration using an NBD server), writing to this BlockBackend doesn't > > work any more. > >=20 > > So what should really happen is that incoming block migration creates > > its own BlockBackend for writing to the image. Now we don't want to do > > this anew for every incoming block, but ideally we'd just create all > > necessary BlockBackends upfront and then keep using them throughout the > > whole migration. Is there a way to get some setup/teardown callbacks > > at the start/end of the migration that could initialise and free such > > global data? >=20 > It can be done in the beginning of block_load() similar to > block_mig_state.bmds_list, which is created in init_blk_migration() at > save time. The difference is that block_load() is the counterpart for block_save_iterate(), not for init_blk_migration(). That is, it is called for each chunk of block migration data, which is interleaved with normal RAM migration chunks. So we can either create each BlockBackend the first time we need it in block_load(), or create BlockBackends for all existing device BBs and BDSes the first time block_load() is called. We still need some place to actually free the BlockBackends again when the migration completes. Dave suggested migration state notifiers, which looked like an option, but at least the existing migration states aren't enough, because the BlockBackends need to go away before blk_resume_after_migration() is called, but MIGRATION_STATUS_COMPLETED is set only afterwards. > We can also move the if (blk !=3D blk_prev) blk_invalidate_cache() code > out of the load loop. It should be done once when setting up > BlockBackends. Same problem as above, while saving has setup/cleanup callbacks, we only have the iterate callback for loading. > > The other problem with block migration is that is uses a BlockBackend > > name to identify which device is migrated. However, there can be images > > that are not attached to any BlockBackend, or if it is, the BlockBackend > > might be anonymous, so this doesn't work. I suppose changing the field > > to "device name if available, node-name otherwise" would solve this. >=20 > Yes, that sounds good and is backwards compatible. Kevin --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJY9jGoAAoJEH8JsnLIjy/Wo9AP/2sBxxpz0/DyE6iVBp4YYE0X 6Ul/gfVmwAiF0d8v8XJFf0VgvQuTTlhfKAa7gPNwvoGKggq0vNy286rYm9/scGK4 34/BQxqpNZLMu/x8t+ZTKoyzEy/tVkRTH+0OdlcLQAx7MDfQBH7HQjGr3OzTzHTL lNqwc05Z0zaaGp3uZwkvuQlzvqM3rn4X5SIcd+TGegxdAam1fqfkLynEAFPHn7Pv bYNBfQRs6y1ulpskz8dsgOsB4VLNCHxZcBNs4TtdrpMT8a042U4BHeejrcAoZLGt lm1jeJ0IM3sWyDiQFiUD0ZGVSboDAbSCtkIPX3D6iNw2bMZtVfuJSrrC4ZQjnYKX kYGaBy450o85qvg4kDi1LO2AacKdjFMLd6k/m9KCSXU36g5ZRd5MQ75+sw7bYUf6 NaRB3oZhkGTgfCSViI94TAPQmaL6nQZGw9xQoz4V0hqMlO7lIoqC8Il7R5omgjum XhwLeV8AEC/jWZLhOmmgDYGwKLFqZTLd8dJ5Fsie5sWjImOSw15Aytcw25R9muw1 6A4UgmsdeyfWZOEvWwYZnKWR1uGVUThHLkjcpZg3oN9svW3u47TnBxvXhppgffBF +7d3QuGouBPuL6qqvF4tLRGe5Q1YPpxqavbsBCGXVSdIVcXXlQh8xDYOy4b9YPBC QTqGad+2PBhmAK3Z0XdG =nvy9 -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi--