[ovirt-users] Re: Bad CPU TYPE after Centos 8.3

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(a)redhat.com&gt; *À: *"Lionel Caignec" <caignec(a)cines.fr&gt; *Cc: *"thomas" <thomas(a)hoberg.net&gt;, "users" <users(a)ovirt.org&gt; *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