cloudstack: Incorrect backup usage when VM is removed then re-assign to backup offering

ISSUE TYPE
  • Bug Report
COMPONENT NAME
Usage
CLOUDSTACK VERSION
4.14.1.0
4.15.0.0
CONFIGURATION

Backup framework enabled

OS / ENVIRONMENT

N/A

SUMMARY

When a VM is removed from a backup offering, then re-assigned to the same backup offering, the usage record generated for the period in which these events occur has an invalid usage value, equal to the sum of the sizes of the backups.

STEPS TO REPRODUCE

Example scenario:

  1. 02:30 PM: Create a VM and assign it to a backup offering
  2. 02:35 PM: Make backups of the VM (for a size of e.g. 1 GiB)
  3. 03:15 PM: Remove the backup offering, with the “force” option (to delete existing backups)
  4. 03:30 PM: Re-assign the VM to the backup offering
  5. 03:35 PM: Make a backup of the VM (for a size of e.g. 0.8 GiB)

To reproduce the bug, if the usage aggregation range is e.g 1 Hour (usage.stats.job.aggregation.range = 60), make sure the steps 3, 4 and 5 are executed in the same hour.

EXPECTED RESULTS

Option 1: I would expect CloudStack usage server to:

  • generate two usage records for the period between 03:00 PM and 04:00 PM (one for each period with a backup offering)
  • use the fields raw_usage / usage_display to show the duration of usage, and the field size to show the size of the backups (that’s the way storage usage records are generated for volumes, templates, ISOs and snashots)
+------------+---------------+------------+------------+----------+----------+------------------------+
|  raw_usage | usage_display | size       | start_date | end_date | usage_id | description            |
+------------+---------------+------------+------------+----------+----------+------------------------+
|        0.5 | 0.5 Hrs       | 1073741824 | 14:00:00   | 14:59:59 |       67 | Backup usage VM ID: 67 |
|       0.25 | 0.25 Hrs      | 1073741824 | 15:00:00   | 15:59:59 |       67 | Backup usage VM ID: 67 |
|        0.5 | 0.5 Hrs       |  858993460 | 15:00:00   | 15:59:59 |       67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+

Option 2: This could also be ok (even if we loose information):

+------------+---------------+------------+------------+----------+----------+------------------------+
|  raw_usage | usage_display | size       | start_date | end_date | usage_id | description            |
+------------+---------------+------------+------------+----------+----------+------------------------+
| 1073741824 | 1.0 GiB       | 1073741824 | 14:00:00   | 14:59:59 |       67 | Backup usage VM ID: 67 |
|  858993460 | 0.8 GiB       |  858993460 | 15:00:00   | 15:59:59 |       67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+
ACTUAL RESULTS

Usage records:

+------------+---------------+------------+------------+----------+----------+------------------------+
|  raw_usage | usage_display | size       | start_date | end_date | usage_id | description            |
+------------+---------------+------------+------------+----------+----------+------------------------+
| 1073741824 | 1.0 GiB       | 1073741824 | 14:00:00   | 14:59:59 |       67 | Backup usage VM ID: 67 |
| 1932735284 | 1.8 GiB       | 1932735284 | 15:00:00   | 15:59:59 |       67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+

Here, the raw_usage for the period from 3 PM to 4 PM is the sum of the backup sizes, which is irrelevant (the 1 GiB backups are deleted before the creation of the 0.8 GiB backup).

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (15 by maintainers)

Commits related to this issue

Most upvoted comments

@Pearl1594 @rhtyd @nvazquez I created a draft pr #5259 to fix this issue. since @Pearl1594 had some work in pr #5005 , let’s work together for a solution.

Let’s discuss on the mailing list, sounds like a new behaviour/change that may require consensus on dev/users ML. cc @Pearl1594 pl start a discussion thread, thanks.