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

[Anthony Liguori]

Eduardo Habkost wrote:
> Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
>   
> > Juan Quintela wrote:
> >     
> > > But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
> > > RHEL5.4.1, you will see that the code bases are going to be really,
> > > really similar.  And if any savevm format is changed, it is because
> > > there are no other solution.
> > >   
> > >       
> > In our own stable branch, we do not introduce any savevm changes.  I 
> > would recommend the same policy for RHEL :-)
> >     
>
> But what if you need to add a savevm change to make migration work
> properly on the stable branch?

Define "properly".

If we have to introduce a new version in VMstate, there are two 
possibilities.  The first is that we have to backlist the old version 
because it was fundamentally broken.  This is rare but it happens.  In 
this case, we would not be able to support migrating from that stable 
release to any other stable release.  Really unfortunate for users but 
we would have no other choice.

The second is that we introduce a new version but don't blacklist the 
old.  This means the old version wasn't fundamentally broken.  It also 
means that the "fix" is a feature.  It makes things better but isn't 
strictly required.  That gets deferred to the next release.

>  You can't just tell users "migration is
> known to be broken on the stable branch, please don't run migrations
> when using the stable branch". That's the case for the pvclock MSR
> migration fix.
>   

You're assuming that backporting the pvclock change is a bug fix.  It's 
a new feature as far as I'm concerned and doesn't belong in stable.

> In a perfect world, the set of state data that is migrated by the
> current implementation would always match exactly the expected behavior
> of the virtual machine. Unfortunately sometimes the implementation
> doesn't follow the "contract" (be it some written specification,
> documentation, or just user expectations).  When that happens, it is a
> bug on qemu and it needs to be fixed on the stable branch.
>
> Note that (right now) I am not arguing for backward migration, but just
> arguing that we can't have a strict "no savevm changes" policy on the
> stable branch.
>   

That's exactly what I'm advocating: a strict savevm policy for stable 
branch.  It's something I've always enforced in the past.  It's 
necessary to preserve the integrity of live migration.

Regards,

Anthony Liguori