Bug 1519146

Summary: Libvirt uses deprecated compat=xxx option
Product: Red Hat Enterprise Linux 7 Reporter: Dan Zheng <dzheng>
Component: libvirtAssignee: Andrea Bolognani <abologna>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 7.5CC: bugproxy, dgibson, dzheng, gsun, haizhao, hannsj_uhl, jdenemar, junli, lvivier, michal.skrivanek, mtessun, mzamazal, qzhang, xianwang
Target Milestone: rcKeywords: Patch, ZStream
Target Release: 7.6   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-4.3.0-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1582125 (view as bug list) Environment:
Last Closed: 2018-10-30 09:50:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1513404, 1528344, 1582125    

Description Dan Zheng 2017-11-30 09:34:58 UTC
Description of problem:

According to https://bugzilla.redhat.com/show_bug.cgi?id=1493954 and https://github.com/qemu/qemu/commit/7843c0d60db694b6d97e14ec5538fb97424016c1,

'compat' is deprecated now. But libvirt still uses it.

Version-Release number of selected component (if applicable):
libvirt-3.9.0-3.el7.ppc64le
qemu-kvm-rhev-2.10.0-9.el7.ppc64le
kernel-4.14.0-4.el7a.ppc64le

How reproducible:
100%

Steps to Reproduce:
1. Add this in the guest XML
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'>power9</model>
    <topology sockets='2' cores='10' threads='1'/>
  </cpu>

2. Start the guest

3. Qemu line:
# ps -ef|grep qemu|grep cpu
qemu      33589      1 89 09:56 ?        00:00:09 /usr/libexec/qemu-kvm -name guest=vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-vm1/master-key.aes -machine pseries-rhel7.5.0,accel=kvm,usb=off,dump-guest-core=off ***-cpu host,compat=power9*** -m 20480 

4. dumpxml guest
  <cpu mode='host-model' check='partial'>
    <model fallback='forbid'>power9</model>
    <topology sockets='2' cores='10' threads='1'/>
  </cpu>


Actual results:
***-cpu host,compat=power9*** 


Expected results:
It should be ***-cpu host,max-cpu-compat=power9*** 


Additional info:

Comment 2 Andrea Bolognani 2017-12-13 14:24:58 UTC
Removing Blocks: on Bug 1396114 because the deprecated CPU-level
compat option still works just fine.

