Bug 1519146
Summary: | Libvirt uses deprecated compat=xxx option | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Dan Zheng <dzheng> | |
Component: | libvirt | Assignee: | Andrea Bolognani <abologna> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 7.5 | CC: | bugproxy, dgibson, dzheng, gsun, haizhao, hannsj_uhl, jdenemar, junli, lvivier, michal.skrivanek, mtessun, mzamazal, qzhang, xianwang | |
Target Milestone: | rc | Keywords: | 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
Removing Blocks: on Bug 1396114 because the deprecated CPU-level compat option still works just fine. (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 Yes, Laurent, thanks for your correction. That is my carelessness. ------- 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.. 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 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 From shivapbh.com 2018-01-05 08:56 EDT------- Posted upstream for review. https://www.redhat.com/archives/libvir-list/2018-January/msg00172.html *** Bug 1582096 has been marked as a duplicate of this bug. *** 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. 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 ... (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? 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. (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. No, We always use the first one. Thanks. <cpu mode='host-model'> <model>power8</model> </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://access.redhat.com/errata/RHSA-2018:3113 |