From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxGDJ-0001vp-V3 for qemu-devel@nongnu.org; Tue, 26 May 2015 10:52:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxGDF-0003eA-4g for qemu-devel@nongnu.org; Tue, 26 May 2015 10:52:17 -0400 Received: from relay.parallels.com ([195.214.232.42]:48769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxGDE-0003dj-RQ for qemu-devel@nongnu.org; Tue, 26 May 2015 10:52:13 -0400 Message-ID: <55648887.7080804@odin.com> Date: Tue, 26 May 2015 17:51:51 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <1431531007-10269-1-git-send-email-vsementsov@parallels.com> <555DE2D7.2020200@parallels.com> <555DE431.60703@openvz.org> <555E0B5D.5060302@redhat.com> <556487BF.2000809@openvz.org> In-Reply-To: <556487BF.2000809@openvz.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/12] Dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , dgilbert@redhat.com Cc: kwolf@redhat.com, peter.maydell@linaro.org, quintela@redhat.com, qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , stefanha@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com On 26/05/15 17:48, Denis V. Lunev wrote: > On 21/05/15 19:44, John Snow wrote: >> >> On 05/21/2015 09:57 AM, Denis V. Lunev wrote: >>> On 21/05/15 16:51, Vladimir Sementsov-Ogievskiy wrote: >>>> Hi all. >>>> >>>> Hmm. There is an interesting suggestion from Denis Lunev (in CC) about >>>> how to drop meta bitmaps and make things easer. >>>> >>>> method: >>>> >>>>> start migration >>>> disk and memory are migrated, but not dirty bitmaps. >>>>> stop vm >>>> create all necessary bitmaps in destination vm (empty, but with same >>>> names and granularities and enabled flag) >>>>> start destination vm >>>> empty bitmaps are tracking now >>>>> start migrating dirty bitmaps. merge them to corresponding bitmaps >>>> in destination >>>> while bitmaps are migrating, they should be in some kind of >>>> 'inconsistent' state. >>>> so, we can't start backup or other migration while bitmaps are >>>> migrating, but vm is already _running_ on destination. >>>> >>>> what do you think about it? >>>> >>> the description is a bit incorrect >>> >>> - start migration process, perform memory and disk migration >>> as usual. VM is still executed at source >>> - start VM on target. VM on source should be on pause as usual, >>> do not finish migration process. Running VM on target "writes" >>> normally setting dirty bits as usual >>> - copy active dirty bitmaps from source to target. This is safe >>> as VM on source is not running >>> - "OR" copied bitmaps with ones running on target >>> - finish migration process (stop source VM). >>> >>> Downtime will not be increased due to dirty bitmaps with this >>> approach, migration process is very simple - plain data copy. >>> >>> Regards, >>> Den >>> >> I was actually just discussing the live migration approach a little bit >> ago with Stefan, trying to decide on the "right" packet format (The only >> two patches I haven't ACKed yet are ones in which we need to choose a >> send size) and we decided that 1KiB chunk sends would be appropriate for >> live migration. >> >> I think I'm okay with that method, but obviously this approach outlined >> here would also work very well and would avoid meta bitmaps, chunk >> sizes, migration tuning, convergence questions, etc etc etc. >> >> You'd need to add a new status to the bitmap on the target (maybe >> "INCOMPLETE" or "MIGRATING") that prevents it from being used for a >> backup operation without preventing it from recording new writes. >> >> My only concern is how easy it will be to work this into the migration >> workflow. >> >> It would require some sort of "post-migration" ternary phase, I suppose, >> for devices/data that can be transferred after the VM starts -- and I >> suspect we'll be the only use of that phase for now. >> >> David, what are your thoughts, here? Would you prefer Vladimir and I >> push forward on the live migration approach, or add a new post-hoc >> phase? This approach might be simpler on the block layer, but I would be >> rather upset if he scrapped his entire series for the second time for >> another approach that also didn't get accepted. >> >> --js > > hmmm.... It looks like we should proceed with this to fit 2.4 dates. > There is not much interest at the moment. I think that we could > implement this later in 2.5 etc... > > Regards, > Den oops. I have written something strange. Anyway, I think that for now we should proceed with this patchset to fit QEMU 2.4 dates. The implementation with additional stage (my proposal) could be added later, f.e. in 2.5 as I do not see much interest from migration gurus. In this case the review will take a ... lot of time. Regards, Den