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

Thursday, 17 September 2020

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?...

{
   "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...

"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...
<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...
<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(a)vnet.net&gt; написа:
> 
> 
> 
> 
> 
> 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(a)vnet.net&gt; написа:
>>
>>
>>
>>
>>
>> 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(a)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/ta...
>>>>
>>>>        
>>>>
<https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/ta...
>>>>
>>>>
>>>>        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(a)ovirt.org
<mailto:users@ovirt.org>
>>>>        To unsubscribe send an email to users-leave(a)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(a)ovirt.org
>>> To unsubscribe send an email to users-leave(a)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(a)ovirt.org
>> To unsubscribe send an email to users-leave(a)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/FYI5DDI7RNV...
>>

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

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