VM Deployment Failed Due to Insufficient Storage
Problem
VM deployment using Ephemeral storage fails with "No valid host was found" on ostackhost logs, and "insufficient resources or a temporary occurrence as compute nodes start up" error in Nova-scheduler logs.
INFO nova.scheduler.manager [None [Req-UUID] [Project-ID] [User-ID] - - default default] Got no allocation candidates from the Placement API. This could be due to insufficient resources or a temporary occurrence as compute nodes start up.Environment
- Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher
- Self-Hosted Private Cloud Director Kubernetes - v2025.4 and Higher
Cause
VM deployment failed because the requested size surpassed the resource provider's max_unit allocation. Further details on [max_units] allocation.
Diagnostics
On underlying host:
- Get the VM disk storage path using command given below:
$ sudo virsh domblklist <VM_UUID>$ sudo virsh domblklist <VM_UUID> Target Source------------------------------------------------------------------------- vda /opt/data/instances/[VM_UUID]/disk- Check where the VM disk storage path is mounted.
The OpenStack placement API takes Disk dev mapper size into account when calculating the resource provider's max unit value.
$ df -lh /opt/data/instances/<VM_UUID>/disk$ sudo df -lh /opt/data/instances/[VM_UUID]/diskFilesystem Size Used Avail Use% Mounted on[Disk dev mapper path] 98G 69G 25G 74% /Here,
- VM disk storage path is mounted on "/".
- The OpenStack consider this 98 GB size while calculating the resource provider's max unit value.
OpenStack CLI:
- List down all available resource providers. These resource providers are responsible for allocating the CPU, Memory and Storage to the VMs.
$ openstack resource provider list- Check for
max_unitforDisk_GBon all resource providers listed above.
Any VM requesting an ephemeral storage disk above the max_unit value will fail with "insufficient resources or a temporary occurrence as compute nodes start up" error in the nova-scheduler logs.
$ openstack resource provider inventory list <RESOURCE_PROVIDER_UUID>$ openstack resource provider inventory list <RESOURCE_PROVIDER_UUID>+----------------+------------------+----------+----------+----------+-----------+--------+-------+| resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used |+----------------+------------------+----------+----------+----------+-----------+--------+-------+| VCPU | 16.0 | 1 | 80 | 0 | 1 | 80 | 6 || MEMORY_MB | 1.5 | 1 | 773663 | 512 | 1 | 773663 | 12288 || DISK_GB | 9999.0 | 1 | 97 | 0 | 1 | 97 | 120 | +----------------+------------------+----------+----------+----------+-----------+--------+-------+Here,
The DISK_GB for the resource provider is 97GB, a value determined by the VM's disk storage configured for the root (/) mount point.
Resolution
- Use image which has storage requirements less than the
max_unitvalue from all available resource providers. - It is recommended to use Cinder-backed volumes for VM deployments.
Validation
- How much storage is requested by the image used to deploy VM.
$ openstack image list --all | grep -i <IMAAGE_USED_BY_VM>$ openstack image show <IMAGE_UUID> --fit+------------------+-----------------------------------------------------------------------+| Field | Value |+------------------+-----------------------------------------------------------------------+... . .| disk_format | qcow2 || file | /v2/images/[image_uuid]/file || id | [image_uuid] || min_disk | 80 <----- Image requires 80 GB disk, within max_unit value || min_ram | 0 || name | [image_name] |... . .+------------------+-----------------------------------------------------------------------+- If these steps prove insufficient to resolve the issue, reach out to the Platform9 Support Team for additional assistance.