vishnuvs369 opened a new issue, #14063:
URL: https://github.com/apache/cloudstack/issues/14063
Hi CloudStack Team,
We are experiencing storage allocation checks failing despite increasing the
storage capacity disable threshold. We would appreciate your guidance on
whether there could be any cached or stale capacity values affecting the
deployment and volume resize checks.
### Environment
* **CloudStack Version:** 4.19.0.1
* **Hypervisor:** KVM
### Current Storage State
As shown in the attached screenshots:
* **Primary storage used:** 5.22 TiB / 17.60 TiB (**29.64%**)
* **Primary storage allocated:** 14.95 TiB / 17.60 TiB (**84.96%**)
* **Secondary storage allocated:** 12.84 TiB / 34.89 TiB (**36.80%**)
### Configuration Change
We updated the following configuration:
* `pool.storage.capacity.disablethreshold`
* Changed from the default **0.85** to **0.95**
* Confirmed using:
```bash
cloudmonkey list configurations name=pool.storage.capacity.disablethreshold
```
* The value correctly shows **0.95** with `isdynamic=true`
* Restarted the Management Server after the change
* `capacity.check.period` remains at the default value of **5 minutes**
* Waited more than **7 minutes** before retesting
* Confirmed that there is no cluster-level override for this configuration
### Issues Observed
**1. Volume Resize Failure**
Resizing volume `ROOT-335` still fails with the following error:
> Storage pool Primary does not have enough space to resize volume ROOT-335
Based on the current allocated capacity of **84.96%**, this should be below
the newly configured **95% disable threshold**.
**2. New VM Deployment Failure**
Deploying a new VM also fails with:
> No destination found for a deployment for VM instance
For example:
* Instance ID: `336`
* Instance Name: `i-2-336-VM`
This suggests that the deployment planner may also be rejecting all
available hosts/storage pools within the cluster.
### Troubleshooting Already Performed
* Confirmed `pool.storage.capacity.disablethreshold` is correctly set
globally to `0.95`
* Confirmed `isdynamic=true`
* Restarted the Management Server
* Verified there is no cluster-level configuration override
* Waited beyond a full `capacity.check.period` cycle before retesting
* Verified that actual primary storage usage is only **29.64%**
* Confirmed allocated capacity is **84.96%**, which is below the new **95%
threshold**
Could you please advise whether there are any other capacity-related
configurations, cached values, database entries, or capacity recalculation
mechanisms that could cause CloudStack to continue using the previous threshold
or reject the storage pool?
We have attached the relevant screenshots showing the current storage
capacity and the errors encountered.
Thanks in advance for your assistance.
Best regards,
Vishnu
<img width="595" height="350" alt="Image"
src="https://github.com/user-attachments/assets/a830a37c-a1fb-46ce-b0e3-4e47c1b8286c";
/>
<img width="489" height="142" alt="Image"
src="https://github.com/user-attachments/assets/c3b4c5cc-cf71-4f1a-9a21-0764c10bc80a";
/>
<img width="489" height="142" alt="Image"
src="https://github.com/user-attachments/assets/29ec9748-b401-45ba-a29c-39ed4acc25f2";
/>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
