From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrrUP-000108-Oe for qemu-devel@nongnu.org; Fri, 21 Nov 2014 11:55:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrrUJ-0000gQ-Ir for qemu-devel@nongnu.org; Fri, 21 Nov 2014 11:55:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrrUJ-0000gK-9u for qemu-devel@nongnu.org; Fri, 21 Nov 2014 11:55:15 -0500 Date: Fri, 21 Nov 2014 16:55:12 +0000 From: Stefan Hajnoczi Message-ID: <20141121165512.GA32635@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <546F139C.1050408@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, den@parallels.com --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 21, 2014 at 01:27:40PM +0300, Vladimir Sementsov-Ogievskiy wrote: > >There is a constraint if we want to get live migration for free: The > >bitmap contents must be accessible with bdrv_read() and > >bdrv_get_block_status() to skip zero regions. > Hm. I'm afraid, it still will not be free. If bitmap is active, it's actual > version is in memory. To migrate bitmap file like a disk image, we should > start syncing it with every write to corresponding disk, doubling number of > io. It would be possible to drive-mirror the persistent dirty bitmap and then flush it like all drives when the guest vCPUs are paused for migration. After thinking more about it though, this approach places more I/O into the critical guest downtime phase. In other words, slow disk I/O could lead to long guest downtimes while QEMU tries to write out the dirty bitmap. > Moreover, we have normal dirty bitmaps, which have no name/file, do we > migrate them? If, for example, the migration occurs when backup in progress? > Active bitmaps should be migrated in the same way for > persistent/named/normal bitmaps. I can't find in qemu source, is there > bitmap migration? bs->dirty_bitmaps is not migrated, in fact none of BlockDriverState is migrated. QEMU only migrates emulated device state (e.g. the hardware registers and associated state). It does not emulate host state that the guest cannot see like the dirty bitmap. > Or you are saying about migrating disabled bitmaps? Hm. We should sync > bitmap file on bitmap_disable. Disabled persistent bitmap is just a static > file ~30mb, we can easily migrate it without common procedure with cow or > something like this.. 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). Stefan --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUb25wAAoJEJykq7OBq3PIbegIAMYpTOimjlwCXY46MhJgvFcq AYoPrcRdwxaqqeakbBKh6KKCJ1tQ3FFWcSd0Bq3xqr0KCIiZ9mhFZI5ll2R3EGk3 gBztbZ2Q3Z5IVQnYnyw2QTu2FW9U9poP8yyv94St8CXQgxyPE8oE4tv4Swva80IJ wCkPaclb1qyBdSFk+jR4sE5HQOMKQOmrPNNDc1+bCmQH7YRgnz+F4nsgemUg7OeK 6uN6wfDlgxXTVQvxagnl+3u2Z7/aIgO2/k6UZhbZc/9sAEwtmIyKQu70OP+Cmnsi s9bOYrZacXYKy/0IxDrC2duSEO9UtPzosg+1zByqjfISyVO14F/mGyWaTiWIKhc= =yMez -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--