> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/diagnose-vm-scheduling-failures.md).

# 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 <code class="expression">space.vars.product\_name</code>.

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 <code class="expression">space.vars.product\_name</code> UI or `pcdctl` CLI.
* For Self-Hosted deployments: access to `kubectl` against 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:

1. **Resource availability** — does any host have enough free vCPU, RAM, and disk to satisfy the flavor?
2. **Host state** — is the `nova-compute` service enabled and up on the host?
3. **Host aggregate membership** — if the flavor specifies aggregate metadata, does the host belong to a matching aggregate?
4. **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:

```bash
pcdctl server show <VM_UUID>
```

Look for the `fault` field. A scheduling failure typically reads:

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

or

```
No valid host was found. Exceeded max scheduling attempts...
```

Also retrieve the server events to find the request ID:

```bash
pcdctl server event list <VM_UUID>
pcdctl server event show <VM_UUID> <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.

```bash
pcdctl compute service list
```

Review the output. For each host in your cluster, check:

* **state**: must be `up`. A `down` state means the Compute Service is not reporting to the management plane.
* **status**: must be `enabled`. A `disabled` status means the host was manually excluded from scheduling (for example, left disabled after a maintenance window).

**To re-enable a disabled host:**

```bash
pcdctl compute service enable nova-compute <HOST_FQDN>
```

If a host shows `state: down`, the Compute Service on that host is not running. See [Recover libvirt and Compute Service Failures](/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/recover-libvirt-and-compute-service.md).

## Step 3: Check Available Resources Against the Flavor

Determine what the VM's flavor requires:

```bash
pcdctl flavor show <FLAVOR_NAME_OR_ID>
```

Note the `vcpus`, `ram` (in MB), and `disk` (in GB) values.

Then check the aggregate resource availability across hosts:

```bash
pcdctl hypervisor stats show
```

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:

```bash
pcdctl hypervisor list --long
```

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:

```bash
pcdctl flavor show <FLAVOR_NAME_OR_ID>
```

Look for `properties` entries starting with `aggregate_instance_extra_specs:`.

Then verify that at least one healthy host belongs to the required aggregate:

```bash
pcdctl aggregate list
pcdctl aggregate show <AGGREGATE_NAME>
```

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 <code class="expression">space.vars.product\_name</code> UI and add the host. Alternatively, use the CLI:

```bash
pcdctl aggregate add host <AGGREGATE_NAME> <HOST_FQDN>
```

See [Host Aggregate](/private-cloud-director/virtualized-clusters/host-aggregate.md) 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:

| Image property               | Requirement                                            |
| ---------------------------- | ------------------------------------------------------ |
| `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:

```bash
pcdctl image show <IMAGE_ID>
```

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)

{% hint style="info" %}
**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.
{% endhint %}

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:

```bash
kubectl logs deployment/nova-scheduler -n <WORKLOAD_REGION> | grep <REQUEST_ID>
```

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

```bash
kubectl logs deployment/placement-api -n <WORKLOAD_REGION> | grep <REQUEST_ID>
```

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

```bash
kubectl logs deployment/nova-conductor -n <WORKLOAD_REGION> | grep <REQUEST_ID>
```

Errors in `nova-conductor` may indicate tenant quota limits rather than host resource limits. Check the tenant's compute quotas:

```bash
pcdctl quota show --project <PROJECT_ID>
```

Compare the `instances`, `cores`, and `ram` used versus allowed values.

## Common Scenarios and Fixes

| Symptom                                           | Likely cause                                 | Fix                                                      |
| ------------------------------------------------- | -------------------------------------------- | -------------------------------------------------------- |
| 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

* [VM Flavors](/private-cloud-director/virtualized-clusters/virtualmachine/vm-flavors.md)
* [Host Aggregate](/private-cloud-director/virtualized-clusters/host-aggregate.md)
* [Advanced Scheduling Options](/private-cloud-director/virtualized-clusters/virtualmachine/advance-vm-scheduling-options.md)
* [Failed to Deploy Virtual Machine](/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/failed-to-deploy-virtual-machine.md)
* [Recover libvirt and Compute Service Failures](/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/recover-libvirt-and-compute-service.md)
* [Virtual TPM](/private-cloud-director/virtualized-clusters/virtual-tpm.md)
* [Tenant Quotas, User Quotas and VM Leases](/private-cloud-director/identity-and-multi-tenancy/tenant-quotas-user-quotas-and-vm-leases.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/virtualized-clusters/troubleshooting-and-log-files/diagnose-vm-scheduling-failures.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.