From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy4qn-0005qC-6H for qemu-devel@nongnu.org; Thu, 28 May 2015 16:56:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yy4qj-0000fs-59 for qemu-devel@nongnu.org; Thu, 28 May 2015 16:56:25 -0400 Received: from mx2.parallels.com ([199.115.105.18]:37579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy4qi-0000fa-Rk for qemu-devel@nongnu.org; Thu, 28 May 2015 16:56:21 -0400 Message-ID: <556780E8.6000700@odin.com> Date: Thu, 28 May 2015 23:56:08 +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> <55648887.7080804@odin.com> <55677603.8040506@redhat.com> In-Reply-To: <55677603.8040506@redhat.com> 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 28/05/15 23:09, John Snow wrote: > > On 05/26/2015 10:51 AM, Denis V. Lunev wrote: >> 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 >> > That sounds good to me. I think this solution is workable for 2.4, and > we can begin working on a post-migration phase for the future to help > simplify our cases a lot. > > I have been out sick much of this week, so apologies in my lack of > fervor getting this series upstream recently. > > --js no prob :)