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.