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