Bug 1248350

Created attachment 1057541 [details]
libvirtd log on target host

Created attachment 1057542 [details]
qemu log on source host

Created attachment 1057543 [details]
qemu log on target host

Upstream fix:

commit 136f3de4112c75af0b38fc1946f44e3658ed1890
Author: Peter Krempa <pkrempa>
Date:   Thu Jul 30 15:27:07 2015 +0200

    qemu: Reject migration with memory-hotplug if destination doesn't support it
    
    If destination libvirt doesn't support memory hotplug since all the
    support was introduced by adding new elements the destination would
    attempt to start qemu with an invalid configuration. The worse part is
    that qemu might hang in such situation.
    
    Fix this by sending a required migration feature called 'memory-hotplug'
    to the destination. If the destination doesn't recognize it it will fail
    the migration.

Verify this bug on build:

1)Source version:
libvirt-1.2.17-6.el7.x86_64

2)Target version:
libvirt-1.2.8-16.el7_1.3.x86_64

Scenario 1(maxmemory in active xml, live migrate):
0.Prepare two hosts: source(RHEL7.2) and target(RHEL7.1)

1.Prepare a running guest on source host with maxMemory setting:
<domain type='kvm'>
  <name>rhel7d1</name>
  <uuid>62a79b7d-e743-4fd3-86a7-18d6a665993d</uuid>
  <maxMemory slots='16' unit='KiB'>2124288</maxMemory>
  <memory unit='KiB'>1024000</memory>
  <currentMemory unit='KiB'>1024000</currentMemory>
...

2.Migrate the guest to target host:
# virsh migrate rhel7d1 qemu+ssh://10.66.6.6/system --verbose --live --persistent
error: internal error: Unknown migration cookie feature memory-hotplug


Scenario 2(maxmemory in inactive xml, live migrate):
1.Prepare a running guest on source host without maxMemory setting.

2.Edit the guest xml, add the maxmemory attribute:
# virsh edit rhel7d1
...
  <maxMemory slots='16' unit='KiB'>2124288</maxMemory>
...
Domain rhel7d1 XML configuration edited.

3.Migrate the guest to target host:
# virsh migrate rhel7d1 qemu+ssh://10.66.6.6/system --verbose --live 
error: internal error: Unknown migration cookie feature memory-hotplug

or 
# virsh migrate rhel7d1 qemu+ssh://10.66.6.6/system --verbose --live --persistent
error: internal error: Unknown migration cookie feature memory-hotplug


Scenario 3(maxmemory in inactive xml, offline migrate):
1.Prepare a guest with xml:
<domain type='kvm'>
  <name>rhel7d1</name>
  <uuid>62a79b7d-e743-4fd3-86a7-18d6a665993d</uuid>
  <maxMemory slots='16' unit='KiB'>2124288</maxMemory>
  <memory unit='KiB'>1024000</memory>
  <currentMemory unit='KiB'>1024000</currentMemory>
...

2.# virsh migrate rhel7d1 qemu+ssh://10.66.6.6/system --offline --persistent
error: internal error: Unknown migration cookie feature memory-hotplug


I have a question with scenario2 -> step3, when migrating without --persistent, why does it also check the maxmemory setting in the inactive xml?

The checking code didn't take into account that corner case. I'll post a patch upstream but I don't think it's worth backporting.

(In reply to Peter Krempa from comment #9)
> The checking code didn't take into account that corner case. I'll post a
> patch upstream but I don't think it's worth backporting.

Since it's not a big issue, I will verify this bug.

Patch for the corner issue described above was merged upstream:

commit a98e5a78153644e0f13b34c69d60b7a866c4401a
Author: Peter Krempa <pkrempa>
Date:   Tue Sep 8 15:06:26 2015 +0200

    qemu: migration: Relax enforcement of memory hotplug support
    
    If the current live definition does not have memory hotplug enabled, but
    the persistent one does libvirt would reject migration if the
    destination does not support memory hotplug even if the user didn't want
    to persist the VM at the destination and thus the XML containing the
    memory hotplug definition would not be used. To fix this corner case the
    code will check for memory hotplug in the newDef only if
    VIR_MIGRATE_PERSIST_DEST was used.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html