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

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>
> 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.

So Pierre/Liran, what do you think about Jan's series?

Regards,

Anthony Liguori