OpenStack architecture: compute scheduling, network ports and storage dependencies
Trace an OpenStack instance request across identity, Nova scheduling, Placement, Neutron and storage. Separate accepted API requests, boot completion and usable guest connectivity.
TL;DR: Creating an OpenStack instance coordinates several services with separate state and failure modes. Follow the request and resource identifiers across those services; a successful API response or an ACTIVE server status cannot establish that the guest application is reachable.
Name the resource each service owns
Keystone supplies identity and scoped authorization context. Nova coordinates compute instances, while Placement tracks resource-provider inventory and allocations used in scheduling. Glance supplies image metadata and access to image data. Neutron owns network resources such as ports, and Cinder owns persistent block volumes. The OpenStack service overview defines these responsibilities.
These are logical services, not a promise that each runs on one dedicated machine. A deployment may distribute API workers, message queues, databases and compute agents across many hosts. Record the actual release and architecture before drawing a recovery plan from a generic diagram.
| Resource or symptom | Relevant owner | Useful distinction |
|---|---|---|
| Instance request and task state | Nova | Accepted request versus completed operation |
| Eligible compute capacity | Placement and Nova scheduler | Aggregate free capacity versus matching candidates |
| Port binding and address | Neutron and its deployed backend | Allocated IP versus working packet path |
| Boot image or attached volume | Glance or Cinder | Resource existence versus successful retrieval or attachment |
Capacity must satisfy the whole request
Placement records resource classes, inventories, usage and traits. A trait describes a property of a provider; it is not itself a consumable quantity. The Placement overview explains this distinction.
Imagine a request needing eight vCPUs and a particular CPU trait. The cloud has twenty idle vCPUs in total, but the two hosts with the required trait each have only four available. The aggregate dashboard looks comfortable while the request still has no eligible home. Quotas, disabled services, host constraints and scheduler filters can narrow the candidate set further.
Treat that example as a constraint problem. Removing the trait might permit scheduling but violate the workload's instruction-set requirement. Increasing quota would not create a matching host. Preserve the fault and request ID, inspect the actual constraints, then change the relevant capacity or requirement with the workload owner.
The branches represent dependencies to inspect, not a universal ordering of every RPC. Backend drivers and boot source change the detailed execution path.
ACTIVE is a compute observation
Suppose the guest reaches ACTIVE and its console shows a login prompt, but SSH from a permitted bastion times out. Stop reissuing the server-create request. A second instance can create additional allocations while preserving the original network defect.
Inspect the Neutron port's fixed IP, binding information and attached network. Then follow the intended route, security rules and guest configuration. An address assigned by the control plane does not prove DHCP delivery, guest interface configuration or return routing. Backend-specific agents and OVN components differ; do not assume that every cloud exposes the same troubleshooting daemon.
Use read-only CLI queries in an authorized project. The IDs below are placeholders obtained from the actual failed request:
openstack server show SERVER_ID
openstack server event list SERVER_ID
openstack port list --server SERVER_ID
openstack port show PORT_ID
openstack volume show VOLUME_ID
The volume query applies only when a volume is involved. Fields and event visibility depend on the cloud's policy and API version. The official server commands describe available operations; do not infer permission from a command being documented.
Persistence belongs to the selected storage lifecycle
An image-backed root disk and a Cinder volume have different ownership and deletion rules. Nova's architecture guide separates Nova-provisioned storage from persistent Cinder resources. For a boot-from-volume instance, inspect the block-device mapping and delete-on-termination choice before assuming that deleting the server preserves or removes the data.
A snapshot is also a scoped operation. Establish whether it captures a particular disk or application-consistent state, and rehearse recovery with the required identity and network dependencies. “The instance is backed up” leaves too many resources unspecified.
Self-check: an instance-create attempt fails before guest boot, and a volume remains allocated. Should the cleanup remove every unattached volume in the project? No. Correlate the volume with this request, verify whether another operation owns it, and follow a bounded cleanup procedure. Shared-project inventory is not a safe substitute for ownership evidence.