[Qemu-devel] Re: new->old version migration

[Alex Williamson <alex.williamson@redhat.com>]

On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> New thread stated intentionally, the original patch is Message-ID:
> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
> 
> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> > Add a compat property for older machine types.  When this is used (via
> > -M pc-0.13, for example), the new flow control mechanisms will not be
> > used.  This is done to keep migration from a machine started with older
> > type on a pc-0.14+ qemu to an older machine working.
> > 
> > The property is named 'flow_control' and defaults to on.
> > 
> > Reported-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> 
> So, I think there are two things that need to be agreed on:
> 
> - Can we commit to support migration from new qemu version to an old one?
>   We haven't in the past but downstreams do want this,
>   so it makes sense to have the infrastructure upstream.

I think lack of testing is the primary thing preventing this.  We can
catch things like this in code review, but it's hard to commit to
support it if we can't reliably catch problems.  This one, we did catch,
and I think it's useful to put Amit's fix upstream, even if other
devices end up having issues.

> - The infrastructure/command line option for such support.
>   We have the -M flags to describe the machine that
>   we are running, but that abstracts away guest-visible machine,
>   which the migration format is not.
>   Also, same qemu could migrate to any older version.
>   So I think we would have to add a flag (call it -V for now)
>   to savevm/migrate commands to specify the format to be used.
>   Naturally some machines would be incompatible with
>   specific -V values, that's nothing new.

This seems unnecessarily complicated.  It makes sense to me that we
should track both the guest visible machine and the migration data
format with the same option.  In fact, I can't think of a good reason
for these ever being different and how we'd support it if they were.
There's plenty wrong with the migration data format, but that's a longer
term discussion, and I think this is appropriate given what we have
today.

Alex