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
