☁️ OpenStack Error: 'Flavor ... could not be found' Launching an Instance

Exact Error Message

$ openstack server create --flavor m1.medium --image ubuntu-22.04 \
    --network private web-01
No flavor with a name or ID of 'm1.medium' exists.

When a stored flavor reference is bad (for example in a Heat stack or automation), Nova returns the API-level 404 instead:

Flavor 7 could not be found. (HTTP 404) (Request-ID: req-4d8a1c2f-6b3e-4a9d-8c1f-2e0b3a4c5d6e)

What It Means

A flavor is Nova’s named template for an instance’s vCPUs, RAM, and root/ephemeral disk. When you boot a server you must reference an existing flavor by name or ID, and Nova looks it up before scheduling. If no flavor matches the name or ID you supplied — because it was deleted, renamed, or is not visible to your project — Nova cannot size the instance and fails with a 404.

The client-side message (“No flavor with a name or ID of …”) comes from the CLI resolving the name; the Flavor N could not be found (HTTP 404) variant comes from the compute API when an ID is passed straight through.

Common Causes

• The flavor was deleted by an operator (deleting a flavor does not affect running instances but breaks new boots referencing it).
• A typo, or using a name that differs from the actual flavor (m1.med vs m1.medium).
• Passing a numeric ID that no longer exists, or confusing the integer ID with the UUID.
• The flavor is private and your project lacks flavor access.
• Region mismatch: the flavor exists in one region but you are targeting another.
• Automation (Heat/Terraform) hard-codes a flavor ID that was recreated with a new ID.

Diagnostic Commands

List every flavor visible to you and confirm the exact name/ID:

openstack flavor list

Look up the specific flavor to see whether it exists at all:

openstack flavor show m1.medium

Include private flavors and check access (admin):

openstack flavor list --all
openstack flavor show m1.medium -c access_project_ids

Confirm you are pointed at the right region/endpoint:

openstack --os-region-name RegionOne flavor list
openstack endpoint list --service compute

Check the Nova API log for the lookup failure:

sudo journalctl -u devstack@n-api --no-pager | grep -i "flavor.*could not be found"
# package installs: /var/log/nova/nova-api.log

Step-by-Step Resolution

1. List flavors and verify the precise spelling and ID. Names are case-sensitive and must match exactly:

openstack flavor list -c ID -c Name

2. If the flavor simply does not exist, recreate it with the required specs (use --id auto unless a fixed ID is needed for legacy references):

openstack flavor create --id auto --ram 4096 --vcpus 2 --disk 40 m1.medium

3. If the flavor is private, grant your project access rather than making it public:

openstack flavor set --project my-project m1.medium

4. If automation references a stale numeric ID, update it to reference the flavor by name instead, which survives recreation:

openstack server create --flavor m1.medium --image ubuntu-22.04 \
  --network private web-01

5. If you are in the wrong region, re-run with the correct --os-region-name (or fix OS_REGION_NAME in your RC file).

6. Retry the boot and confirm the instance reaches ACTIVE:

openstack server create --flavor m1.medium --image ubuntu-22.04 \
  --network private web-01 --wait
openstack server show web-01 -c status

Prevention

• Reference flavors by stable name in automation, not by numeric ID, so a recreated flavor does not break stacks.
• Treat flavor deletion as a breaking change; audit for references before removing a flavor from a shared cloud.
• Keep a documented, version-controlled set of standard flavors so recreation is deterministic.
• For private flavors, manage project access explicitly and review it when onboarding projects.
• Validate flavor existence in CI before applying Heat/Terraform that boots instances.

Related Errors

• No valid host was found. There are not enough hosts available. — the flavor exists but no host can satisfy it (a scheduling failure, not a lookup failure).
• Image ... could not be found (HTTP 404) — the analogous 404 for a missing/inaccessible image.
• Flavor's disk is too small for requested image — flavor found, but its root disk is smaller than the image.
• Forbidden (HTTP 403) on flavor show — the flavor is private and access is denied.

Frequently Asked Questions

Does deleting a flavor break running instances? No. Instances that already booted keep running, but any new boot (or a rebuild) that references the deleted flavor fails with 404. Recreate the flavor to restore new launches.

Why does the flavor show in the dashboard but not for my user? It is likely a private flavor scoped to specific projects. Ask an admin to add your project with openstack flavor set --project <project> <flavor>.

Should I reference flavors by name or ID? Prefer name in automation. Numeric IDs change when a flavor is recreated, whereas a consistent name is more stable and readable.

How do I recreate a flavor with the same ID a stack expects? Pass --id <n> to openstack flavor create instead of --id auto so the legacy numeric reference resolves again. For flavor-planning prompts, see the OpenStack prompts.

Could this be a region problem? Yes. Flavors are region-scoped, so a flavor present in RegionOne may be absent in another region. Confirm OS_REGION_NAME and your compute endpoint. For more compute guides, see the OpenStack guides.