Latest response

Hi all

Going through the first guided exercise in chapter 3 of the RH318 course, my RHEV-H node is in a 'non-operational state'. The text says:

'If the RHEV-H host enters a Non-Operational state, reboot the RHEV-H host and check its BIOS settings. Make sure that “Execute Disable Memory Protection Technology” is enabled.'

How do I do this?



Hi Colin,

I assume you are using the virtual labs provided, not sure why i would be prompting you to change things in the BIOS. Those instructions might be to allow for those who are using their own bare-metal systems.

Can you see the specific error messages in the event log, or on rhev-m? (/var/log/ovirt-engine/engine.log). There's a number of reasons why a new host might go non-operational, so could be something else.

Hi Marcus

Yep, using the ROL labs.

Under events, I see “Host servera.pod1.example.com moved to Non-operational state as host CPU type is not supported in this cluster compatibility version or is not supported at all”. In the RHEV gui Cluster CPU architecture is undefined.

Going to servera’s console, I see it is an “AuthenticAMD” Athlon (by running “cat /proc/cpuinfo”)"

When I get a chance I'll have a look at the engine.log


Not sure how to copy engine.log from the lab VM. I can't copy/paste to my PC, can't get to gmail or pastebin.

Messsage in engine.log saying "nonoperational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER

Googling that error message finds https://access.redhat.com/solutions/1234703.

Double checked the output of "cat /proc/cpuinfo" and the 'nx' flag is showing so maybe https://access.redhat.com/solutions/1234703 is not the cause in my case.

I'll try deleting the lab and re-provisioning and see what happens.

Hi Colin, what 'CPU type' did you select for your cluster? Try selecting the most basic AMD one first (Opteron G1)

You can check the flags (provided by /proc/cpuinfo) required for each 'CPU type' in the solution here: https://access.redhat.com/solutions/634853 (bottom of the page)

The drop down list for selecting the CPU type is empty.

Hi Colin, can you show the output of the following DB query: On rhev-m run (assuming this is 3.5)

 su - postgres
 psql engine
 engine=# select * from vdc_options where option_name = 'ServerCPUList' and version = '3.5';

I've heard of an issue where, if the CPU information in the DB is not correct, the gui simply refuses to display anything at all. Info from my working environment: (one line)

3:Intel Conroe Family:vmx,nx,model_Conroe:Conroe:x86_64; 4:Intel Penryn Family:vmx,nx,model_Penryn:Penryn:x86_64; 5:Intel Nehalem Family:vmx,nx,model_Nehalem:Nehalem:x86_64; 6:Intel Westmere Family:aes,vmx,nx,model_Westmere:Westmere:x86_64; 7:Intel SandyBridge  Family:vmx,nx,model_SandyBridge:SandyBridge:x86_64; 8:Intel Haswell Family:vmx,nx,model_Haswell:Haswell:x86_64; 2:AMD Opteron G1:svm,nx,model_Opteron_G1:Opteron_G1:x86_64; 3:AMD Opteron G2:svm,nx,model_Opteron_G2:Opteron_G2:x86_64; 4:AMD Opteron G3:svm,nx,model_Opteron_G3:Opteron_G3:x86_64; 5:AMD Opteron G4:svm,nx,model_Opteron_G4:Opteron_G4:x86_64; 6:AMD Opteron G5:svm,nx,model_Opteron_G5:Opteron_G5:x86_64; 3:IBM POWER 8:powernv,model_power8:power8:ppc64;

Since this is a test environment that can easily be reset, you can try updating with this string, restart ovirt-engine, and see if it helps. Either way, it seems like a bug with the environment rather than something you are doing wrong (screenshot of the gui and the above db query will help)

Well, I deleted the lab and re-provisioned it and this time the host is up. Obviously I did something wrong last time.