From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvOkm-0006wf-V6 for qemu-devel@nongnu.org; Mon, 01 Dec 2014 06:02:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvOkg-0001DK-QV for qemu-devel@nongnu.org; Mon, 01 Dec 2014 06:02:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvOkg-0001CK-IV for qemu-devel@nongnu.org; Mon, 01 Dec 2014 06:02:46 -0500 Date: Mon, 1 Dec 2014 11:02:43 +0000 From: Stefan Hajnoczi Message-ID: <20141201110243.GA4248@stefanha-thinkpad.redhat.com> References: <546A88DD.10006@redhat.com> <1416479664-3414-1-git-send-email-vsementsov@parallels.com> <546DC54A.2050701@parallels.com> <20141120113622.GB11224@stefanha-thinkpad.redhat.com> <546F139C.1050408@parallels.com> <20141121165512.GA32635@stefanha-thinkpad.redhat.com> <54787899.7070403@parallels.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <54787899.7070403@parallels.com> Subject: Re: [Qemu-devel] [PATCH v2] persistent dirty bitmap: add QDB file spec. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy Cc: famz@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, "Denis V. Lunev" --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 28, 2014 at 04:28:57PM +0300, Vladimir Sementsov-Ogievskiy wrot= e: > On 21.11.2014 19:55, Stefan Hajnoczi wrote: > >Active dirty bitmaps should migrate too. I'm thinking now that the > >appropriate thing is to add live migration of dirty bitmaps to QEMU > >(regardless of whether they are active or not). > I think, we should migrate named dirty bitmaps, which are not used now. So > if some external mechanism uses the bitmap (for example - backup) - we > actually can't migrate this process, because we will need to restore the > whole backup structure including a pointer to the bitmap, which is too ha= rd > and includes not only bitmap migration. > So, if named bitmap is enabled, but not used (only bdrv_aligned_pwritev > writes to it) it can be migrated. For this I see the following solutions: >=20 > 1) Just save all corresponding pieces of named bitmaps with every migrated > block. The block size is 1mb, so the overhead for migrating additionally a > bitmap with 64kb granularity would be 2b, and it would be 256b for bitmap > with 512b granularity. This approach needs additional fields in BlkMigBlo= ck, > for saving bitmaps pieces. block-migration.c is not used for all live migration. So it's important not to tie dirty bitmap migration to block-migration.c, at least there needs to be a way to skip actually copying disk contents in block-migration.c. (When there is shared storage that both source and destination hosts can access then block-migration.c is not used. Also, there is a newer non-shared storage migration mechanism that is used instead of block-migration.c which is not tied into the live migration data stream, so block-migration.c is optional.) > 2) Add DIRTY flag to migrated block flags, to distinguish blocks, which > became dirty while migrating. Save all the bitmaps separately, and also > update them on block_load, when we receive block with DIRTY flag on. Some > information will be lost, migrated dirty bitmaps may be "more dirty" then > original ones. This approach needs additional field "bool dirty" in > BlkMigBlock, and saving this flag in blk_send. >=20 > These solutions don't depend on "persistence" of dirty bitmaps or persist= ent > bitmap file format. That's an important characteristic since we probably want to migrate named dirty bitmaps, whether they are persistent or not. Stefan --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUfErTAAoJEJykq7OBq3PImBwH/12TMefRIK/+2Ji3PiB2Zfen e/Dx5ct3BuLS3YLZhFTZl//3VpfDx2Ut4cXDj/gQLQDpxn2LMatBoz5JZVmFbwoU KvkYgchJ8+umRM9LNm+LLHellxVO47DF7FSEOA2oSXVKCKtDgOP/AruuuKphj75+ 5UEkPjRJV2yIz1u15oeX32gqeEC1kYYQko2orjX9GGk2OA9yv+iXzpi8tEQMHTo8 3wnBBwuNe+9H9kb2rlmhHZzwnJGSBTSHDlPX80D62ThVrwH6jmg62FUghHFfRENy AD4ri/CgeiEuczl91CpDsdP9n6GQR+h03hhZlFe0itHcxDgBKDx4elVuWhqlX5s= =HG39 -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt--