☁️ OpenStack Error: Nova Migration Pre-Check Failed (Host, CPU, or Disk)

Exact Error Message

$ openstack server migrate --live-migration --host compute-07 vm-db-01
Unexpected API Error. (HTTP 400)
ERROR (BadRequest): Migration pre-check error: Unable to migrate
instance (a1b2c3d4) to host compute-07: Unable to migrate a1b2c3d4:
Host compute-07 is not compatible with instance CPU flags
{'vmx', 'pdpe1gb'}

Other pre-check variants you may hit:

Migration pre-check error: Unable to migrate instance: Insufficient
compute resources: Free disk (GB) 12 < requested disk (GB) 40.

ComputeHostNotFound: Compute host compute-07 could not be found.

No valid host was found. There are not enough hosts available.

What It Means

Before Nova moves an instance, nova-conductor and the destination nova-compute run a series of pre-checks: does the target host exist and is it enabled, is there enough free disk/RAM, is the CPU compatible, and is the storage model (shared vs. local) consistent between source and destination. If any check fails, Nova aborts before touching the instance and returns MigrationPreCheckError — the instance stays running untouched on its current host.

This is a good failure: nothing is half-migrated. The message names the failing dimension — CPU flags, disk, host, or “no valid host” — which points straight at the fix. The most common culprit is CPU incompatibility across heterogeneous hardware, followed by insufficient disk on the target.

Common Causes

• The destination host’s CPU lacks flags the guest was booted with (mixed hardware generations, cpu_mode = host-passthrough).
• The target host does not have enough free disk or RAM for the flavor.
• The named --host is disabled, down, or does not exist in this cell.
• Source and destination disagree on shared storage — one expects Ceph/NFS, the other local disk.
• No valid host was found because filters (aggregate, NUMA, PCI, availability zone) exclude every candidate.
• The instance uses local (non-shared) storage and you requested live migration without --block-migration.

Diagnostic Commands

Confirm the target host is up, enabled, and in the right cell:

openstack compute service list --service nova-compute --host compute-07
openstack hypervisor show compute-07 -c free_disk_gb -c free_ram_mb -c vcpus_used

Inspect the instance’s flavor and host so you know what the target must satisfy:

openstack server show vm-db-01 -c flavor -c 'OS-EXT-SRV-ATTR:host'

Compare CPU capabilities between source and destination (host-passthrough migrations fail on any missing flag):

ssh compute-07 "virsh capabilities" | grep -A2 '<cpu>'

Read the conductor/compute log for the precise pre-check that failed:

journalctl -u nova-conductor -u nova-compute --since "15 min ago" \
  | grep -i 'pre-check\|PreCheck\|No valid host'

Step-by-Step Resolution

1. Read the error to classify it: CPU flags, disk/RAM, host-not-found, or “no valid host”. Each has a distinct fix.

2. For a CPU-flags mismatch, stop pinning a single host and let the scheduler pick a compatible one, or set a compatible baseline CPU model so guests are portable across your hardware:

# Let the scheduler choose a compatible destination
openstack server migrate --live-migration vm-db-01

For long-term fixes, set cpu_mode = custom with a common cpu_models baseline in nova.conf on all computes so instances stop carrying host-specific flags.

3. For insufficient disk/RAM, either pick a host with capacity or free space on the target. Verify capacity first:

openstack hypervisor list -c 'Hypervisor Hostname' -c 'Free Disk GB' -c 'Free RAM MB'

4. For local (non-shared) storage, request block migration so Nova copies the disk:

openstack server migrate --live-migration --block-migration vm-db-01

5. For “no valid host”, relax the constraint that excludes candidates — check aggregate metadata, availability zone, and NUMA/PCI requirements:

openstack aggregate list
openstack availability zone list --compute

6. Re-run the migration without --host so the scheduler applies all filters and lands the instance on a truly valid target, then confirm:

openstack server migrate --live-migration vm-db-01
openstack server show vm-db-01 -c status -c 'OS-EXT-SRV-ATTR:host'

Prevention

• Standardize CPU handling: use cpu_mode = custom with a shared cpu_models baseline so guests migrate cleanly across mixed hardware generations.
• Group compatible hardware into host aggregates and migrate within an aggregate rather than across incompatible ones.
• Keep disk/RAM headroom on compute hosts and alert before free capacity drops below a typical flavor size.
• Prefer letting the scheduler choose the destination over pinning --host, so filters do the compatibility work.
• Be explicit about storage: use --block-migration for local disks and shared storage everywhere else, and keep the model consistent per aggregate.

Related Errors

• No valid host was found. There are not enough hosts available — the scheduler-side variant when every host is filtered out.
• ComputeHostNotFound: Compute host ... could not be found — a wrong or down --host target.
• Insufficient compute resources: Free disk (GB) ... < requested — the capacity variant of the pre-check.
• InvalidSharedStorage / Block migration can not be used with shared storage — the storage-model mismatch.

Frequently Asked Questions

Does a pre-check failure harm my running instance? No. Pre-checks run before Nova touches the instance, so a MigrationPreCheckError leaves the guest running untouched on its original host.

Why does the CPU-flags error keep appearing on newer hardware? With cpu_mode = host-passthrough, guests inherit the source host’s exact CPU flags; a destination with a different (often older) CPU lacks some of them. Switching to a custom CPU baseline shared across hosts fixes portability.

Should I pin the destination with —host? Usually not. Pinning bypasses the scheduler’s compatibility filters, so a manually chosen host frequently fails a pre-check. Omit --host and let the scheduler find a valid target.

How do I migrate an instance on local disk? Add --block-migration so Nova copies the disk during live migration; without it, live migration assumes shared storage and the pre-check fails.

Where can I find more Nova troubleshooting? See the full OpenStack guides for migration, scheduling, and Placement fixes, and pull a ready-made diagnostic prompt from the prompt library.