diff options
| author | Daniel P. Berrangé <berrange@redhat.com> | 2023-06-01 17:13:47 +0100 |
|---|---|---|
| committer | Thomas Huth <thuth@redhat.com> | 2023-07-10 15:34:57 +0200 |
| commit | e02f56e3dee8dffc194e74275439f1975552da78 (patch) | |
| tree | fa3e2b48b5e779eb621a66c1af7175f9ff9e3084 /roms | |
| parent | cb2d7e63d19794c5344d438d943a8680d6756bdc (diff) | |
| download | qemu-e02f56e3dee8dffc194e74275439f1975552da78.zip qemu-e02f56e3dee8dffc194e74275439f1975552da78.tar.gz qemu-e02f56e3dee8dffc194e74275439f1975552da78.tar.bz2 | |
tests/qtest: massively speed up migration-test
The migration test cases that actually exercise live migration want to
ensure there is a minimum of two iterations of pre-copy, in order to
exercise the dirty tracking code.
Historically we've queried the migration status, looking for the
'dirty-sync-count' value to increment to track iterations. This was
not entirely reliable because often all the data would get transferred
quickly enough that the migration would finish before we wanted it
to. So we massively dropped the bandwidth and max downtime to
guarantee non-convergance. This had the unfortunate side effect
that every migration took at least 30 seconds to run (100 MB of
dirty pages / 3 MB/sec).
This optimization takes a different approach to ensuring that a
mimimum of two iterations. Rather than waiting for dirty-sync-count
to increment, directly look for an indication that the source VM
has dirtied RAM that has already been transferred.
On the source VM a magic marker is written just after the 3 MB
offset. The destination VM is now montiored to detect when the
magic marker is transferred. This gives a guarantee that the
first 3 MB of memory have been transferred. Now the source VM
memory is monitored at exactly the 3MB offset until we observe
a flip in its value. This gives us a guaranteed that the guest
workload has dirtied a byte that has already been transferred.
Since we're looking at a place that is only 3 MB from the start
of memory, with the 3 MB/sec bandwidth, this test should complete
in 1 second, instead of 30 seconds.
Once we've proved there is some dirty memory, migration can be
set back to full speed for the remainder of the 1st iteration,
and the entire of the second iteration at which point migration
should be complete.
On a test machine this further reduces the migration test time
from 8 minutes to 1 minute 40.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20230601161347.1803440-11-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'roms')
0 files changed, 0 insertions, 0 deletions