Bug 1541328 - [ansible] deployment fails on Opteron CPUs due to bad cpu type in vm.conf at the end
Summary: [ansible] deployment fails on Opteron CPUs due to bad cpu type in vm.conf at ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: General
Version: 2.2.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.2.2
: ---
Assignee: Simone Tiraboschi
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks: 1458709
TreeView+ depends on / blocked
 
Reported: 2018-02-02 09:52 UTC by Simone Tiraboschi
Modified: 2018-03-29 11:06 UTC (History)
12 users (show)

Fixed In Version: ovirt-hosted-engine-setup-2.2.10
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-29 11:06:35 UTC
oVirt Team: Integration
Embargoed:
rule-engine: ovirt-4.2+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 87050 0 master MERGED ansible: correctly parse CPU model 2020-09-09 17:22:23 UTC
oVirt gerrit 87060 0 ovirt-hosted-engine-setup-2.2 MERGED ansible: correctly parse CPU model 2020-09-09 17:22:23 UTC

Description Simone Tiraboschi 2018-02-02 09:52:57 UTC
Description of problem:
On Opteron systems the deployment fails due to a bad CPU type in vm.conf.

We have:
# Editing the hosted engine VM is only possible via the manager UI\API

vmId=b8bac1d8-2c0a-4489-afd7-dafb7d0e3d6a
memSize=16384
display=vnc
devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0, bus:1, type:drive},specParams:{},readonly:true,deviceId:b3f76c67-e112-4427-a219-4b8a9dbdfa89,path:,device:cdrom,shared:false,type:disk}
devices={index:0,iface:virtio,format:raw,poolID:00000000-0000-0000-0000-000000000000,volumeID:39576610-89f6-42e1-a115-0c952d84ee08,imageID:06e0839c-78ad-428e-85da-49ad3fb5f1df,specParams:{},readonly:false,domainID:ac26b024-444b-4cd8-9b5f-eb0008f2551f,optional:false,deviceId:39576610-89f6-42e1-a115-0c952d84ee08,address:{bus:0x00, slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shared:exclusive,propagateErrors:off,type:disk,bootOrder:1}
devices={device:scsi,model:virtio-scsi,type:controller}
devices={nicModel:pv,macAddr:00:16:3e:1c:e2:4b,linkActive:true,network:ovirtmgmt,specParams:{},deviceId:89eccfd9-acc3-4946-8268-bb7ad6c6f0ac,address:{bus:0x00, slot:0x03, domain:0x0000, type:pci, function:0x0},device:bridge,type:interface}
devices={device:console,type:console}
devices={device:vga,alias:video0,type:video}
devices={device:vnc,type:graphics}
vmName=HostedEngine
spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir
smp=4
maxVCpus=16
cpuType=Opteron G5
emulatedMachine=pc-i440fx-rhel7.3.0
devices={device:virtio,specParams:{source:urandom},model:virtio,type:rng}

while it should be:
cpuType=Opteron_G5



Version-Release number of selected component (if applicable):
ovirt-hosted-engine-setup-2.2.9

How reproducible:
just on opteron CPUs

Steps to Reproduce:
1. try to deploy hosted-engine via ansible (from cli or form cockpit) an AMD hosts
2.
3.

Actual results:
The setup hangs on:
[ INFO  ] TASK [Wait for the engine to come up on the target VM]
[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed": true, "cmd": ["hosted-engine", "--vm-status", "--json"], "delta": "0:00:00.268333", "end": "2018-02-02 04:10:35.409954", "rc": 0, "start": "2018-02-02 04:10:35.141621", "stderr": "", "stderr_lines": [], "stdout": "{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, \"extra\": \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=2161 (Fri Feb  2 04:10:32 2018)\\nhost-id=1\\nscore=0\\nvm_conf_refresh_time=2162 (Fri Feb  2 04:10:33 2018)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineUnexpectedlyDown\\nstopped=False\\ntimeout=Wed Dec 31 19:36:27 1969\\n\", \"hostname\": \"dell-per515-02.lab.eng.pek2.redhat.com\", \"host-id\": 1, \"engine-status\": {\"reason\": \"bad vm status\", \"health\": \"bad\", \"vm\": \"down_unexpected\", \"detail\": \"Down\"}, \"score\": 0, \"stopped\": false, \"maintenance\": false, \"crc32\": \"f7c57b4c\", \"local_conf_timestamp\": 2162, \"host-ts\": 2161}, \"global_maintenance\": false}", "stdout_lines": ["{\"1\": {\"conf_on_shared_storage\": true, \"live-data\": true, \"extra\": \"metadata_parse_version=1\\nmetadata_feature_version=1\\ntimestamp=2161 (Fri Feb  2 04:10:32 2018)\\nhost-id=1\\nscore=0\\nvm_conf_refresh_time=2162 (Fri Feb  2 04:10:33 2018)\\nconf_on_shared_storage=True\\nmaintenance=False\\nstate=EngineUnexpectedlyDown\\nstopped=False\\ntimeout=Wed Dec 31 19:36:27 1969\\n\", \"hostname\": \"dell-per515-02.lab.eng.pek2.redhat.com\", \"host-id\": 1, \"engine-status\": {\"reason\": \"bad vm status\", \"health\": \"bad\", \"vm\": \"down_unexpected\", \"detail\": \"Down\"}, \"score\": 0, \"stopped\": false, \"maintenance\": false, \"crc32\": \"f7c57b4c\", \"local_conf_timestamp\": 2162, \"host-ts\": 2161}, \"global_maintenance\": false}"]}

in /var/log/message we see:
Feb  2 04:16:12 localhost libvirtd: 2018-02-02 09:16:12.710+0000: 30216: error : x86ModelFromCPU:1061 : internal error: Unknown CPU model OpteronG5

And in /var/run/ovirt-hosted-engine-ha/vm.conf we see 
cpuType=Opteron G5
instead of
cpuType=Opteron_G5


Expected results:
successful deployment on Opteron systems

Additional info:

Comment 1 Michal Skrivanek 2018-02-03 08:16:39 UTC
also note that in 4.2 RHV the machine type of 4.2 Clusters is pc-i440fx-rhel7.5.0, and in 4.2 oVirt it's pc-i440fx-rhel7.3.0 (since we're already released GA)

Comment 2 Polina 2018-02-25 08:07:57 UTC
verified in 
 
ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch


# Editing the hosted engine VM is only possible via the manager UI\API

cpuType=Opteron_G3
emulatedMachine=pc-i440fx-rhel7.3.0
vmId=bfe04467-6470-421d-b387-ddb1938bd863
smp=2
memSize=4096
maxVCpus=32

Comment 3 Sandro Bonazzola 2018-03-29 11:06:35 UTC
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

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


Note You need to log in before you can comment on or make changes to this bug.