From: Igor Redko <red...@virtuozzo.com>
To get this estimation we must divide pending_size by bandwidth
according to description of expected-downtime ("qmp-commands.hx:3246"):
"expected-downtime": only present while migration is active
total amount in ms for downtime that was calculated on
the last bitmap round (json-int)
Previous version was just wrong because dirty_bytes_rate and bandwidth
are measured in Bytes/ms, so dividing first by second we get some
dimensionless quantity.
As it said in description above this value is showed during active
migration phase and recalculated only after transferring all memory
and if this process took more than 1 sec. So maybe just nobody noticed
that bug.
Signed-off-by: Igor Redko <red...@virtuozzo.com>
Reviewed-by: Anna Melekhova <an...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Juan Quintela <quint...@redhat.com>
CC: Amit Shah <amit.s...@redhat.com>
---
migration/migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/migration.c b/migration/migration.c
index 662e77e..d55d545 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -994,7 +994,7 @@ static void *migration_thread(void *opaque)
/* if we haven't sent anything, we don't want to recalculate
10000 is a small enough number for our purposes */
if (s->dirty_bytes_rate && transferred_bytes > 10000) {
- s->expected_downtime = s->dirty_bytes_rate / bandwidth;
+ s->expected_downtime = pending_size / bandwidth;
}
qemu_file_reset_rate_limit(s->file);
--
2.1.4
