Resolve CPU Baseline Mismatch After Host Upgrade

Overview

All hypervisor hosts in a virtualized cluster must expose the same CPU model to their VMs. The Compute Service selects the cluster's CPU baseline automatically when each host is first authorized, picking the newest approved model that every host in the cluster can report as usable. When a host is upgraded — especially when moving from one CPU generation to another, or when the libvirt version changes — the set of flags the host can advertise may change. If the upgraded host can no longer satisfy the flags required by the cluster's established CPU baseline, libvirt rejects the host and the Compute Service reports an error.

Common symptoms of a CPU baseline mismatch:

• A host that completed a PCD agent upgrade transitions to error or offline status even though the host itself is reachable.

• /var/log/pf9/hostagent.log or /var/log/pf9/ostackhost.log contains an error similar to CPU model <model> is not supported on this host or unsupported configuration: CPU flag <flag> not found.

• VM live migrations or DRR rebalancing fail with CPU compatibility errors after adding a new-generation host to a cluster that previously had uniform CPU hardware.

In this guide, you will identify the mismatch, choose a compatible baseline, and use cpu_model_extra_flags if needed to bridge the gap for a mixed-generation cluster.

Step 1: Confirm the Cluster's Current CPU Baseline

Check the configured CPU model on one of the existing, healthy hosts:

grep -A 5 '\[libvirt\]' /opt/pf9/etc/nova/conf.d/nova_override.conf

Look for the cpu_models value. For example:

[libvirt]
cpu_models = Cascadelake-Server-noTSX

If cpu_models is not set in nova_override.conf, the Compute Service is using the auto-selected value. To see what model is actually in use, check the running configuration:

sudo grep -r "cpu_models" /opt/pf9/etc/nova/

Step 2: Check What the Upgraded Host Reports as Usable

On the upgraded or newly added host, run:

virsh domcapabilities | grep "model usable='yes'" | sort

Compare the output against the cluster's current cpu_models value from Step 1. If the current baseline model does not appear in the output of this command, libvirt on this host cannot support that model and will reject the host.

Step 3: Choose a New Common Baseline (If Required)

Run the usable-model command on every host in the cluster:

# Run on each host
virsh domcapabilities | grep "model usable='yes'" | sort > /tmp/usable-models-$(hostname).txt

Find the intersection — the most recent model that appears as usable across all hosts. Use the Supported CPU Models list to confirm the model is approved.

If you need to lower the cluster baseline to accommodate a host with a less capable CPU (for example, an older CPU generation added to a cluster running on newer hardware), choose the newest model that all hosts can support.

Step 4: Apply the New Baseline to All Hosts

Edit nova_override.conf on each hypervisor host in the cluster. The file must be updated on every host for the change to take effect consistently. Perform this change during a maintenance window, as each host's Compute Service must be restarted.

sudo vi /opt/pf9/etc/nova/conf.d/nova_override.conf

Set or update the cpu_models value under [libvirt]:

[libvirt]
cpu_models = <new-common-model>

After editing, restart the Compute Service on each host:

sudo systemctl restart pf9-ostackhost

See Compute Service Advanced Configuration for the full configuration reference.

Use cpu_model_extra_flags for Mixed-Generation Clusters

In some clusters, hosts from different CPU generations can support the same named model but differ in the specific flags they expose. libvirt may reject a host whose CPU is missing flags that the cluster baseline requires — even if the host reports the model itself as usable. This is common when mixing Intel CPU generations within the same cluster.

cpu_model_extra_flags is a Compute Service configuration option that explicitly adds or removes CPU feature flags from the model advertised to VMs. It lets you tailor the baseline to the lowest common denominator of flags present across all hosts, so that every host can pass libvirt's CPU compatibility check.

Modifying cpu_model_extra_flags affects the CPU feature set visible to all VMs on that host. Adding flags that the physical CPU does not support will cause VM launch failures. Removing flags may reduce VM performance or break workloads that require those flags. Make this change under guidance from Platform9 Support or after thorough testing in a non-production environment.

Identify Missing Flags

To see which flags the cluster baseline requires but the host is missing, run on the affected host:

# Get the flags the baseline model expects
cat /usr/share/libvirt/cpu_map/x86_<model-name>.xml | grep 'feature name'

# Get the flags the host actually reports as available
virsh domcapabilities | grep -A 200 '<model usable=.yes.><model-name>' | head -50

Alternatively, the Compute Service log on a failing host shows exactly which flag is missing:

grep -i "cpu flag\|unsupported.*cpu\|cpu.*not found" /var/log/pf9/ostackhost.log | tail -20

Configure cpu_model_extra_flags

Edit nova_override.conf on the hosts that are missing the flags. Use a minus prefix to remove a flag or a plus prefix (or no prefix) to add one:

[libvirt]
cpu_models = Cascadelake-Server-noTSX
cpu_model_extra_flags = -pcid,-ssbd

In this example, the flags pcid and ssbd are removed from the advertised CPU model on this host, bringing it in line with what the cluster's older-generation hosts can offer.

After editing, restart the Compute Service:

sudo systemctl restart pf9-ostackhost

Repeat on every host where the same flag adjustment is needed to ensure the cluster baseline is consistent.

Verify the Adjusted Model

After restarting, confirm the Compute Service picks up the change:

sudo grep -A 10 '\[libvirt\]' /opt/pf9/etc/nova/conf.d/nova_override.conf
sudo systemctl status pf9-ostackhost

If the host returns to applied status in the UI, the CPU model is now accepted.

Cross-Reference: Host Upgrades and CPU Baseline

When planning a host upgrade, check the CPU baseline compatibility before starting. A host OS upgrade (Ubuntu 22.04 to 24.04) can change the libvirt version and with it the set of flags reported as usable. Review the Host Upgrade Runbook for the full pre-upgrade checklist, including the recommendation to verify CPU model consistency across the cluster before and after the upgrade.