From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuLcg-0004oR-MD for qemu-devel@nongnu.org; Fri, 28 Nov 2014 08:30:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuLca-0005Ev-Ho for qemu-devel@nongnu.org; Fri, 28 Nov 2014 08:30:10 -0500 Received: from relay.parallels.com ([195.214.232.42]:44636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuLca-0004yT-A4 for qemu-devel@nongnu.org; Fri, 28 Nov 2014 08:30:04 -0500 Message-ID: <54787899.7070403@parallels.com> Date: Fri, 28 Nov 2014 16:28:57 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 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> In-Reply-To: <20141121165512.GA32635@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: famz@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, "Denis V. Lunev" 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 hard 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: 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 BlkMigBlock, for saving bitmaps pieces. 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. These solutions don't depend on "persistence" of dirty bitmaps or persistent bitmap file format. Best regards, Vladimir On 21.11.2014 19:55, Stefan Hajnoczi wrote: > 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