Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version

[Paolo Bonzini]

Il 28/05/2014 14:04, Dr. David Alan Gilbert ha scritto:
> * Paolo Bonzini (address@hidden) wrote:
> > Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
> > > There aren't any uses of the migration version in this patch set, however
> > > uses I can think of include:
> > >    a) Generating an old format for a particular device when sent to a
> > >       particular version
> > >    b) Fudging a register value for a particular version
> > >    c) Fudging around more general problems (e.g. the 1.6.x short PCI naming)
> >
> > http://lists.gnu.org/archive/html/qemu-stable/2013-10/msg00019.html
>
> Yep, I'm aware of that one, it only solves some of the directions.

Ok, I wanted to make sure it's the same issue.

> > I don't think this is necessary; not yet at least.
>
> Yep, most things seem to be fudgable; however I'd point out the
> 'not yet at least' in your response; the intention of this patch is to
> already have the information/infrastructure in place so that if we do
> find a nasty case then it's easier to fix.
>
> It's also more likely in the case where people want to backward migrate
> across larger version gaps.

I think something as large as RHEL7->RHEL6 is the largest that anyone 
sane would try.  That's already too large probably.

I said "not yet at least" in the sense that I've not been convinced yet. 
 If it's useful, it's certainly better to get it in now.

> > Of the above three cases, (a) and (b) can be handled by machine types.
>
> I don't see how this is generally the case without having to boot the source
> QEMU with a machine type dependent on which destination you're going to go to,
> that you don't yet know.

You already need to boot the source QEMU with a machine type that 
_exists_ on the destination that you're going to go it, for example with 
the least common denominator of your cluster.  This is already the case, 
with or without this additional knob, and this is why I don't like 
adding it: you have a version-based knob already, which is the machine type.

> > (c) should have been caught by testing, and is not entirely solved by this
> > approach.  It would fix 2.0->1.6 migration, but not 1.6->2.0 migration with
> > -M pc-1.5.  In other words, it would not fix the case that we care about in
> > upstream.
>
> I think 1.6->2.0 -M pc-1.5 is fixable by the appropriate flag being passed to
> the 2.0 at startup to tell it to use/not-use the short-bus; not pretty though.

Yes, I think it can be already fixed with "-global 
i440FX-pcihost.short_root_bus=on".

> > and don't solve the fundamental problem of migration receiving
> > insufficient testing with upstream QEMU versions.
>
> Indeed; and it's not meant to - in no way is this an excuse for inadequate
> testing - however, we're all human, and bugs happen, this is just providing
> a way to get out of some of the mess afterwards.

But there is only one way to avoid the mess, and it's to test things. 
Because once you've released a buggy version, migration _from_ that 
version is f***ed up and going to involve hacks no matter what.

Downstreams that care should and do their own testing, with their own 
matrix.  If upstream cares, we need to test things at least across 
adjacent versions (1.5 <-> 1.6 <-> 1.7).  If we do this, and if the 
assumption is valid that migration compatibility is essentially 
transitive, it solves the problem much better than code can do

Paolo