New oVirt Install - Host Engine Deployment Fails

I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now. The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage. [ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"} 2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 } I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance. [root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running Looking at the "Convert CPU model name" task: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks... set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find. Any advice or recommendation is appreciated -Thanks in advance

What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported). On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:

Thanks for the quick response. Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem. Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents. # grep -E 'svm|vmx' /proc/cpuinfo | grep n Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported. Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage? Thanks again On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks... <https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml>
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:

Wondering if there are any suggestions here before I wipe these nodes and go back to another Hypervisor. On 9/14/2020 12:59 PM, Michael Blanton wrote:
Thanks for the quick response.
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents.
# grep -E 'svm|vmx' /proc/cpuinfo | grep n
Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported.
Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage?
Thanks again
On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ
et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:

You didn't mention your CPU type. Best Regards, Strahil Nikolov В сряда, 16 септември 2020 г., 20:44:23 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа: Wondering if there are any suggestions here before I wipe these nodes and go back to another Hypervisor. On 9/14/2020 12:59 PM, Michael Blanton wrote:
Thanks for the quick response.
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents.
# grep -E 'svm|vmx' /proc/cpuinfo | grep n
Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported.
Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage?
Thanks again
On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ
et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FYI5DDI7RNVSWE...

In my previous reply:
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Xeon 5130 "Woodcrest" Do you need something more specific or different? I also found one a reply from you on an older thread and added it: ~~~ 100 - name: Debug why parsing fails 101 debug: 102 msg: 103 - "Loop is done over {{server_cpu_list.json['values']['system_option_value'][0]['value'].split(';')|list| difference(['']) }}" 104 - "Actual value of server_cpu_dict before the set_fact is {{server_cpu_dict }}" 105 - name: Parse server CPU list 106 set_fact: 107 server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}" 108 with_items: >- 109 {{ server_cpu_list.json['values']['system_option_value'][0]['value'].split('; ')|list|difference(['']) }} 110 - debug: var=server_cpu_dict 111 - name: Convert CPU model name 112 set_fact: 113 cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" 114 - debug: var=cluster_cpu_model ~~~ [ INFO ] ["Loop is done over ['1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64', ' 2:Secure Intel Nehalem Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64', ' 4:Secure Intel Westmere Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 5:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64', ' 6:Secure Intel SandyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64', ' 8:Secure Intel IvyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 9:Intel Haswell Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64', ' 10:Secure Intel Haswell Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 11:Intel Broadwell Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64', ' 12:Secure Intel Broadwell Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 13:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client,-hle,-rtm:x86_64', ' 14:Secure Intel Skylake Client Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 15:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server,-hle,-rtm:x86_64', ' 16:Secure Intel Skylake Server Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 17:Intel Cascadelake Server Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64', ' 18:Secure Intel Cascadelake Server Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64', ' 1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64', ' 2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64', ' 3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64', ' 4:Secure AMD EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64', ' 1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64', ' 2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64', ' 1:IBM z114, z196:sie,model_z196-base:z196-base:s390x', ' 2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x', ' 3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x', ' 4:IBM z14:sie,model_z14-base:z14-base:s390x']", 'Actual value of server_cpu_dict before the set_fact is {}'] [ INFO ] TASK [ovirt.hosted_engine_setup : Parse server CPU list] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 110, column 15, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"} On 9/16/2020 4:14 PM, Strahil Nikolov wrote:
You didn't mention your CPU type.
Best Regards, Strahil Nikolov
В сряда, 16 септември 2020 г., 20:44:23 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа:
Wondering if there are any suggestions here before I wipe these nodes and go back to another Hypervisor.
On 9/14/2020 12:59 PM, Michael Blanton wrote:
Thanks for the quick response.
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents.
# grep -E 'svm|vmx' /proc/cpuinfo | grep n
Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported.
Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage?
Thanks again
On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ
et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FYI5DDI7RNVSWE...

