From: Juan Quintela <quintela@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, "Leonardo Bras" <leobras@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Avihai Horon" <avihaih@nvidia.com>,
"Thomas Huth" <thuth@redhat.com>,
"Lukas Straub" <lukasstraub2@web.de>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH v2] migration: Add documentation for backwards compatiblity
Date: Thu, 11 May 2023 14:00:27 +0200 [thread overview]
Message-ID: <87o7mr3wo4.fsf@secure.mitica> (raw)
In-Reply-To: <2912b2c8-41c2-4a9d-64ac-b3a05e66028f@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Thu, 11 May 2023 13:23:12 +0300")
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> wrote:
> On 11.05.23 11:27, Juan Quintela wrote:
>> State what are the requeriments to get migration working between qemu
>> versions. And once there explain how one is supposed to implement a
>> new feature/default value and not break migration.
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>
> In general looks good to me:
>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Thanks.
>> ---
>> [v2]
>> - Add all danp fixes
>> [v1]
>> I will really appreciate reviews:
>> - I don't speak natively .rst format, so let me what I have done
>> wrong.
>> - English is not my native language either (no points if had guessed
>> that).
>
> Same for me. Sometimes your wording seems awkward to me, but I don't
> risk to propose my awkward replacement)
happens to me all the time O:-)
>> +When we do migration, we have to qemu process: the source and the
>
> two qemu processes
Done. Already reported by daniel.
> (also probably we should say QEMU everywhere)
Done.
>> +target. There are two cases, they are the same version or they are a
>> +different version. The easy case is when they are the same version.
>> +The difficult one is when they are different versions.
>> +
>> +There are two things that are different, but they have very similar
>> +names and sometimes get confused:
>> +- qemu version
>> +- machine version
>> +
>> +Let's start with a practical example, we start with:
>> +
>> +- qemu-system-x86_64 (v5.2), from now on qemu-5.2.
>> +- qemu-system-x86_64 (v5.1), from now on qemu-5.1.
>> +
>> +Related to this are the "latest" machine types defined on each of
>> +them:
>> +
>> +- pc-q35-5.2 (newer one in qemu-5.2) from now on pc-5.2
>> +- pc-q35-5.1 (newer one qemu-5.1) from now on pc-5.1
>
> one in qemu-5.1
done.
>> +
>> +First of all, migration is only supposed to work if you use the same
>> +machine type in both source and destination. The qemu hardware
>> +configuration needs to be the same also on source and destination.
>> +Most aspects of the backend configuration can be changed at will,
>> +except for a few cases where the backend features influence frontend
>> +device feature exposure. But that is not relevant for this section.
>> +
>> +I am going to list the number of combinations that we can have. Let's
>> +start with the trivial ones, qemu is the same on source and
>> +destination:
>> +
>> +1 - qemu-5.2 -M pc-5.2 -> migrates to -> qemu-5.2 -M pc-5.2
>> +
>> + This is the latest qemu with the latest machine type.
>> + This have to work, and if it don't work it is a bug.
>
> doesn't
done.
Search for all don't and replace lots of them.
>> +
>> +2 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
>> +
>> + Exactly the same case than the previous one, but for 5.1.
>> + Nothing to see here either.
>> +
>> +This are the easiest ones, we will not talk more about them in this
>> +section.
>> +
>> +Now we start with the more interesting cases. Let start with the
>> +same qemu but not the same machine type.
>
> sounds like "different machine type on source and target" for me..
>
> Maybe, "not latest machine type" ?
Now we start with the more interesting cases. Let start with a the
same QEMU process and a different QEMU version machine type.
Better?
Thanks, Juan.
next prev parent reply other threads:[~2023-05-11 12:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 8:27 [PATCH v2] migration: Add documentation for backwards compatiblity Juan Quintela
2023-05-11 10:23 ` Vladimir Sementsov-Ogievskiy
2023-05-11 12:00 ` Juan Quintela [this message]
2023-05-11 14:16 ` Vladimir Sementsov-Ogievskiy
2023-05-11 15:48 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7mr3wo4.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=berrange@redhat.com \
--cc=leobras@redhat.com \
--cc=lukasstraub2@web.de \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vsementsov@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).