DescriptionSimone 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:
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)
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
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.