Hi Lionel,

if you managed to remove the host (or move it to a different cluster) so that all hosts in your cluster are UP - you could try to put one of your running hosts to the maintenance and then back to active - the cluster settings should be updated on the host activation. You can look for the log "Updating cluster CPU flags and verb according to the configuration of the [cluster name]".

If that does not help, you can try to restart the engine.

Please let me know if that helps.

Lucia

On Tue, Dec 15, 2020 at 12:53 PM Lionel Caignec <caignec@cines.fr> wrote:

Thank you i understand now.

I double checked all my 8.2 host about cababilities and they seems ok.

I think i foudn the source of this "bug".

For this time i've updated one host in 8.3 (the non operative one), and then i update engine and run engine-setup (with all host up and activated except the 8.3 one). Maybe this is why the cluster table is not updated?

What do you think, if y remove the 8.3 host, rerun "engine-setup" an re-add the 8.3 host?

Lionel.

De: "Lucia Jelinkova" <ljelinko@redhat.com>
À: "Lionel Caignec" <caignec@cines.fr>
Cc: "thomas" <thomas@hoberg.net>, "users" <users@ovirt.org>
Envoyé: Mardi 15 Décembre 2020 11:31:47
Objet: Re: [ovirt-users] Re: Bad CPU TYPE after Centos 8.3

Hi Lionel,

in oVirt 4.4.2 the Secure Intel Cascadelake Server Family was configured to use the Cascadelake-Server libvirt/qemu CPU. In oVirt 4.4.3, this has been changed to Cascadelake-Server-noTSX libvirt/qemu CPU (since the TSX was dropped in 8.3).

The problem you're facing is caused by this transition. In the cluster table you can see that the running hosts still use the old configuration - Cascadelake-Server. That is why the new 8.3 host is non operative.

Now the question is why the configuration in the cluster table was not updated. This should be the correct workflow:
1. engine update from 4.4.2 to 4.4.3
2. during engine-setup, the configuration values should be updated in the vdc_table in the database
3. during engine startup, the cluster value should be updated IF all hosts are UP AND all hosts comply to the new configuration

Could anything from the below cause the configuration in the cluster table not to be updated?
a) engine-setup was not performed
b) not all hosts in the cluster were UP
c) some of the 8.2 hosts do not support the Cascadelake-Server-noTSX (I can see that the 8.2 you've checked does support it, maybe it would be worth checking the others as well).

Based on your answer we can try a workaround in the Webadmin before changing the kernel values.

Regards,

Lucia