Comment 3 Laurent Vivier 2017-12-13 16:43:41 UTC
(In reply to Dan Zheng from comment #0)
> Expected results:
> It should be ***-cpu host,max-cpu-compat=power9*** 


In fact, "max-cpu-compat" is a machine option, not a "cpu" option.

The correct syntax is, for instance:

    -machine pseries-rhel7.5.0,max-cpu-compat=power9

Comment 4 Dan Zheng 2017-12-14 10:07:57 UTC
Yes, Laurent, thanks for your correction. That is my carelessness.

Comment 5 IBM Bug Proxy 2017-12-18 06:50:35 UTC
------- Comment From sthoufee.com 2017-12-18 01:43 EDT-------
(In reply to comment #9)
> Yes, Laurent, thanks for your correction. That is my carelessness.

Did you able to start the guest with

-machine pseries-rhel7.5.0,max-cpu-compat=power9 option now ?  Please verify.. if this is not a bug, then we will reject it..

Comment 6 Dan Zheng 2017-12-18 10:04:39 UTC
The problem in this bug is the wrong qemu command line for '-cpu host,compat=power9' which is expected to be '-machine pseries-rhel7.5.0,max-cpu-compat=power9'. So this problem still exists now.


/usr/libexec/qemu-kvm -name guest=vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-60-vm1/master-key.aes ***-machine pseries-rhel7.5.0,accel=kvm,usb=off,dump-guest-core=off -cpu host,compat=power9 *** -m

Comment 7 Andrea Bolognani 2018-01-05 16:16:33 UTC
Merged upstream.

  commit 2b041dc8c7b70e762d99b6bd7805daa9961740f6
  Author: Shivaprasad G Bhat <sbhat.ibm.com>
  Date:   Fri Jan 5 19:18:00 2018 +0530

    qemu: Add support for pseries machine's max-cpu-compat= parameter
    
    When the -machine pseries,max-cpu-compat=X is supported use
    machine parameter instead of -cpu host,compat=X parameter as
    that is deprecated now with qemu >= v2.10.
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1519146
    
    Signed-off-by: Shivaprasad G Bhat <sbhat.ibm.com>
    Reviewed-by: Andrea Bolognani <abologna>

v3.10.0-131-g2b041dc8c

Comment 8 IBM Bug Proxy 2018-01-07 10:31:07 UTC
------- Comment From shivapbh.com 2018-01-05 08:56 EDT-------
Posted upstream for review.

https://www.redhat.com/archives/libvir-list/2018-January/msg00172.html

Comment 14 Jiri Denemark 2018-05-25 10:51:47 UTC
*** Bug 1582096 has been marked as a duplicate of this bug. ***

Comment 16 Dan Zheng 2018-05-28 10:52:02 UTC
Andrea,
I do not remember any bug for P8-P9 migration in RHEL7.5 from libvirt.

We did not find serious migration issue and included the test results in https://bugzilla.redhat.com/show_bug.cgi?id=1493844#c9 and https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c21 and https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c20.

I am interested in what error messages they got when failed and how they are able to use ' -machine pseries-7.5.0,max-cpu-compat=power8' in libvirt to test.

Comment 17 Dan Zheng 2018-05-30 08:55:57 UTC
Test on P8:
OS tree: RHEL-7.6-20180519.n.0
kernel 3.10.0-889.el7.ppc64le
libvirt-4.3.0-1.el7.ppc64le
qemu-kvm-rhev-2.12.0-2.el7.ppc64le

XML:


  <cpu mode='host-model' check='partial'>
    <model fallback='forbid'>power8</model>
    <topology sockets='2' cores='10' threads='1'/>
  </cpu>


Start guest ok
Qemu command line:

...
-machine pseries-rhel7.5.0,accel=kvm,usb=off,dump-guest-core=off,max-cpu-compat=power8 -cpu host -m 20480
...

Comment 18 Andrea Bolognani 2018-05-30 09:04:17 UTC
(In reply to Dan Zheng from comment #16)
> Andrea,
> I do not remember any bug for P8-P9 migration in RHEL7.5 from libvirt.
> 
> We did not find serious migration issue and included the test results in
> https://bugzilla.redhat.com/show_bug.cgi?id=1493844#c9 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c21 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c20.

I tried poking around in Jenkins but couldn't find any evidence

  <cpu mode='host-model'>
    <model>power8</model>
  </cpu>

was used when testing migration between POWER8 and POWER9. Can you
please point me towards it?

Comment 19 Dan Zheng 2018-05-30 09:15:49 UTC
Andrea, 

Testing with below was not yet covered in our Jenkins jobs.
  <cpu mode='host-model'>
    <model>power8</model>
  </cpu>

But IBM has a PR for compat mode guest migration testcases in upstream and they provided their test results here https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c20

PR: https://github.com/autotest/tp-libvirt/pull/1312

Including that PR in our jenkins is under investigation.

Thanks.

Comment 20 Andrea Bolognani 2018-05-30 09:43:48 UTC
(In reply to Dan Zheng from comment #19)
> Andrea, 
> 
> Testing with below was not yet covered in our Jenkins jobs.
>   <cpu mode='host-model'>
>     <model>power8</model>
>   </cpu>
> 
> But IBM has a PR for compat mode guest migration testcases in upstream and
> they provided their test results here
> https://bugzilla.redhat.com/show_bug.cgi?id=1396114#c20
> 
> PR: https://github.com/autotest/tp-libvirt/pull/1312
> 
> Including that PR in our jenkins is under investigation.

Good! I'd be surprised if migration between POWER8 and POWER9
worked at all without either that or

  <cpu>
    <model>POWER8</model>
  </cpu>

which is, however, not recommended, so if you're using the
latter you should definitely consider moving away from it.

Comment 21 Dan Zheng 2018-05-30 10:06:06 UTC
No, We always use the first one. Thanks.
   <cpu mode='host-model'>
     <model>power8</model>
   </cpu>

Comment 23 errata-xmlrpc 2018-10-30 09:50:00 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://access.redhat.com/errata/RHSA-2018:3113