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

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

On Tue, Nov 24, 2009 at 01:35:35PM +0000, Paul Brook wrote:
> > But it's easy to support migration to old qemu just
> > by discarding the INTx state, and this is not
> > at all harder, or worse, than migrating from old qemu
> > to new one.
> 
> Do we really care about migrating to older versions?
> 
> Migrating to a new version (backward compatibility) I see the use, it allows 
> people to do upgrades with minimal downtime. I have my reservations about how 
> feasible this is long-term, but within a release series it's not too bad.
> 
> However is migrating to an old version (forward compatibility) really a 
> worthwhile thing to support?

migrating to old version does not have to require forward compatibility IMO.
wikipedia says
"Forward compatibility or upward compatibility (sometimes confused with
 extensibility) is the ability of a system to gracefully accept input
 intended for later versions of itself. "

Supporting an explicit option to migrate to old versions would be enough.

> It sounds like the sort of thing that we're never 
> really going to test properly, so will probably fail a good proportion of the 
> time anyway.

Why is it harder to test than old->new migration?
If you have a migration test, just run it both ways.


> Reading in old state files is a whole lot easier (to write 
> maintain, and stay sane) than producing state that is bug-compatible with 
> previous versions.

It seems to me that old->new and new->old migrations are
of about the same level of difficulty.
Supporting one of these but not the other is of course
easier than supporting both, but I don't see where
"a whole lot" comes from.

> This feels something where the best answer all round is "Don't do that".
> 
> Paul
>