RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1251927 - The cpu model between managedsave XML and original XML is inconsistent.
Summary: The cpu model between managedsave XML and original XML is inconsistent.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: ppc64le
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Andrea Bolognani
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-10 10:22 UTC by Dan Zheng
Modified: 2018-03-23 10:51 UTC (History)
7 users (show)

Fixed In Version: libvirt-1.2.17-6.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 06:50:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Dan Zheng 2015-08-10 10:22:57 UTC 
Description of problem:
The cpu model between managedsave XML and original XML is inconsistent.

Version-Release number of selected component (if applicable):
Tests with below packages:
libvirt-1.2.17-3.el7.ppc64le
qemu-kvm-rhev-2.3.0-16.el7.ppc64le
kernel-3.10.0-302.el7.ppc64le


How reproducible:
100%

Steps to Reproduce:
1. Edit XML like below:
  <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>

or 
  <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>


2. Start the guest successfully
# virsh start q8
Domain q8 started

3. Run managedsave
# virsh managedsave q8

Domain q8 state saved by libvirt

4. Check save file
# vi  /var/lib/libvirt/qemu/save/q8.save
  <cpu mode='host-model' match='exact'>
    <model fallback='forbid'>power8e</model>
    <vendor>IBM</vendor>
    <numa>
      <cell id='0' cpus='0-1' memory='1048576' unit='KiB'/>
      <cell id='1' cpus='2-3' memory='1048576' unit='KiB'/>
    </numa>
  </cpu>

Problem: 'power8e' is inserted in managedsave XML file for above two configurations.



Actual result:
'power8e' is inserted in saved XML instead of power8.
When no cpu model is defined in original XML, 'power8e' is still inserted in managedsave XML.

Expected result:
There should be same configuration between saved XML file and original XML file.


Additional information:
--
Comment 2 Peter Krempa 2015-08-10 10:43:13 UTC 
Does the change of the model happen after starting the VM in the live XML? (prior to the managed save)
Comment 3 Dan Zheng 2015-08-11 01:21:52 UTC 
(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.
Comment 5 Andrea Bolognani 2015-08-22 00:11:10 UTC 
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
Comment 6 Dan Zheng 2015-08-24 07:16:17 UTC 
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>
Comment 7 Dan Zheng 2015-08-25 08:38:40 UTC 
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>
Comment 9 errata-xmlrpc 2015-11-19 06:50:41 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.