live-migration fails with two different CPU families in same availability-zone

[Drew Freiberger]

Using xenial rev 135 of nova-compute charm (nova v13.1.2) we are experiencing issues with live-migration from HP gen9 processors to pre-existing HP gen8 servers due to incompatible cpu flags.

nova-compute charm options were enable-live-migration: True, and cpu-mode and cpu-model were at charm defaults.

Worked around by setting cpu-mode: custom and cpu-model: <output of virsh cpu-baseline all_node_<cpu>_features.xml>.

Would like to recommend that if enable-live-migration is set to True in the charm, peer relations of nova-compute units on different cpu generations should override/auto-configure lowest common denominator cpu into cpu-model based on cpu features of all related nova-compute units rather than operator having to compute the cpu-model to set in charm from cpu-baseline. Perhaps this could be a new cpu-mode of "auto-custom" or the like.

The following flags exist on the newly added nova-compute units that don't appear on previously existing nova-compute units.
> 3dnowprefetch
> adx
> cqm_mbm_local
> cqm_mbm_total
> hle
> intel_pt
> rdseed
> rtm
> smap

[James Page (james-page)]

It would be nice if OpenStack could figure this out across a deployment, and do something sane.

[do3meli (d-info-e)]

I even see this behavior when live migrating instances from a HPE G9 to another HPE G9 with the same CPU model, but different CPU flags. After applying HPE SPP 2018.3 there seems to be one additional CPU flag on the upgraded G9: spec_ctrl.

I like the idea of having a "auto_custom" cpu-mode but wonder if this bug tracker is the right place. shouldn't this be more an upstream bug?