Bug 1294866 - Support live guest migration from rhel 7 to rhel 6
Support live guest migration from rhel 7 to rhel 6
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Dr. David Alan Gilbert
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2015-12-30 14:00 EST by Yuri Arabadji
Modified: 2016-06-30 08:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-06-30 08:22:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Yuri Arabadji 2015-12-30 14:00:08 EST
Redhat KB lists migration path as unsupported, but with this patch https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg00990.html it should be doable. 

See his blog post for more info http://www.anchor.com.au/blog/2015/11/bugfixing-kvm-live-migration/ 

Comment 3 Yuri Arabadji 2016-01-11 08:42:22 EST
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.
Comment 4 Dr. David Alan Gilbert 2016-01-11 09:47:08 EST
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).
Comment 5 Dr. David Alan Gilbert 2016-06-30 08:22:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.