Thomas Huth <th...@redhat.com> writes: > On 18/10/2023 21.27, Fabiano Rosas wrote: >> We have strict rules around migration compatibility between different >> QEMU versions but no test to validate the migration state between >> different binaries. >> >> Add infrastructure to allow running the migration tests with two >> different QEMU binaries as migration source and destination. >> >> The code now recognizes two new environment variables >> QTEST_QEMU_BINARY_SRC and QTEST_QEMU_BINARY_DST. In the absence of >> either of them, the test will use the QTEST_QEMU_BINARY variable. If >> both are missing then the tests are run with single binary as >> previously. >> >> The machine type is selected automatically as the latest machine type >> version that works with both binaries. >> >> Usage (only one of SRC|DST is allowed): >> >> QTEST_QEMU_BINARY_SRC=../build-8.2.0/qemu-system-x86_64 \ >> QTEST_QEMU_BINARY=../build-8.1.0/qemu-system-x86_64 \ >> ./tests/qtest/migration-test >> >> Reviewed-by: Juan Quintela <quint...@redhat.com> >> Signed-off-by: Fabiano Rosas <faro...@suse.de> >> --- >> tests/qtest/migration-test.c | 28 ++++++++++++++++++++++++---- >> 1 file changed, 24 insertions(+), 4 deletions(-) > > Reviewed-by: Thomas Huth <th...@redhat.com> > > I wonder whether we could test this in the gitlab-CI, too, e.g. by using a > Debian container and installing the qemu-system-x86_64 from the Debian > distro there (since this should be close enough to an older version of an > upstream release), then run the test with that version from Debian and the > one that has just been compiled from the master branch? Anyway, just an > idea, this can certainly be done later.
Yes, something like this is the goal. It's not in this series because my docker-fu is a bit rusty, so I didn't want to delay the qtest part. I think taking a built-from-tree QEMU would be better than a distro-shipped one. I also think that we should have this disabled in CI, due to the issues I described in the other thread. And possibly enable it with fewer migration-test tests. I don't see the need to run *all* of the migration-tests in this "compat testing" scheme.
