<div dir="ltr"><div>Hi,</div><div><br></div><div>Try to choose a custom cpu_model that fits into your infra. This should be the best approach to avoid this kind of problem. If the performance is not an issue for the tenants, KVM64 should be a good election.<br></div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-size:small">Br,</div><div style="font-size:small"><a href="https://www.linkedin.com/in/luisframirez/" target="_blank">Luis Rmz</a></div><div style="font-size:small">Blockchain, DevOps & Open Source Cloud Solutions Architect</div><div style="font-size:small">----------------------------------------</div><div style="font-size:small"><font size="1">Founder & CEO </font></div><div style="font-size:small"><font size="1"><a href="http://www.opencloud.es/" style="color:rgb(17,85,204)" target="_blank">OpenCloud.es</a></font></div><div style="font-size:small"><font style="color:rgb(17,85,204)" size="1"><a href="mailto:luis.ramirez@opencloud.es" style="color:rgb(17,85,204)" target="_blank">luis.ramirez@opencloud.es</a></font></div><div><font size="1">Skype ID: d.overload</font></div><div><font size="1">Hangouts: <a href="mailto:luis.ramirez@opencloud.es" target="_blank">luis.ramirez@opencloud.es</a></font></div><div style="font-size:small"><font size="1"><img src="https://ssl.gstatic.com/mail/emoji/v7/png48/emoji_ufe4eb.png" alt="" style="margin:0px 0.2ex;vertical-align:middle;height:24px;width:24px"> +34 911 950 123 / </font><img src="https://ssl.gstatic.com/mail/emoji/v7/png48/emoji_ufe4e9.png" alt="" style="font-size:x-small;margin:0px 0.2ex;vertical-align:middle;height:24px;width:24px"><span style="font-size:x-small">+39 392 1289553 / </span><img src="https://ssl.gstatic.com/mail/emoji/v7/png48/emoji_ufe4e8.png" alt="" style="font-size:x-small;margin:0px 0.2ex;vertical-align:middle;height:24px;width:24px"><span style="font-size:x-small">+49 152 26917722 / </span><span style="font-size:x-small;color:rgb(84,84,84)">Česká republika: </span><span style="font-size:x-small">+420 774 274 882  </span></div><div style="font-size:small"><font size="1">-----------------------------------------------------<br></font></div></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 18 ago. 2020 a las 16:55, Belmiro Moreira (<<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.lists@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>
</blockquote></div>