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
<mblan...@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
> <mblan...@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 <mblan...@vnet.net
>>> <mailto:mblan...@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/create_target_vm/01_create_target_hosted_engine_vm.yml
>>>
>>>
>>> <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-le...@ovirt.org
>>> <mailto:users-le...@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-le...@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-le...@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/FYI5DDI7RNVSWESZOS7A7HVDZBEQXI4D/
>
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/3FCZE47SSIWQ6HQA766SYAJTWHFKQGDH/
