> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/cpu-baseline-mismatch.md).

# 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 <code class="expression">space.vars.product\_acronym</code> 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:

```bash
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:

```bash
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:

```bash
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:

```bash
# 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](https://github.com/platform9/pcd-docs-gitbook/blob/main/private-cloud-director/2026.4/virtualized-clusters/troubleshooting-and-log-files/supported-cpu-models-list.md) 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.

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

Set or update the `cpu_models` value under `[libvirt]`:

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

After editing, restart the Compute Service on each host:

```bash
sudo systemctl restart pf9-ostackhost
```

See [Compute Service Advanced Configuration](/private-cloud-director/virtualized-clusters/nova-override.md#cpu-mode-and-model-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.

{% hint style="warning" %}
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](https://support.platform9.com/) or after thorough testing in a non-production environment.
{% endhint %}

### Identify Missing Flags

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

```bash
# 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:

```bash
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:

```ini
[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:

```bash
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:

```bash
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](/private-cloud-director/upgrade/host-upgrade-runbook.md) for the full pre-upgrade checklist, including the recommendation to verify CPU model consistency across the cluster before and after the upgrade.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/cpu-baseline-mismatch.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.