Hi ,Vladimir sometimes ,post-copy mode is not the best choice. For instance, Supposing migrate process will take ten minutes,but network may be interruptted In this process . If it does happenthe , memory data of VM will be splitted into two parts, and will not be rollback.This is a bad situation
so migrate-start-postcopy will not be setted in conservative scenario. In this case, the migration with block dirty bitmap may not be finished. I think migration of block dirty bitmap should not dependent on post-copy or pre-copy mode. Best regards At 2022-09-10 18:18:04, "Vladimir Sementsov-Ogievskiy" <vsement...@yandex-team.ru> wrote: >On 9/10/22 09:35, liuhaiwei wrote: >> From: liuhaiwei <liuhai...@inspur.com> >> >> bug description as https://gitlab.com/qemu-project/qemu/-/issues/1203 >> Usually,we use the precopy or postcopy mode to migrate block dirty bitmap. >> but if block-dirty-bitmap size more than threshold size,we cannot entry the >> migration_completion in migration_iteration_run function >> To solve this problem, we can setting the pending size to a fake >> value(threshold-1 or 0) to tell migration_iteration_run function to entry >> the migration_completion,if pending size > threshold size >> > > >Actually, bitmaps migrate in postcopy. So, you should start postcopy for it to >work (qmp command migrate-start-postcopy). This command simply set the boolean >variable, so that in migration_iteration_run() we'll move to postcopy when >needed. So, you can start this command immediately after migrate command, or >even before it, but after setting the "dirty-bitmaps" capability. > >Fake pending is a wrong thing to do, it means that you will make downtime to >be larger than expected. > >-- >Best regards, >Vladimir
