From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxaj-0006AQ-B3 for qemu-devel@nongnu.org; Tue, 13 Jan 2015 04:16:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAxad-0001AL-3S for qemu-devel@nongnu.org; Tue, 13 Jan 2015 04:16:49 -0500 Received: from mx2.parallels.com ([199.115.105.18]:33131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxac-0001AD-UD for qemu-devel@nongnu.org; Tue, 13 Jan 2015 04:16:43 -0500 Message-ID: <54B4E270.7090302@parallels.com> Date: Tue, 13 Jan 2015 12:16:32 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1418307457-25996-1-git-send-email-vsementsov@parallels.com> <1418307457-25996-10-git-send-email-vsementsov@parallels.com> <54B3FACA.7060800@redhat.com> <54B404D9.6060203@redhat.com> <54B41BE7.1080909@redhat.com> In-Reply-To: <54B41BE7.1080909@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , John Snow , qemu-devel@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, stefanha@redhat.com On 12.01.2015 17:42, Paolo Bonzini wrote: > On 12/01/2015 15:20, Vladimir Sementsov-Ogievskiy wrote: >> On 09.01.2015 01:36, Paolo Bonzini wrote: >>> The bitmaps are transmitted many times in their entirety, but only the >>> last copy actually means something. The others are lost. This means >>> you should use the non-live interface (register_savevm). This will >>> simplify the code a lot. >> But what if the dirty bitmap is really big? >> >> For example, for 5 Pb drive the bitmap with granularity 65536 will be of >> 2 Gb size. So, shouldn't it be migrated iteratively for live migration? > But your code is not attempting to do that. It is not attempting to > track the dirtiness of the dirty bitmap, so to speak. > > For such a huge storage, in any case, I suspect the solution is to not > use QEMU's live operations and, instead, operate at the storage level. > > Paolo On 12.01.2015 22:09, Paolo Bonzini wrote: > On 12/01/2015 18:31, John Snow wrote: >>> How do you track which parts of the disk have been acted upon (e.g. >>> mirrored in the case of the drive-mirror command), so that they have >>> become 0? >> Hm... so your question here is, "What happens if the named bitmap you >> are transferring gets reset to 0 during migration? Will anybody track >> this change?" >> >> As far as I know, the only "consumer" of _named_ BdrvDirtyBitmaps is >> block/backup.c, and we do not support it for mirror (yet?) > Right. > >> So can a block-backup job be running WHILE we migrate? > I think so. > > Paolo There is no dirty bitmap for dirty bitmap in my solution, actually block migration dirty bitmap is used for this. It provides tracking of setting bitmap bits to 1 (when corresponding blocks are written), and if the bitmap changes only is this way (no other block-jobs are working with the migrated bitmap) - then the bitmap will be migrated iteratively as it is. Such approach doesn't provide tracking of resetting the bitmap to 0, and such changes are not migrated. So if the bitmap is in use by any block-job, it may have additional set bits after migration. If we want to migrate more precisely we need separate dirty bitmap for every migrated bitmap. And tracking of this dirty-dirty bitmap should be injected into BdrvDirtyBitmap interface. But do we really need precise migration of the bitmap being in use by some block-job (backup for example)? In this case we should "migrate" the backup process to, migrate working block-job.. Is it possible and is it planned to be implemented? Best regards, Vladimir