qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 10/11] tests/qtest/migration: Support more than one QEMU b


From: Juan Quintela
Subject: Re: [PATCH v3 10/11] tests/qtest/migration: Support more than one QEMU binary
Date: Wed, 18 Oct 2023 16:45:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux)

Fabiano Rosas <farosas@suse.de> wrote:
> Juan Quintela <quintela@redhat.com> writes:
>
>> Fabiano Rosas <farosas@suse.de> wrote:
>> D> 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:
>>> QTEST_QEMU_BINARY_SRC=../build-8.2.0/qemu-system-x86_64 \
>>> QTEST_QEMU_BINARY_DST=../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>
>>
>> The test works for me.  But I would really like to be able to specify
>> the machine type for which I have to test.  I.e. right now, we can test:
>>
>> qemu-8.2 <-> qemu-8.1
>>
>> and it is going to use q35-8.1
>>
>> But in the case that I want to test that two binaries with q35-8.0,
>> there is no way to setup that.
>
> Sorry, I didn't catch that you wanted to test versions other than the
> latest when you mentioned it the first time.
>
>> So basically what I need is
>>
>> QTEST_QEMU_MACHINE_TYPE var, and if that exist, just use that instead of
>> the value of "machine"
>>
>> What do you think?
>
> I don't see why not.
>
> I have to resend this series because I sent the wrong version by
> accident. I'll add the new var then.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]