CloudStack 4.19.0.1 - Storage Capacity Allocation Checks Still Failing After Updating Disable Threshold, VM deployment and volume resize failing #14067

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:

  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