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

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

On Mon, Feb 07, 2011 at 02:56:50PM -0600, Anthony Liguori wrote:
> On 02/07/2011 01:53 PM, Michael S. Tsirkin wrote:
> >On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
> >>On 02/07/2011 10:07 AM, 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.
> >>Only within a stable release series and only when it's possible
> >>without sacrificing integrity.  I know some downstreams disagree
> >>with this but I don't think this is a business we want to get into.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>>- 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.
> >>>
> >>>Pls comment.
> >OK, assuming we want this, let's talk about implementation.
> >I think that spreading custom flags all over the code like
> >this patch does would be pretty bad.
> >
> >What I'd like to see is a way to
> >- map stable versions (e.g. machine type if we are going
> >   to tie to that)  to savevm format using
> >   some kind of table
> >- for save callbacks to be able to figure out what
> >   version to use
> 
> Why doesn't subsections already solve this problem?
> 
> Regards,
> 
> Anthony Liguori


How does it? We need to know we are saving in 0.13
format and skip the new subsection, otherwise
0.13 will see a subsection it does not recognize
and exit.

We also need API to add subsections without vmstate,
because virtio serial wasn't yet converted.

-- 
MST