[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-18 Thread Mark R 
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
___
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/JWGMJ6VTRRNAFUCU4PK2RXUW3WQOUYM6/

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-17 Thread Michael Blanton 

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:s

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-16 Thread Strahil Nikolov via Users 
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 
 написа: 





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

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-16 Thread Michael Blanton 

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 
 написа:





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:

T

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-16 Thread Strahil Nikolov via Users 
You didn't mention your CPU type.

Best Regards,
Strahil Nikolov






В сряда, 16 септември 2020 г., 20:44:23 Гринуич+3, Michael Blanton 
 написа: 





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 > > 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+ 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
>>  
>>
>>    
>> 
>>  
>>
>>
>>     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"
>>     u

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-16 Thread Michael Blanton 
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 > 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+ 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 


 



    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 un

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-14 Thread Michael Blanton 

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 > 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+ 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



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-le...@ovirt.org

Privacy Statement: https://www.ovirt.org/privacy-policy.html

[ovirt-users] Re: New oVirt Install - Host Engine Deployment Fails

2020-09-14 Thread Edward Berger 
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  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+ 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   NameState
> ---
>  1HostedEngineLocal   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
>
> 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-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: