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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 25, 2009 at 03:53:40PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> 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.

Well, no. machine is whatever you boot into.
If it looks the same when you first boot into it,
it is the same machine.

> Savevm format is tied to whatever devices version you are using, really.

Yes. But not the other way around.
devices are not tied to savevm format.


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

No, this is *not* what me and others are telling you.
What people are saying is that you often have many
savevm formats for the same machine.
This is the issue we are trying to address.


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

I do not disagree. But the argument you are making for me
above is not the one I am making at all.

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

Looks like we are talking about different things.

-- 
MST