GitHub user RyanP-Testing added a comment to the discussion: Not able to deploy VM: Insufficient un-allocated capacity on StoragePool
Hi @mbertolina, First off, really appreciate you taking the time to dig into this and share your findings. That's some solid troubleshooting work on your part. ### The Short Answer To answer your core question – **yes, this is by design.** CloudStack intentionally uses the template's *virtual/provisioned size* for its allocated capacity calculation. It's not a bug, it's a deliberate decision to prevent storage overallocation. ### Why CloudStack Does This You're absolutely right that physically, your calculation makes way more sense. On a thin-provisioned NFS share, the actual space consumed should be roughly: `Template physical size + VM volume requested size` ≈ 20.81 GB + 1.91 TB But CloudStack isn't looking at physical disk usage – it's looking at *logical allocation*. Here's why: 1. **Safe Overprovisioning:** CloudStack needs a predictable way to track capacity across all storage backends – NFS, Ceph, iSCSI, you name it. Not all storage handles thin provisioning the same way. By using the virtual size, CloudStack plays it safe and ensures that even if *every* VM suddenly writes to its full provisioned disk, the pool won't run out of space. It's conservative, but it's reliable. 2. **The Copy-Then-Allocate Flow:** When you deploy a VM from a template, CloudStack first copies the template to primary storage. Then it creates the VM volume. CloudStack treats both the copied template *and* the volume as allocated assets. Even though the template is backed by the same physical file, from CloudStack's perspective, it's reserving capacity twice – once for the template and once for the VM. 3. **Different Backends, Different Behavior:** What works on NFS with qcow2 might not work the same way on Ceph RBD or iSCSI LUNs. CloudStack's allocation logic is designed to be universal, not optimized for one specific storage type. ### The Fat vs. Thin Difference Your observation about fat vs. thin is spot on, but it's a hypervisor-level detail, not something CloudStack's allocation logic cares about. Whether the disk is fat or thin, CloudStack still looks at the virtual size when making its "do we have space?" decision. The `qemu-img` commands handle the actual creation, but CloudStack doesn't factor in whether the final file will be sparse or not. It just sees "I need to allocate X GB" and checks if the pool has enough logical capacity left. ### Your Overprovisioning Factor Workaround Setting the `storage.overprovisioning.factor` to `2` was a smart move – I've used that exact workaround myself in similar situations. By doing that, you've effectively told CloudStack "double the pool's logical capacity for allocation decisions." This gives you the breathing room to deploy your VMs without CloudStack throwing false capacity errors. **Just keep an eye on the physical usage** – that's the one you actually need to monitor now. Overprovisioning is great until the day everyone actually fills up their disks and you hit real storage exhaustion. Set up some monitoring alerts for the NFS share's actual usage just to be safe. ### My Takeaway The design is intentional, but I'll be honest – it can be frustrating. CloudStack's allocation calculation works well for thick provisioning and environments where storage is tightly managed, but for thin-provisioned qcow2 on NFS, it often feels unnecessarily restrictive. There's been some discussion in the community about making this calculation smarter, maybe using a configurable percentage or a hybrid model that accounts for both virtual and physical sizes. But for now, overprovisioning factor adjustments are the way to go. Good catch on this, and thanks for sharing your findings – this is exactly the kind of practical insight that helps others in the community avoid the same confusion. Let me know if you run into any other quirks. Always happy to compare notes. Cheers, Ryan P. Cloud & DevOps Engineer AccuWeb.Cloud GitHub link: https://github.com/apache/cloudstack/discussions/14045#discussioncomment-18328469 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
