Re: [PATCH v4 10/12] tests/qtest/migration: Support more than one QEMU binary

[Juan Quintela]

Thomas Huth <thuth@redhat.com> wrote:
> 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 <quintela@redhat.com>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>>   tests/qtest/migration-test.c | 28 ++++++++++++++++++++++++----
>>   1 file changed, 24 insertions(+), 4 deletions(-)
>
> Reviewed-by: Thomas Huth <thuth@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.

My idea would be to modify the container to create two trees:
- last released version
- upstream tip

And just use that two binaries with the upstream one handling this.

Later, Juan.