You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Quota charges attached volumes twice since 4.22.1 (cumulative + per-VM usage_volume records from #11531) #14550
Since #11531 (4.22.1), Usage intentionally writes two kinds of usage_volume helper rows for an attached volume: a cumulative row (vm_id NULL) and a per-VM row (vm_id set). Both generate an hourly usage_type = 6 (VOLUME) record in cloud_usage, one with and one without vm_instance_id.
The Quota plugin treats both records as billable, so every attached volume is charged twice.
versions
CloudStack 4.22.1.1 (management, usage)
KVM, Ceph RBD primary storage
Quota enabled with a volume tariff (usage_type = 6)
steps to reproduce
Enable Quota and configure a tariff for usage type 6.
Create a data volume and attach it to a running VM (events VOLUME.CREATE, then VOLUME.ATTACH).
After the next Usage run, check cloud_usage.usage_volume. There are two rows with deleted IS NULL, one with vm_id NULL and one with vm_id set to the VM.
Check cloud_usage.cloud_usage for that volume and hour. There are two usage_type = 6 records with the same raw_usage: one with vm_instance_id NULL and one with vm_instance_id set.
Check cloud_usage.quota_usage. There is one row per cloud_usage record, both with the same quota_used, so the account balance is debited twice.
Example, one volume and one hour:
cloud_usage.vm_instance_id
records
quota_used
NULL (cumulative)
1
0.0081
set (per-VM)
1
0.0081
expected
A volume should be charged once per hour. Quota should bill only one of the two record kinds, for example the cumulative record (vm_instance_id NULL), since that is the one that is consistent with pre-#11531 behaviour.
Our workaround: an hourly job sets deleted = created on per-VM usage_volume rows whenever an active cumulative row exists for the same volume. Per-VM records then stop being generated for that volume, and the cumulative row keeps billing it through detach and re-attach. Records written before we found this had to be removed by hand.
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Since #11531 (4.22.1), Usage writes two usage_volume helper rows for an attached volume: a cumulative row (vm_id NULL) and a per-VM row. Each generates an hourly usage_type = 6 record, and Quota bills both, so attached volumes are charged twice. The reporter describes a workaround that sets deleted on per-VM rows, and notes that the double charge will also reach root volumes once the unique key is widened in 4.22.2 (#13909 / #13933).
📊 Assessment
Dimension
Value
Reasoning
Type
type:bug
Duplicate billing records since 4.22.1
Component
component:usage-server, component:quota
Usage writes the rows; Quota debits them
Severity
Severity:Major
Account balances are debited twice for attached volumes; workaround in place
Activity
boring-cyborg commentedon Nov 1, 2026
Thanks for opening your first issue here! Be sure to follow the issue template!
github-actions commentedon Nov 2, 2026
Warning
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
Since #11531 (4.22.1), Usage writes two
usage_volumehelper rows for an attached volume: a cumulative row (vm_idNULL) and a per-VM row. Each generates an hourlyusage_type = 6record, and Quota bills both, so attached volumes are charged twice. The reporter describes a workaround that setsdeletedon per-VM rows, and notes that the double charge will also reach root volumes once the unique key is widened in 4.22.2 (#13909 / #13933).📊 Assessment
🔗 Similar issues
usage_volume, referenced in the report as the reason root volumes are not yet affectedvm_instance_idis null for volume usage (usage_type = 6)💡 Notes and suggestions
cloud_usageandquota_usagerows will need a cleanup or credit decision; the reporter removed theirs by hand.Add this agentic workflow to your repo
To install this agentic workflow, run