Re: [Qemu-devel] question about live migration with storage

[Paolo Bonzini <pbonzini@redhat.com>]

On 14/01/2015 08:58, Zhang Haoyu wrote:
>> 2) Finer-grain control the parameters of block migration (dirty bitmap
>> granularity).
>>
>> 3) Block and RAM migration do not share the same socket and thus can
>> more easily be parallelized.
>>
> But, because of the parallelization, how to calculate the progress?

You can use "query-block-jobs".

> BTW, the traditional iterative mechanism is buggy-implemented?
> e.g., some bugs which are very difficult to fixed, or something?

There are no bugs that corrupt data. It's simply less flexible.

Regarding parallelization, the problems happen especially if you disable
migration bandwidth limits.  Then you'll see large chunks of RAM and
large chunks of block device data being sent.  This is a problem for
convergence in some workloads. Instead, with NBD-based storage migration
everything happens in parallel, and TCP makes sure that bandwidth is
split between the sockets.

If you have a migration bandwidth limit, NBD-based storage migration
will use a separate bandwidth limit for each disk and for RAM. Thus
network usage is less predictable than with block-migration.c.  On the
other hand, storage migration uses a lot of network so it's usually more
likely that you do not have migration bandwidth limits.

Paolo

> Thanks,
> Zhang Haoyu
>> Note that 1-2 are not yet supported by libvirt as far as I remember.
>>
>> Paolo
> 
> 
>