Diagnose VM Scheduling Failures
Overview
When you attempt to create or resize a VM and the Compute Service cannot find a suitable host, the VM lands in ERROR state with the fault message "No valid host was found". This is one of the most common VM creation failure modes in Private Cloud Director.
This guide walks you through diagnosing and resolving scheduling failures by checking the factors the Compute Service evaluates when placing a VM: available resources (vCPU, RAM, disk), host aggregate membership, host state, and the Placement service.
In this guide, you will identify why a VM is failing to schedule and take the corrective action needed to get it placed.
Prerequisites
Access to the Private Cloud Director UI or
pcdctlCLI.For Self-Hosted deployments: access to
kubectlagainst the region namespace (for pod log inspection).
Understand the Placement Decision
Before checking individual factors, it helps to know what the Compute Service evaluates when scheduling a VM:
Resource availability — does any host have enough free vCPU, RAM, and disk to satisfy the flavor?
Host state — is the
nova-computeservice enabled and up on the host?Host aggregate membership — if the flavor specifies aggregate metadata, does the host belong to a matching aggregate?
Image properties — does the image require specific host capabilities (for example, vTPM support)?
If any filter eliminates all hosts, scheduling fails with "No valid host was found."
Step 1: Confirm the Fault Message
Retrieve the failed VM's fault detail:
Look for the fault field. A scheduling failure typically reads:
or
Also retrieve the server events to find the request ID:
The event detail often contains more specific information about which filter rejected all hosts.
Step 2: Check Compute Service State on All Hosts
A disabled or down nova-compute service on a host makes that host ineligible for new VMs.
Review the output. For each host in your cluster, check:
state: must be
up. Adownstate means the Compute Service is not reporting to the management plane.status: must be
enabled. Adisabledstatus means the host was manually excluded from scheduling (for example, left disabled after a maintenance window).
To re-enable a disabled host:
If a host shows state: down, the Compute Service on that host is not running. See Recover libvirt and Compute Service Failures.
Step 3: Check Available Resources Against the Flavor
Determine what the VM's flavor requires:
Note the vcpus, ram (in MB), and disk (in GB) values.
Then check the aggregate resource availability across hosts:
This shows total and free vCPUs, RAM, and disk across all enabled hypervisors in the region. If free resources are below what the flavor requires, no host can accept the VM.
For per-host breakdown:
Compare the Free RAM MB, Free Disk GB, and Running VMs columns against the flavor requirements. A host is only eligible if it has enough free RAM and disk, and enough vCPU headroom.
If resources are fully consumed: either add hosts to the cluster, resize the flavor, or shut down unused VMs to free resources.
Step 4: Check Host Aggregate Membership
If the flavor includes host aggregate metadata (such as aggregate_instance_extra_specs:<key>=<value>), the VM can only schedule on hosts that belong to a matching aggregate.
Check the flavor's extra specs:
Look for properties entries starting with aggregate_instance_extra_specs:.
Then verify that at least one healthy host belongs to the required aggregate:
The hosts field lists which hosts are members. If no healthy host is a member of the aggregate the flavor targets, scheduling fails.
To add a host to an aggregate:
Navigate to Infrastructure > Host Aggregates in the Private Cloud Director UI and add the host. Alternatively, use the CLI:
See Host Aggregate for more information on configuring aggregates and flavor-level targeting.
Step 5: Check Image Properties
Certain image properties require specific host capabilities and restrict which hosts the VM can schedule on. Common examples:
hw_tpm_version = 2.0
Host must have vTPM (swtpm) installed and configured
hw:numa_nodes
Host must have multiple NUMA nodes
Aggregate isolation metadata
Host must belong to a specific aggregate
Check the image's properties:
If the image requires a capability that only some hosts have (for example, vTPM), confirm that those hosts are healthy, enabled, and have sufficient resources.
Step 6: Inspect Placement Service Logs (Self-Hosted Deployments Only)
Self-Hosted deployments only
The following steps require kubectl access to the region namespace in the management plane. In SaaS deployments, contact Platform9 Support to retrieve Placement and Compute Service logs for your region.
When the previous steps do not reveal an obvious cause, inspect the Placement service and Compute Service logs in the management plane to see exactly which filters rejected all hosts.
Check the Compute Service (nova-scheduler) Logs
Retrieve the request ID from the VM events (Step 1), then search for it in the nova-scheduler logs:
Look for lines containing FilterScheduler or the names of individual filters such as RamFilter, DiskFilter, ComputeFilter, or AggregateInstanceExtraSpecsFilter. These lines indicate which filter rejected which hosts.
Check the Placement API Logs
A GET /resource_providers call with an empty result set (zero providers returned) means the Placement service found no resource provider (host) with enough inventory to satisfy the VM's resource requirements. This confirms a resource exhaustion problem rather than a filter mismatch.
Check nova-conductor for Quota or Policy Rejections
Errors in nova-conductor may indicate tenant quota limits rather than host resource limits. Check the tenant's compute quotas:
Compare the instances, cores, and ram used versus allowed values.
Common Scenarios and Fixes
All hosts show state: down
Compute Service not running on any host
Restart pf9-ostackhost on affected hosts
Some hosts status: disabled
Left disabled after maintenance
Run pcdctl compute service enable nova-compute <HOST>
Resources show 0 free RAM/disk
Cluster fully consumed
Add hosts, or free resources by stopping unused VMs
Flavor has aggregate metadata but no host matches
Aggregate misconfiguration or host not added
Add a healthy host to the required aggregate
Image requires vTPM but no vTPM hosts available
No eligible hosts
Verify vTPM-capable hosts are in the cluster and healthy
Quota exceeded
Tenant has hit its resource quota
Raise the quota or delete unused resources
Related Pages
Last updated
Was this helpful?