Diagnosing OpenStack Nova CPU Pinning Launch Failures

When an OpenStack instance fails to launch with a "No resources available" error despite having idle CPUs, the culprit is often a mismatch between Nova's scheduling requirements and the physical hardware's capabilities. CPU pinning—the process of mapping virtual CPUs to specific physical cores—is used to eliminate noisy neighbor effects, but if the configuration does not align perfectly with the host's topology, the nova-compute service will reject the request entirely.

This guide helps you identify why Nova is failing to pin CPUs and provides the necessary steps to reconfigure your compute nodes for high-performance workloads.

Common Root Causes

Before diving into configuration files, identify the likely cause based on the symptoms observed in your environment:

Symptom	Likely Cause
"No resources available" during boot.	cpu_pin_set is missing or mismatched in nova.conf.
Instance starts but performance is jittery.	cpu_allocation_ratio is too high for pinned workloads.
Nova-compute fails to restart or logs permission errors.	Cgroup hierarchy is not mounted or accessible.
Scheduler finds no host with compatible PCIUs.	Hypervisor (KVM) does not report pinning capabilities.

Diagnostic Workflow

Follow these checks on the specific compute node where the launch failure occurred.

1. Verify Hypervisor Capabilities

The underlying hypervisor (usually KVM) must support CPU de-segmentation. Run the following command on the host OS:

virsh capabilities | grep -A 5 cpu

Look for the <pin> tag. If this is missing, the kernel or hardware does not support pinning, and you cannot use this feature.

2. Audit Physical Topology vs. Configuration

Nova needs to know exactly which cores are available for pinning. First, check your physical core count:

grep -c processor /proc/cpuinfo # or lscpu

Then, inspect the Nova configuration file located at /etc/nova/nova.conf. You are looking for the [compute] section:

[compute]
# Example: Pinning cores 0 through 7
cpu_pin_set = 0,1,2,3,4,5,6,7
cpu_scheduler_policy = dedicated

Crucial Check: The cpu_pin_set must exist within the range of the host's physical CPUs. If you define 0-15 but the host only has 8 cores, the scheduler will fail to place instances on this host.

3. Check Cgroup Alignment

CPU pinning relies on Linux cgroups to isolate processes. Ensure the CPU cgroup controller is mounted:

mount | grep /sys/fs/cgroup/cpu

If no output is returned, nova-compute cannot reserve cores. You may need to mount the cgroup system via fstab or systemd units.

4. Validate Allocation Ratios

By default, cpu_allocation_ratio allows multiple vCPUs to share one pCPU. However, for pinned instances, this ratio should generally be set to 1.0 to prevent overcommitment of the pinned resources:

[compute]
cpu_allocation_ratio = 1.0

Remediation and Fix

Based on your findings above, apply the following fixes:

Scenario: cpu_pin_set Mismatch

Edit /etc/nova/nova.conf on the compute node. Ensure the set matches your available hardware. If you have 16 cores and want to reserve the first 8 for pinned instances, use:

sudo nano /etc/nova/nova.conf
# Update or add the line under [compute]
cpu_pin_set = 0,1,2,3,4,5,6,7

Restart the service to apply changes:

sudo systemctl restart nova-compute

Scenario: Cgroup Permission Errors

If logs show Permission denied when accessing cgroups, ensure the nova user has ownership of the relevant cgroup paths:

sudo chown -R nova:nova /sys/fs/cgroup/cpu

Verification
After applying fixes, attempt to launch an instance with a flavor that requires dedicated CPUs. Track the process via the OpenStack CLI:
openstack server create --image <IMAGE> --flavor <FLAVOR> test-instance
Monitor the logs in real-time to verify the mapping:
tail -f /var/log/nova/nova-compute.log | grep "pinning"
If successful, you will see "Allocation started" followed by the specific CPU IDs assigned to the instance.

Limitations and Cautions

  
Resource Fragmentation: Pinning CPUs makes those cores unavailable for non-pinned instances, which can lead to lower overall host utilization if the pinned instances are underutilized.
  
Hardware Affinity: Avoid using pinning on hosts with NUMA nodes unless you also configure numa_topology_policy, otherwise, you may inadvertently cross NUMA boundaries, degrading performance.
  
State Change Risk: Incorrect cgroup configurations can cause the nova-compute service to crash repeatedly in a boot loop.