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