qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.



  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).