<div dir="ltr"><div dir="ltr"><div>Hi,</div><div>in our infrastructure we have always compute nodes that need a hardware intervention and as a consequence they are rebooted, bringing a new kernel, kvm, ...</div><div><br></div><div>In order to have a good compromise between performance and flexibility (live migration) we have been using "host-model" for the "cpu_mode" configuration of our service VMs. We didn't expect to have CPU compatibility issues because we have the same hardware type per cell.</div><div><br></div><div>The problem is that when a compute node is rebooted the instance domain is recreated with the new cpu features that were introduced because of the reboot (using centOS).</div><div><br></div><div>If there are new CPU features exposed, this basically blocks live migration to all the non rebooted compute nodes (those cpu features are not exposed, yet). The nova-scheduler doesn't know about them when scheduling the live migration destination.</div><div><br></div><div>I wonder how other operators are solving this issue. </div><div>I don't like stopping OS upgrades. </div><div>What I'm considering is to define a "custom" cpu_mode for each hardware type.</div><div><br></div><div>I would appreciate your comments and learn how you are solving this problem.</div><div><br></div><div>Belmiro</div><div><br></div></div></div>