Open Stack

On Tue, 2020-08-18 at 17:06 +0200, Fabian Zimmermann wrote:
> Hi,
> 
> We are using the "custom"-way. But this does not protect you from all issues.
> 
> We had problems with a new cpu-generation not (jet) detected correctly
> in an libvirt-version. So libvirt failed back to the "desktop"-cpu of
> this newer generation, but didnt support/detect some features =>
> blocked live-migration.
yes that is common when using really new hardware. having previouly worked
at intel and hitting this often that one of the reason i tend to default to host-passthouh
and recommend using AZ or aggreate to segreatate the cloud for live migration.

in the case where your libvirt does not know about the new cpus your best approch is to use the
newest server cpu model that it know about and then if you really need the new fature you can try
to add theem using the config options  but that is effectivly the same as using host-passhtough
which is why i default to that as a workaround instead.

> 
>  Fabian
> 
> Am Di., 18. Aug. 2020 um 16:54 Uhr schrieb Belmiro Moreira
> <moreira.belmiro.email.lists at gmail.com>:
> > 
> > Hi,
> > 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, ...
> > 
> > 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.
> > 
> > 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).
> > 
> > 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.
> > 
> > I wonder how other operators are solving this issue.
> > I don't like stopping OS upgrades.
> > What I'm considering is to define a "custom" cpu_mode for each hardware type.
> > 
> > I would appreciate your comments and learn how you are solving this problem.
> > 
> > Belmiro
> > 
> 
>