[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version
Date: Wed, 28 May 2014 14:41:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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)


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]