It seems that this one fails : - name: Parse server CPU list set_fact: server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}" In cases like that I usually define a new variable. Can you put another task before that like: - name: Debug server_cpu_dict debug: var: server_cpu_dict Best Regards, Strahil Nikolov В четвъртък, 17 септември 2020 г., 00:30:57 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа: In my previous reply:
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Xeon 5130 "Woodcrest" Do you need something more specific or different? I also found one a reply from you on an older thread and added it: ~~~ 100 - name: Debug why parsing fails 101 debug: 102 msg: 103 - "Loop is done over {{server_cpu_list.json['values']['system_option_value'][0]['value'].split(';')|list| difference(['']) }}" 104 - "Actual value of server_cpu_dict before the set_fact is {{server_cpu_dict }}" 105 - name: Parse server CPU list 106 set_fact: 107 server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}" 108 with_items: >- 109 {{ server_cpu_list.json['values']['system_option_value'][0]['value'].split('; ')|list|difference(['']) }} 110 - debug: var=server_cpu_dict 111 - name: Convert CPU model name 112 set_fact: 113 cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" 114 - debug: var=cluster_cpu_model ~~~ [ INFO ] ["Loop is done over ['1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64', ' 2:Secure Intel Nehalem Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64', ' 4:Secure Intel Westmere Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 5:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64', ' 6:Secure Intel SandyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64', ' 8:Secure Intel IvyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 9:Intel Haswell Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64', ' 10:Secure Intel Haswell Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 11:Intel Broadwell Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64', ' 12:Secure Intel Broadwell Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 13:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client,-hle,-rtm:x86_64', ' 14:Secure Intel Skylake Client Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 15:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server,-hle,-rtm:x86_64', ' 16:Secure Intel Skylake Server Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 17:Intel Cascadelake Server Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64', ' 18:Secure Intel Cascadelake Server Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64', ' 1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64', ' 2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64', ' 3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64', ' 4:Secure AMD EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64', ' 1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64', ' 2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64', ' 1:IBM z114, z196:sie,model_z196-base:z196-base:s390x', ' 2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x', ' 3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x', ' 4:IBM z14:sie,model_z14-base:z14-base:s390x']", 'Actual value of server_cpu_dict before the set_fact is {}'] [ INFO ] TASK [ovirt.hosted_engine_setup : Parse server CPU list] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 110, column 15, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"} On 9/16/2020 4:14 PM, Strahil Nikolov wrote:
You didn't mention your CPU type.
Best Regards, Strahil Nikolov
В сряда, 16 септември 2020 г., 20:44:23 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа:
Wondering if there are any suggestions here before I wipe these nodes and go back to another Hypervisor.
On 9/14/2020 12:59 PM, Michael Blanton wrote:
Thanks for the quick response.
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents.
# grep -E 'svm|vmx' /proc/cpuinfo | grep n
Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported.
Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage?
Thanks again
On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ
et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FYI5DDI7RNVSWE...

