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

[Zhang Haoyu]

On 2015-01-14 17:07:08, Paolo Bonzini wrote:
> 
> 
> 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.
> >>
drive_mirror job is done in main-thread,
then how to accept the qmp_migrate request while drive_mirror is performing?
If need to wait for the completion of drive_mirror,
how to implement the parallelization between block and ram migration?

Thanks,
Zhang Haoyu
> > 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