Clarification on Storage Overprovisioning Factor

[vishnuvs369]

Hi Team,

We noticed that the Storage overprovisioning factor is currently set to 2 in CloudStack.

Could you please confirm how this setting is being applied to our primary storage and how it affects the allocated storage capacity shown in the CloudStack dashboard?

Our current primary storage shows:

Total: 17.60 TiB
Allocated: 14.27 TiB (81.08%)
Used: 4.84 TiB (27.51%)
Storage overprovisioning factor: 2

Could you also please confirm whether a factor of 2 means CloudStack considers approximately 35.2 TiB as available/allocatable storage from the 17.6 TiB physical capacity?

Additionally, please advise what would happen if the allocated storage reaches 100%, and whether there are any risks or recommended limits we should consider with the current configuration.

Attaching relevant screenshots for your refference.

[prashanthr2]

@vishnuvs369

>>Could you also please confirm whether a factor of 2 means CloudStack considers approximately 35.2 TiB as available/allocatable storage from the 17.6 TiB physical capacity?

Yes, but it depends on the type of Primary Storage being used. https://docs.cloudstack.apache.org/en/latest/adminguide/storage.html#hypervisor-support-for-primary-storage

[Ryan-AccuWeb-Cloud]

Hi @vishnuvs369 ,

Yeah, this trips up a lot of people — happy to clear it up.

So how does the factor actually work?

The storage.overprovisioning.factor (default is 2) is a global setting. It applies to storage pools that support thin provisioning — mainly NFS, and thin iSCSI/FC on some hypervisors. You can't set it per-pool out of the box, which is a bit annoying (there's an old feature request for it: CLOUDSTACK-6092).

Your numbers — you've got it right

With a factor of 2 on a 17.60 TiB pool, CloudStack treats it as:

17.60 × 2 = 35.2 TiB allocatable

So yep, that's where the 35.2 TiB comes from. It's basically CloudStack saying "I'll let you thin-provision up to double the physical size."

What allocated vs. used actually means

This is the part that confuses most folks:

• Allocated (14.27 TiB / 81%) — this is just the sum of all the volume sizes CloudStack has handed out. It's what would be used if everyone filled their disks completely.
• Used (4.84 TiB / 27.5%) — this is the real physical space actually sitting on disk right now (basically what df would show you).

So in your case, people have been given 14.27 TiB worth of volumes, but they're only actually using 4.84 TiB. That gap is exactly why overprovisioning exists — most VMs never fill their disks.

What happens when allocated hits 100%?

CloudStack stops letting you create new volumes on that pool (and typically blocks VM deploys that need a new volume). Simple as that.

One thing to watch out for: there have been bugs in some versions where resize or migration operations don't do the capacity check properly, and allocated sneaks past 100%. So don't rely on that 100% limit as a hard wall.

The real risk with factor = 2

Here's the thing — factor 2 assumes your average disk usage stays under 50%. If people start actually filling their disks, you'll run out of physical space long before allocated ever hits 100%.

That's the trap. Allocated says "everything's fine, you're at 81%," but you could be near physical exhaustion and not realize it until writes start failing.

What I'd recommend

• Watch Used, not Allocated. Used is your real limit.
• Keep actual usage under ~80% of physical capacity to be safe.
• If your users tend to fill disks (or you're not sure), drop the factor to 1.5 or even 1.
• Factor 2 is fine if you trust that utilization stays low. Factor 3+ is asking for trouble unless you've got data proving people barely use their disks.

TL;DR — Yes, 35.2 TiB is the allocatable number. CloudStack will block new volumes at 100% allocated, but the real danger is running out of physical space first. Keep an eye on Used and you'll be fine.

Regards,
Ryan | AccuWeb.Cloud
Cloud & Infrastructure Support