Re: [Qemu-devel] [PATCH 00/23] block migration: Fixes, cleanups and speedups

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> This series is a larger rework of the block migration support qemu
>> recently gained. Besides lots of code refactorings the major changes
>> are:
>>  - Faster restore due to larger block sizes (even if the target disk is
>>    unallocated)
>>  - Off-by-one fixes in the block dirty tracking code
>>  - Allow for multiple migrations (after cancellation or if migrating
>>    into a backup image)
>>  - Proper error handling
>>  - Progress reporting fixes: report to monitor instead of stdout, report
>>    sum of multiple disks
>>  - Report disk migration progress via 'info migrate'
>>  - Progress report during restore
>>
>> One patch is directly taken from Pierre Riteau queue [1] who happend to
>> work on the some topic the last days, two more are derived from his
>> commits.
>>
>> These patches make block migration usable for us. Still, there are two
>> more major improvements on my wish/todo list:
>>  - Respect specified maximum migration downtime (will require tracking
>>    of the number of dirty blocks + some coordination with ram migration)
>>  - Do not transfere unallocated disk space (also for raw images, ie. add
>>    bdrv_is_allocated support for the latter)
>>
>> In an off-list chat, Liran additionally brought up the topic that RAM
>> migration should not start too early so that we avoid re-transmitting
>> dirty pages over and over again while the disk image is slowly beamed
>> over.

Putting "slightly" more load on the guest while trying to migrate, this
issue became a very visible one here. We definitely need some ordering
between block and ram migration, but I'm not sure how to achieve this best.

>>
>> I hope we can join our efforts to resolve the open topics quickly, the
>> critical ones ideally before the merge window closes.
>>   
> 
> That really needs to happen no later than the end of this week.

Most critical is surely the vmstate format. From my current POV, none of
the open issues should force us to change the format.

So when all goes wrong, we should even be able to fix remaining issues
of this brand new feature inside the stable series. Still, the earlier
we resolve the urging ones (migration order is now my favorite), the better.

> 
> So Pierre/Liran, what do you think about Jan's series?
> 
> Regards,
> 
> Anthony Liguori

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]