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

[Anthony Liguori]

On 02/07/2011 10:51 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote:
>    
> > On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> >      
> > > New thread stated intentionally, the original patch is Message-ID:
> > > <address@hidden>
> > >
> > > 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<address@hidden>
> > > > Signed-off-by: Amit Shah<address@hidden>
> > > >          
> > > 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.
> >      
> It's not just testing.  Look at the specific example. The requirement
> for new->old migration makes us keep broken code without flow control
> around.  This will only increase with time and the mess here
> is not limited to vmstate, unlike the old->new format which
> generally makes us do conversion at load time, so it's contained.
>    

I haven't looked closely at the specific example but subsections allow 
us to migrate a state only when it's value is not what the old version 
defaults to.  This is the only way we can have our cake and eat it too.  
Anything less compromises integrity.

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.
> > >        
> > 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
> >
> >      
> Take the specific example. 0.13 has trouble under stress, it loses data.
> -M 0.13 is needed if you created the guest under 0.14, to make upgrading
> hypervisors seamless.
>
> This patch would force disabling flow control which
> is not needed if both version being migrated between
> are 0.14.
>
>
>