[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Juan Quintela]

"Michael S. Tsirkin" <address@hidden> wrote:
> On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
>> On 11/25/09 14:40, Michael S. Tsirkin wrote:
>>
>>>> We could add a DeviceState->savevm field and make that available as
>>>> property for devices which need to support multiple versions.  Then you
>>>> we can use the compat properties to switch back to the older format with
>>>> -M pc-0.10.
>>
>>> I'm confused sorry. Of course when you want to migrate to qemu 0.10
>>> you must have a compatible machine. And savevm format has nothing
>>> to do with it IMO, so MSI is orthogonal to this discussion.
>>> It just shows that it was smart not to save MSI state when
>>> MSI is not present (/me pats self on the back).
>>>
>>> In this thread we were discussing changes like pvclock bug,
>>> where we change savevm format without changing the machine,
>>> or almost without changing the machine.
>>
>> If 0.12 has this fixed (and thus a new version) and 0.11 hasn't, then  
>> you'll want -M pc-0.11 use the old (buggy) savevm version.  You have to  
>> stay bug compatible otherwise you can't migrate to the old buggy version  
>> because the old qemu can't handle the new format.
>>
>> Could be implemented via DeviceState->savevm as outlined above.
>>
>> cheers,
>>   Gerd
>
> There might be many reasons to use -M pc-0.11.  Migrating to old qemu is
> only one of them.  We should not force old savevm bugs on all users that
> use -M pc-0.11.  In partucular, I think with time (years) we might drop
> support for old savevm bugs, but I see no reason not to support old
> machines indefinitely.

You had to get both or drop both.  If you do a savevm change, machine is
not pc-0.11 anymore, it is pc-0.11.1  or whatever do you want to call
it.

Savevm format is tied to whatever devices version you are using, really.
It just happens that for some cases, you could move between one type of
machine and another.  But that is only some cases.  And IMHO, you don't
want to generate another set of infrastructure for that case.

You need to change saveformats when you change machine description.  I
think that everybody agrees here.  Now, there are times, when one
machine can save in other savevm formats (notice that I am not telling
how many cases are).  To be able to do this, you need yet another
infrastructure.

What people are telling here (me, gerd now) is that the cost/benefit of
adding  the new infrastructure for another use case is too high.  That
it is better to get this behaviour with new machine description types.

Obviously you disagree here.  Then we can stop discussing what cases are
doable one way and another, and go back to the "real discussion".

Does it makes sense to only have one mechanism to change savevm formats
(Machine description types) or should we have Machine descrition types
and another one when machines can save in different formats?

Again, it is a tradeoff between amount of infrastructure and
flexibility.  But the discussion that we are having at this moment is
this one.

Notice that I haven't told yet what are more probable, bugfixes that can
be changed at the savevm moment or changes that need to change at device
creation time.

Michael, do you agree that the discusion is to have two mechanisms vs
only one?  That way, we don't have to continue creating examples :)

Later, Juan.