Bug 1251927

Does the change of the model happen after starting the VM in the live XML? (prior to the managed save)

(In reply to Peter Krempa from comment #2)
> Does the change of the model happen after starting the VM in the live XML?
> (prior to the managed save)

Peter,
No. The change of the model happens after managed save. 
The order is 
1. Edit XML and start the guest ok with expected model.
2. Do managed save successfully 
3. Check the saved XML, then find the model is changed.

The bug has been fixed upstream by the following commits.

  commit 5750149fedb2ec7f1aaaad8286650255718c861d
  Author: Andrea Bolognani <abologna>
  Date:   Fri Aug 14 16:04:18 2015 +0200
  
      cpu: Move check for NULL CPU model inside the driver
      
      While the check is appropriate for eg. the x86 and generic drivers,
      there are some valid ppc64 guest configurations where the CPU
      model is supposed to be NULL.
      
      Moving this check from the generic code to the drivers makes it
      possible to accomodate both use cases.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927
  
  commit 2f913162ed615faa7227d7366b39fa59b23f233d
  Author: Andrea Bolognani <abologna>
  Date:   Thu Aug 13 17:50:37 2015 +0200
  
      cpu: Better support for ppc64 compatibility modes
      
      Not all combinations of host CPU models and compatibility modes
      are valid, so we need to make sure we don't try to do something
      that QEMU will reject.
      
      Moreover, we need to apply a different logic to guests using
      host-model and host-passthrough modes when testing them for host
      compatibility.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927
  
  commit 6d7c2f65c103c9b98baf595d14725e62651bdb1b
  Author: Andrea Bolognani <abologna>
  Date:   Thu Aug 13 13:40:12 2015 +0200
  
      cpu: Don't update host-model guest CPUs on ppc64
      
      If a guest CPU is defined using
      
        <cpu mode='host-model'/>
      
      the <model> sub-element will contain the compatibility mode to use.
      That means we can't just copy the host CPU model on cpuUpdate(),
      otherwise we'll overwrite that information and migration of such
      guests will fail.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251927

Tests with below packages:
libvirt-1.2.17-6.el7.ppc64le
qemu-kvm-rhev-2.3.0-18.el7.ppc64le
kernel-3.10.0-305.el7.ppc64le

Below tests are done:
All pass.

Start the guest with below XMl setting respectively successfully, then managedsave ok,  and the then the guest can be re-started successfully.
1.1  
  <cpu mode='host-model'>
    <model fallback='forbid'/>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
Below is Managedsave XML:
  Same as above.

1.2
 <cpu mode='host-model'>
    <model fallback='forbid'>power8</model>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
Below is Managedsave XML:
  <cpu mode='host-model' match='exact'>
    <model fallback='forbid'>power8</model>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>

1.3. 
 <cpu mode='host-model'>
     <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>
Below is Managedsave XML:
  <cpu mode='host-model'>
    <model fallback='allow'/>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>


1.4. 
  <cpu mode='host-passthrough'>
     <topology sockets='1' cores='2' threads='8'/>
  </cpu>
Below is Managedsave XML:
  <cpu mode='host-passthrough' match='exact'>
    <model>POWER8</model>
    <vendor>IBM</vendor>
    <topology sockets='1' cores='2' threads='8'/>
  </cpu>


1.5.  
  <cpu mode='custom' match='exact'>
     <model fallback='forbid'>POWER8</model>
     <topology sockets='1' cores='2' threads='8'/>
  </cpu>
Below is Managedsave XML:
  Same as above

1.6. 
  <cpu mode='custom' match='strict'>
   <topology sockets='1' cores='2' threads='8'/>
  </cpu>
Below is Managedsave XML:
 <cpu>
    <topology sockets='1' cores='2' threads='8'/>
  </cpu>

1.7 Using the XML  in 1.1, 1.2 ,1.3 and 1.5 for cpu model setting to test basic migration respectively.
All pass.

Like below:

1.7.1 
# virsh dumpxml q1|grep cpu -a7
  <cpu mode='host-model'>
    <model fallback='allow'/>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>


1.7.2 
# virsh migrate q1 --unsafe --live --verbose qemu+ssh://10.19.106.39/system
Migration: [100 %]

1.7.3 Check on target host(10.19.106.39).
# virsh list --all
 Id    Name                           State
----------------------------------------------------
 23    q1                             running

1.7.4 Check the cpu model on target host
# virsh dumpxml q1 |grep cpu -a7
  <cpu mode='host-model'>
    <model fallback='allow'/>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>

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