GitHub user RyanP-Testing added a comment to the discussion: Not able to deploy VM: Insufficient un-allocated capacity on StoragePool
Hello @mbertolina, Thank you for the excellent and detailed logs — this really helps pinpoint exactly what's happening. Let me explain why CloudStack is rejecting your storage pools and how to fix it. --- ### Root Cause Analysis **You've hit the "Allocated Capacity Threshold"**, not the physical usage threshold. Here's the key moment from your logs: ``` Insufficient un-allocated capacity on: StoragePool for storage allocation since its allocated percentage: 0.9337067261132008 has crossed the allocated pool.storage.allocated.capacity.disablethreshold: 0.85 ``` **What this means:** CloudStack maintains two separate capacity metrics for storage: | Metric | Physical Usage | Allocated Capacity | |--------|---------------|-------------------| | **What it tracks** | Actual bytes written to disk (0.05% in your case) | Total provisioned size of all volumes *reserved* by CloudStack (93.37% in your case) | | **Why it's high** | You've created volumes totaling ~1.86 TB across your pools, even if they're not fully written to disk | | In your case: - **Template Size:** 1.91 TB (this is the *provisioned* size CloudStack tracks) - **Pool Capacity:** ~4.0 TB - **Allocated Percentage:** 93.37% (because CloudStack has already reserved the full 1.91 TB from your template) - **Physical Usage:** Only 0.05% (the thin-provisioned qcow2 file on disk) The **allocated threshold** is set to **0.85 (85%)** by default, and your pools are at **93.37%**, so CloudStack correctly blocks new deployments to prevent overallocation. --- ### Solutions #### Solution 1: Increase the Allocated Threshold (Quick Fix) Increase the `pool.storage.allocated.capacity.disablethreshold` global setting: 1. Navigate to **Global Settings** in the CloudStack UI 2. Search for `pool.storage.allocated.capacity.disablethreshold` 3. Increase the value from `0.85` to something higher, e.g.: - `0.95` (95%) or - `0.98` (98%) **Why this works:** It allows CloudStack to provision volumes up to 95% or 98% of the pool's *allocated capacity*, giving you room to deploy VMs. **Limitation:** Once you exceed the threshold again (e.g., create more volumes), you'll hit the same issue. This is a temporary fix, not a long-term solution. --- #### Solution 2: Check for Orphaned Volumes (Recommended) If you have unused volumes, detach or delete them to free up allocated capacity: 1. Go to **Storage → Volumes** 2. Look for volumes that are: - **Detached** but still exist - **Expired snapshots** - **Old templates** no longer needed 3. Delete or clean up unnecessary volumes **Why this works:** Each volume you delete reduces the `totalAllocatedSize` in CloudStack's database, freeing up capacity for new deployments. --- #### Solution 3: Monitor Allocated Capacity Proactively Use this API call to check allocated capacity for a specific pool: ```bash curl -k -H "Authorization: <your-auth-header>" \ "http://<ms-ip>:8080/client/api?command=listStoragePools&id=<pool-uuid>" ``` Look for the `allocated` field in the response to track this metric over time. --- #### Solution 4: If You're Using Thin Provisioning If your underlying storage supports thin provisioning, you can safely increase the threshold closer to 1.0 since your physical usage is low. However, **be cautious** — monitoring actual storage usage is critical to avoid real capacity exhaustion. --- ### 📝 Summary Table | Metric | Current Value | Threshold | Status | |--------|---------------|-----------|--------| | Physical Usage | 0.05% | N/A | ✅ OK | | Allocated Capacity | 93.37% | 85% | ❌ **Blocked** | **Conclusion:** Increase the allocated threshold to 95%, or clean up unused volumes. Either approach will allow your VM deployment to proceed. Let us know which approach you take, and feel free to share any additional questions! --- Regards, Ryan P. Cloud & DevOps Engineer AccuWeb.Cloud GitHub link: https://github.com/apache/cloudstack/discussions/14045#discussioncomment-18313986 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