Thanks again for the help on this. Summary: Got past one roadblock only to hit another. Time to give up. Feel free to review my notes in case I missed anything. I had to give myself a bit of crash course in Ansible to follow the playbook. See if I have this correct: ~~~ 100 - name: Parse server CPU list 101 set_fact: 102 server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}" 103 with_items: >- 104 {{ server_cpu_list.json['values']['system_option_value'][0]['value'].split('; ')|list|difference([ '']) }} 105 - debug: var=server_cpu_dict 106 - name: Debugging why deployment fails #1 107 debug: 108 msg: 109 - "Loop is done over {{server_cpu_list.json['values']['system_option_value'][0]['value'].split('; ')|list|difference(['']) }}" 110 - "Actual value of server_cpu_dict before the set_fact is {{server_cpu_dict }}" 111 - name : Debuggind when deployment fails #2 112 debug: 113 msg: 114 - "cluster_cpu is {{ cluster_cpu }}" 115 - "ovirt_cluster_info is {{ ovirt_cluster_info }}" 116 - name: Convert CPU model name 117 set_fact: 118 cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" 119 - debug: var=cluster_cpu_model ~~~ Now we fail on my Debug #2 task. [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'ovirt_cluster_info' is undefined\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 111, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n - \"Actual value of server_cpu_dict before the set_fact is {{server_cpu_dict }}\"\n - name : Debuggind when deployment fails #2\n ^ here\n"} Tracing this backwards 'server_cpu_dict' is set in 'Parse server CPU list'. It is built from server_cpu_list So, I need to add the debug after that fact is created. The debug failed because I had it before. I moved it and nowit traces correctly. In fact there is already a debug at line 105 for that. Mine is now just a duplicate, but I kept it as a learning expereince for instrumenting Ansible. server_cpu_list is set in 'Get server CPU list via REST API'. It is the return from the API call to the running local instance INFO ] ["Loop is done over ['1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64', ' 2:Secure Intel Nehalem Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64', ' 4:Secure Intel Westmere Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 5:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64', ' 6:Secure Intel SandyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64', ' 8:Secure Intel IvyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 9:Intel Haswell Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64', ' 10:Secure Intel Haswell Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 11:Intel Broadwell Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64', ' 12:Secure Intel Broadwell Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 13:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client,-hle,-rtm:x86_64', ' 14:Secure Intel Skylake Client Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 15:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server,-hle,-rtm:x86_64', ' 16:Secure Intel Skylake Server Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 17:Intel Cascadelake Server Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64', ' 18:Secure Intel Cascadelake Server Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64', ' 1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64', ' 2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64', ' 3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64', ' 4:Secure AMD EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64', ' 1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64', ' 2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64', ' 1:IBM z114, z196:sie,model_z196-base:z196-base:s390x', ' 2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x', ' 3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x', ' 4:IBM z14:sie,model_z14-base:z14-base:s390x']", "Actual value of server_cpu_dict before the set_fact is {'Intel Nehalem Family': 'Nehalem', 'Secure Intel Nehalem Family': 'Nehalem,+spec-ctrl,+ssbd,+md-clear', 'Intel Westmere Family': 'Westmere', 'Secure Intel Westmere Family': 'Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear', 'Intel SandyBridge Family': 'SandyBridge', 'Secure Intel SandyBridge Family': 'SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear', 'Intel IvyBridge Family': 'IvyBridge', 'Secure Intel IvyBridge Family': 'IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear', 'Intel Haswell Family': 'Haswell-noTSX', 'Secure Intel Haswell Family': 'Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear', 'Intel Broadwell Family': 'Broadwell-noTSX', 'Secure Intel Broadwell Family': 'Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear', 'Intel Skylake Client Family': 'Skylake-Client,-hle,-rtm', 'Secure Intel Skylake Client Family': 'Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm', 'Intel Skylake Server Family': 'Skylake-Server,-hle,-rtm', 'Secure Intel Skylake Server Family': 'Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm', 'Intel Cascadelake Server Family': 'Cascadelake-Server,-hle,-rtm,+arch-capabilities', 'Secure Intel Cascadelake Server Family': 'Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities', 'AMD Opteron G4': 'Opteron_G4', 'AMD Opteron G5': 'Opteron_G5', 'AMD EPYC': 'EPYC', 'Secure AMD EPYC': 'EPYC,+ibpb,+virt-ssbd', 'IBM POWER8': 'POWER8', 'IBM POWER9': 'POWER9', 'IBM z114, z196': 'z196-base', 'IBM zBC12, zEC12': 'zEC12-base', 'IBM z13s, z13': 'z13-base', 'IBM z14': 'z14-base'}"] Making sure it matches the API https://ovirt-engine.home.io:6900/ovirt-engine/api/options/ServerCPUList?ver... { "values": { "system_option_value": [ { "value": "1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64; 2:Secure Intel Nehalem Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64; 3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; 4:Secure Intel Westmere Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64; 5:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; 6:Secure Intel SandyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64; 7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64; 8:Secure Intel IvyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64; 9:Intel Haswell Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64; 10:Secure Intel Haswell Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64; 11:Intel Broadwell Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64; 12:Secure Intel Broadwell Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64; 13:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client,-hle,-rtm:x86_64; 14:Secure Intel Skylake Client Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64; 15:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server,-hle,-rtm:x86_64; 16:Secure Intel Skylake Server Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64; 17:Intel Cascadelake Server Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64; 18:Secure Intel Cascadelake Server Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64; 1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; 2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; 3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64; 4:Secure AMD EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64; 1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64; 2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64; 1:IBM z114, z196:sie,model_z196-base:z196-base:s390x; 2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x; 3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x; 4:IBM z14:sie,model_z14-base:z14-base:s390x;", "version": "4.4" } ] }, "name": "ServerCPUList", "href": "/ovirt-engine/api/options/ServerCPUList", "id": "ServerCPUList" } So our issue must be with 'cluster_cpu.type' 'cluster_cpu' is set in 'Parse Cluster details'. This is build from 'cluster_facts.ovirt_clusters' cluster_facts.ovirt_clusters is set in 'Fetch Cluster name' cluster_facts is set in 'Fetch Cluster facts' I have not gotten into 'ovirt_cluster_info' module yet. https://docs.ansible.com/ansible/latest/modules/ovirt_cluster_module.html I went ahead and dug around in the docs for the other API calls. I found the one that appears to match the ovirt Anbile module call. http://ovirt.github.io/ovirt-engine-api-model/4.4/#services/cluster I can get the ID of the default cluster, then pull the details. https://ovirt-engine.home.io:6900/ovirt-engine/api/clusters/b198fd0c-f8df-11... "cpu": { "architecture": "undefined", "type": "" } So, the 'Type' and 'Architecture' are still undefined for the cluster, even though the first node is added at this point. I though I would try a post to the API to change the settings, just to see if I could make any progress. PUT https://ovirt-engine.home.io:6900/ovirt-engine/api/clusters/b198fd0c-f8df-11... <cluster> <cpu> <type>Intel Nehalem Family</type> <architecture>x86_64</architecture> </cpu> </cluster> Result: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <detail>[Cannot change Cluster CPU to higher CPU type when there are active Hosts with lower CPU type. -Please move Host ovirt-node01.home.io with lower CPU to maintenance first.]</detail> <reason>Operation Failed</reason> </fault> Let's find the first node: https://ovirt-engine.home.io:6900/ovirt-engine/api/hosts "address": "ovirt-node01.home.io", "auto_numa_status": "unknown", "certificate": { "organization": "home.io", "subject": "O=home.io,CN=ovirt-node01.home.io" }, "cpu": { "name": "Intel(R) Xeon(R) CPU 5130 @ 2.00GHz", } Summary so far: We have the HostedEngineLocal instance online. The first node is joined to the cluster. However, we do not set the cpu architecture or cpu type properties on the cluster object. This is the cause of the playbook failure when we attempt to access the undefined property. I might dig a little more into this to understand why it's not set on the cluster, but that will get into ovirt code and probably not worth the effort. I am able to set the cpu architecture via the API PUT https://ovirt-engine.home.io:6900/ovirt-engine/api/clusters/b198fd0c-f8df-11... <cluster> <cpu> <architecture>x86_64</architecture> </cpu> </cluster> "cpu": { "architecture": "x86_64", "type": "" }, [ INFO ] ["cluster_cpu is {'architecture': 'x86_64', 'type': ''}"] But, as expected, we still fail on the 'type' call in cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" [ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 115, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n - \"cluster_cpu is {{ cluster_cpu }}\"\n - name: Convert CPU model name\n ^ here\n"} After going through all of this, which was still good for learning, my "fix" was pretty simple. I just needed something to validate against that dictionary. I thought about trying to change the CPU value on the host, so I could get a better API return, but that may cause more issues. It was easier just to set the fact so we could move past that point in the playbook. So I used to lowest value from the list. ~~~ 115 - name: HACK - Set cluster_cpu.type 116 set_fact: 117 cluster_cpu: {'type':'Intel Nehalem Family', 'architecture':'x86_64'} 118 - name: HACK - Trace the fact we set 119 debug: 120 msg: 121 - "cluster cpu is {{ cluster_cpu }}" ~~~ [ INFO ] ["cluster_cpu is {'architecture': 'x86_64', 'type': ''}"] [ INFO ] TASK [ovirt.hosted_engine_setup : HACK - Set cluster_cpu.type] [ INFO ] ["cluster cpu is {'type': 'Intel Nehalem Family', 'architecture': 'x86_64'}"] Now the hosted engine deployment progressed and the image file is created on the NFS storage. [ INFO ] TASK [ovirt.hosted_engine_setup : Add HE disks] And now it fails here. [ FAILED ] Add HE disks "msg": "Timeout exceed while waiting on result state of the entity." The disk copies over fine, along with metadata. It's not that. When I dig into the job API I find a large queue of failed jobs: "description": "Adding unmanaged VMs running on Host ovirt-node01.home.io to Cluster Default", "status": "failed", Looks like it loops through attempting this operation until it times out. Something is still stopping that HostedEngineLocal instance from transferring over to the cluster. Tempted to look into the ovirt_disk_28.py and ovirt.py to see if I can track down why it won't transfer to the cluster. But out of time and need to get real work done instead of playing. True end result, as much as this was entertaining and educational, this ate up way too much time from the OKD work I needed to do. Was hoping to use the Install Provisions Infrastructure option with the ovirt/OKD integration. Guess it's back to UPI on a different hypervisor until I can get some newer hardware. On 9/17/2020 12:54 AM, Strahil Nikolov wrote:
It seems that this one fails :
- name: Parse server CPU list set_fact: server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}"
In cases like that I usually define a new variable.
Can you put another task before that like: - name: Debug server_cpu_dict debug: var: server_cpu_dict
Best Regards, Strahil Nikolov
В четвъртък, 17 септември 2020 г., 00:30:57 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа:
In my previous reply:
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Xeon 5130 "Woodcrest" Do you need something more specific or different?
I also found one a reply from you on an older thread and added it:
~~~ 100 - name: Debug why parsing fails 101 debug: 102 msg: 103 - "Loop is done over {{server_cpu_list.json['values']['system_option_value'][0]['value'].split(';')|list| difference(['']) }}" 104 - "Actual value of server_cpu_dict before the set_fact is {{server_cpu_dict }}" 105 - name: Parse server CPU list 106 set_fact: 107 server_cpu_dict: "{{ server_cpu_dict | combine({item.split(':')[1]: item.split(':')[3]}) }}" 108 with_items: >- 109 {{ server_cpu_list.json['values']['system_option_value'][0]['value'].split('; ')|list|difference(['']) }} 110 - debug: var=server_cpu_dict 111 - name: Convert CPU model name 112 set_fact: 113 cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}" 114 - debug: var=cluster_cpu_model ~~~
[ INFO ] ["Loop is done over ['1:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64', ' 2:Secure Intel Nehalem Family:vmx,spec_ctrl,ssbd,md_clear,model_Nehalem:Nehalem,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 3:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64', ' 4:Secure Intel Westmere Family:aes,vmx,spec_ctrl,ssbd,md_clear,model_Westmere:Westmere,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 5:Intel SandyBridge Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64', ' 6:Secure Intel SandyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_SandyBridge:SandyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 7:Intel IvyBridge Family:vmx,nx,model_IvyBridge:IvyBridge:x86_64', ' 8:Secure Intel IvyBridge Family:vmx,spec_ctrl,ssbd,md_clear,model_IvyBridge:IvyBridge,+pcid,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 9:Intel Haswell Family:vmx,nx,model_Haswell-noTSX:Haswell-noTSX:x86_64', ' 10:Secure Intel Haswell Family:vmx,spec_ctrl,ssbd,md_clear,model_Haswell-noTSX:Haswell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 11:Intel Broadwell Family:vmx,nx,model_Broadwell-noTSX:Broadwell-noTSX:x86_64', ' 12:Secure Intel Broadwell Family:vmx,spec_ctrl,ssbd,md_clear,model_Broadwell-noTSX:Broadwell-noTSX,+spec-ctrl,+ssbd,+md-clear:x86_64', ' 13:Intel Skylake Client Family:vmx,nx,model_Skylake-Client:Skylake-Client,-hle,-rtm:x86_64', ' 14:Secure Intel Skylake Client Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Client:Skylake-Client,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 15:Intel Skylake Server Family:vmx,nx,model_Skylake-Server:Skylake-Server,-hle,-rtm:x86_64', ' 16:Secure Intel Skylake Server Family:vmx,spec_ctrl,ssbd,md_clear,model_Skylake-Server:Skylake-Server,+spec-ctrl,+ssbd,+md-clear,-hle,-rtm:x86_64', ' 17:Intel Cascadelake Server Family:vmx,model_Cascadelake-Server:Cascadelake-Server,-hle,-rtm,+arch-capabilities:x86_64', ' 18:Secure Intel Cascadelake Server Family:vmx,md-clear,mds-no,model_Cascadelake-Server:Cascadelake-Server,+md-clear,+mds-no,-hle,-rtm,+tsx-ctrl,+arch-capabilities:x86_64', ' 1:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64', ' 2:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64', ' 3:AMD EPYC:svm,nx,model_EPYC:EPYC:x86_64', ' 4:Secure AMD EPYC:svm,nx,ibpb,ssbd,model_EPYC:EPYC,+ibpb,+virt-ssbd:x86_64', ' 1:IBM POWER8:powernv,model_POWER8:POWER8:ppc64', ' 2:IBM POWER9:powernv,model_POWER9:POWER9:ppc64', ' 1:IBM z114, z196:sie,model_z196-base:z196-base:s390x', ' 2:IBM zBC12, zEC12:sie,model_zEC12-base:zEC12-base:s390x', ' 3:IBM z13s, z13:sie,model_z13-base:z13-base:s390x', ' 4:IBM z14:sie,model_z14-base:z14-base:s390x']", 'Actual value of server_cpu_dict before the set_fact is {}']
[ INFO ] TASK [ovirt.hosted_engine_setup : Parse server CPU list]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name]
[ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in '/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml': line 110, column 15, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
On 9/16/2020 4:14 PM, Strahil Nikolov wrote:
You didn't mention your CPU type.
Best Regards, Strahil Nikolov
В сряда, 16 септември 2020 г., 20:44:23 Гринуич+3, Michael Blanton <mblanton@vnet.net> написа:
Wondering if there are any suggestions here before I wipe these nodes and go back to another Hypervisor.
On 9/14/2020 12:59 PM, Michael Blanton wrote:
Thanks for the quick response.
Ansible task reports them as Xeon 5130. According to Intel Ark these fall in the Woodcrest family, which is older the Nehalem.
Obviously the CPUs support virtualization. I also confirmed the required extensions from the oVirt documents.
# grep -E 'svm|vmx' /proc/cpuinfo | grep n
Question for my lab: So is this a situation where "Woodcrest" is simply not in the dictionary? Is there a way to manually add that or "force" it, just to get the engine to deploy? That way I can kick the tires on oVirt while I consider an upgrade to my lab systems. Knowing ahead of time that it is a "hack" and unsupported.
Question for product: If this is an unsupported CPU, shouldn't the installer/Hosted Engine Deployment flag that at the beginning of the process, not 45 minutes later when trying to move the already created VM to shared storage?
Thanks again
On 9/14/2020 12:45 PM, Edward Berger wrote:
What is the CPU? I'm asking because you said it was old servers, and at some point oVirt started filtering out old CPU types which were no longer supported under windows. There was also the case where if a certain bios option wasn't enabled (AES?) a westmere(supported) reported as an older model(unsupported).
On Mon, Sep 14, 2020 at 12:20 PM <mblanton@vnet.net <mailto:mblanton@vnet.net>> wrote:
I am attempting a new oVirt install. I have two nodes installed (with oVirt Node 4.4). I have NFS shared storage for the hosted engine. Both nodes are Dell quad core Xeon CPUs with 32GB of RAM. Both have been hypervisors before, XCP-NG and Proxmox. However I'm very interested to learn oVirt now.
The hosted engine deployment (through cockpit) fails during the "Finish" stage. I do see the initial files created on the NFS storage.
[ INFO ] TASK [ovirt.hosted_engine_setup : Convert CPU model name] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute ''\n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_target_hosted_engine_vm.yml':
line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
2020-09-13 17:39:56,507+0000 ERROR ansible failed { "ansible_host": "localhost", "ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml", "ansible_result": { "_ansible_no_log": false, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute '' \n\nThe error appears to be in
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/create_target_vm/01_create_targ
et_hosted_engine_vm.yml': line 105, column 16, but may\nbe elsewhere in the file depending on the exact syntax problem.\ n\nThe offending line appears to be:\n\n# - debug: var=server_cpu_dict\n ^ here\n\nThere appears to be bo th 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.\n" }, "ansible_task": "Convert CPU model name", "ansible_type": "task", "status": "FAILED", "task_duration": 1 }
I can see the host engine is created and running locally on the node. I can event SSH into the HostedEngineLocal instance.
[root@ovirt-node01]# virsh --readonly list Id Name State ----------------------------------- 1 HostedEngineLocal running
Looking at the "Convert CPU model name" task:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/tasks...
set_fact: cluster_cpu_model: "{{ server_cpu_dict[cluster_cpu.type] }}"
server_cpu_dict is good, I can find that in the logs, cluster_cpu is undefined. But this is normal correct? The Cluster CPU type is "undefined" until the first host is added to the cluster. The error makes it seems that server_cpu_dict and not cluster_cpu.type is the problem. I'm not sure this is really the problem, but that is the only undefined variable I can find.
Any advice or recommendation is appreciated -Thanks in advance _______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html <https://www.ovirt.org/privacy-policy.html> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives:
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FYI5DDI7RNVSWE...

Just to chime in here, trying a fresh hosted engine deploy today on AMD EPYC servers, the exact same error kills the deploy. So it's not you or your CPUs/servers, there's a bug in the Ansible routine that was introduced with 4.4.2 that makes hosted engine deployment impossible. I was able to deploy hosted engine on these servers using 4.4.1 without issue but hit a different (non-oVirt, rather Linux kernel) issue. As I was given a test kernel to work around that, I wanted to try deployment again so I paved the server, completely fresh install of CentOS 8.2 w/ all updates then added the kernel that fixes the bonding/bridge issue. The hosted engine deploy will reliably fail every time on that step with that error, this is a regression with 4.4.2. Regards, Mark
participants (5)
-
Edward Berger
-
Mark R
-
mblanton@vnet.net
-
Michael Blanton
-
Strahil Nikolov