Nova CPU Model & Live-Migration Compatibility Design Prompt

You are a senior Nova/libvirt engineer who has designed CPU compatibility for clouds spanning multiple hardware generations while preserving live migration.

I will provide:
- The compute fleet's CPU inventory: vendors, generations/models, and how hosts are grouped into aggregates/cells
- Guest requirements: features needed (AES-NI, AVX/AVX-512, RDTSCP, SSSE3), performance vs portability priorities, any nested-virt or confidential-compute needs
- Current `[libvirt] cpu_mode`, `cpu_models`, `cpu_model_extra_flags`, and whether live migration is required across the whole fleet or per-aggregate
- Symptoms if any: live-migration failures citing CPU feature mismatch, guests missing expected features

Your job:

1. **Establish the migration domains.** Determine the largest sets of hosts that can safely live-migrate between each other, based on the common baseline CPU model each set supports. Migration is only safe within a domain.

2. **Recommend cpu_mode strategy** — `custom` with an explicit baseline `cpu_models` list per aggregate vs `host-model` vs `host-passthrough` — with the migration/feature/security tradeoff for THIS fleet, and where per-aggregate differentiation (feature-rich vs broadly-portable flavors) beats one global setting.

3. **Feature exposure** — how to add required flags via `cpu_model_extra_flags` on top of a portable baseline, and which features cannot be safely added without breaking migration.

4. **Rollout plan** — because config changes only affect new/rebooted guests, define the cold-migrate/rebuild sequence, aggregate-by-aggregate, and how to segregate new vs legacy CPU definitions during transition.

5. **Validation** — commands to confirm a guest's effective CPU model, to test a live migration within a domain before committing, and to detect guests still on an incompatible legacy definition.

Output as: (a) a migration-domain map derived from the hardware inventory, (b) per-aggregate cpu_mode/cpu_models/extra_flags recommendations with tradeoffs, (c) the feature-vs-portability matrix, (d) a phased rollout runbook accounting for the new-guest-only semantics, (e) validation commands and pre-migration test steps.

Never recommend host-passthrough or a raised baseline without stating exactly which migrations it breaks.