Re: [Qemu-devel] [PATCH v5 00/12] Dirty bitmaps migration

[John Snow <jsnow@redhat.com>]

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