Just a note that the patch didn't work for me. Guest is resumed, but it's not continuing the execution. CPU is 0%, display is blank and unresponsive. "kvm_stat -l" counters are all 0.

I need to investigate this patch a little; but the challenge is that while it fixes one piece of state to produce backwardly compatible data, many other parts of the state need checking to make sure they dont introduce backwards compatible behaviour as well.  That check is quite tricky (since there tend to be non-obvious effects that are found when you try them).

Hi Yuri,
  I'm marking this as a wont-fix, but I wanted to explain why.

The problem we have is that the old 0.12 qemu in RHEL6 has many places that are different from the more modern versions in rhel7.  The changes are quite varied, and there are a bunch of different problems that stop us going in the reverse direction:

   a) There are things where the format of the migration data has changed; the newer qemu's have code to read the old migration formats for devices but they don't have code to write the format needed by the older version; I found one example of this a few days ago when debugging a different problem.

   b) More subtle things like the patch you found, where a combination of patches in qemu or the kernel, that individually look harmless, cause a migration problem.

   c) Newer qemu making use of features that the old one can't support.


If we wanted to do this we'd have to write tools and things to find all the cases of (a) - we could find those and somehow write work arounds for many of them.

Finding (c) is actually quite hard; when you use a new feature you don't necessarily think about making it backwards compatibil that far.

Then finding (b) is *really* hard - when you look at each of the individual changes you don't necessarily realise they're going to cause a migration problem, so the only way to find out is a LOT of testing.