Post-copy migration of dirty-bitmaps doesn't mean post-copy migration of RAM.
To turn on post-copy migration of RAM, you should enable postcopy-ram
capability. If you don't enable it, RAM is migrated in pre-copy (i.e. before
starting VM on target).
migrate-start-postcopy command doesn't enable postcopy-ram capability
automatically, so don't be afraid of it.
On 9/15/22 04:28, liuhaiwei9699 wrote:
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
If you don't enable postcopy-ram capability, memory data is already migrated
_before_ starting VM on destination. So, the only thing that we may lose in
worst case is dirty bitmap itself, not RAM.
so migrate-start-postcopy will not be setted in conservative scenario. In this
case, the migration with block dirty bitmap may not be finished.
Again, migrate-start-postcopy command don't enable postcopy of RAM. It only
allow to enter generic postcopy mode. If dirty-bitmaps capability is enabled
and postcopy-ram is not, the only thing that can be migrated in postcopy is
dirty bitmap.
I think migration of block dirty bitmap should not dependent on post-copy or
pre-copy mode.
But dirty bitmaps migration is realized as postcopy in Qemu.
We can't migrate bitmaps during downtime in general, as bitmaps may be large
and connection slow (your case). So, we have to migrate them either in pre-copy
or in post-copy mode. Historically, the second method was chosen.
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
--
Best regards,
Vladimir
