Snapshot defaulting to Physical Size 0

[CJBecker]

ISSUE TYPE

• Bug Report

COMPONENT NAME

Snapshot to secondary storage

CLOUDSTACK VERSION

4.19.1

CONFIGURATION

OS / ENVIRONMENT

KVM, NFS secondary storage

SUMMARY

Upgrading from Cloudstack 4.18 to 4.19.1, I see reports in the UI that all snapshots have a 0 Physical Size even when there is a physical size in the database.

select * from snapshot_store_ref where snapshot_id=91517\g
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| id     | store_id | snapshot_id | created             | last_updated | job_id | store_role | size        | physical_size | parent_snapshot_id | install_path                                                                         | state | update_count | ref_cnt | updated             | volume_id | download_state | download_pct | error_str | display | local_path |
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| 129502 |       69 |       91517 | 2024-09-09 09:00:09 | NULL         | NULL   | Primary    | 85899345920 |   85899345920 |                  0 | cloudstack/1721884e-c618-413b-9f31-4eba9a4acc50/582372a9-a122-4121-b25b-f6ea2d875e38 | Ready |            2 |       0 | 2024-09-09 09:00:10 |     25832 | NULL           |            0 | NULL      |       1 | NULL       |
| 129505 |        1 |       91517 | 2024-09-09 09:00:10 | NULL         | NULL   | Image      | 85899345920 |   56633131008 |                  0 | snapshots/13511/25832/582372a9-a122-4121-b25b-f6ea2d875e38                           | Ready |            2 |       0 | 2024-09-09 09:04:45 |     25832 | NULL           |            0 | NULL      |       1 | NULL       |
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
2 rows in set (0.000 sec)

I am using Ceph and local storage with snapshot.backup.to.secondary enabled. I can give more information if needed.

STEPS TO REPRODUCE

Snapshot using local storage with snapshot.backup.to.secondary enabled

EXPECTED RESULTS

Seeing the physical size in the UI as reflected in the database

ACTUAL RESULTS

"physicalsize": 0,

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[DaanHoogland]

@CJBecker , have you tried if the API does give the expected size? (i.e. is it a UI only problem)

[CJBecker]

Hi, The snap posted above has been rotated so I have found a replacement that I was looking at:

select * from snapshot_store_ref where snapshot_id=91820\g
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| id     | store_id | snapshot_id | created             | last_updated | job_id | store_role | size        | physical_size | parent_snapshot_id | install_path                                                                         | state | update_count | ref_cnt | updated             | volume_id | download_state | download_pct | error_str | display | local_path |
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| 129928 |       69 |       91820 | 2024-09-10 09:00:09 | NULL         | NULL   | Primary    | 85899345920 |   85899345920 |                  0 | cloudstack/1721884e-c618-413b-9f31-4eba9a4acc50/7dbbbaa9-3671-41fb-9bc1-2430e88c564c | Ready |            2 |       0 | 2024-09-10 09:00:09 |     25832 | NULL          
 |            0 | NULL      |       1 | NULL       |
| 129931 |        1 |       91820 | 2024-09-10 09:00:09 | NULL         | NULL   | Image      | 85899345920 |   56636145664 |                  0 | snapshots/13511/25832/7dbbbaa9-3671-41fb-9bc1-2430e88c564c                           | Ready |            2 |       0 | 2024-09-10 09:03:52 |     25832 | NULL          
 |            0 | NULL      |       1 | NULL       |
+--------+----------+-------------+---------------------+--------------+--------+------------+-------------+---------------+--------------------+--------------------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
2 rows in set (0.000 sec)

When I check the UUID via cmk I get:

cmk list snapshots id=3cf61abd-211e-4ddf-bd7c-cabdee7b9634 listall=true filter=physicalsize,virtualsize,state
{
  "count": 1,
  "snapshot": [
    {
      "physicalsize": 0,
      "state": "BackedUp",
      "virtualsize": 85899345920
    }
  ]
}

It appears to not be just a UI issue.

Also, when the original post was made I provided a Ceph store, but I see the same with local storage aswell.

 select * from snapshot_store_ref where snapshot_id=91808\g
+--------+----------+-------------+---------------------+--------------+--------+------------+--------------+---------------+--------------------+------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| id     | store_id | snapshot_id | created             | last_updated | job_id | store_role | size         | physical_size | parent_snapshot_id | install_path                                                           | state | update_count | ref_cnt | updated             | volume_id | download_state | download_pct | error_str | display | local_path |
+--------+----------+-------------+---------------------+--------------+--------+------------+--------------+---------------+--------------------+------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
| 129917 |       52 |       91808 | 2024-09-10 09:00:08 | NULL         | NULL   | Primary    | 171798691840 |  171798691840 |                  0 | /var/lib/libvirt/images/snapshots/75066687-bd71-4785-8981-a5ccdb0533fd | Ready |            2 |       0 | 2024-09-10 09:03:44 |     17717 | NULL           |           
 0 | NULL      |       1 | NULL       |
| 129932 |        1 |       91808 | 2024-09-10 09:03:44 | NULL         | NULL   | Image      | 171798691840 |   65756332032 |                  0 | snapshots/872/17717/183ebc06-613f-4c58-bce1-c0c51498a654               | Ready |            2 |       0 | 2024-09-10 09:05:55 |     17717 | NULL           |           
 0 | NULL      |       1 | NULL       |
+--------+----------+-------------+---------------------+--------------+--------+------------+--------------+---------------+--------------------+------------------------------------------------------------------------+-------+--------------+---------+---------------------+-----------+----------------+--------------+-----------+---------+------------+
2 rows in set (0.000 sec)

cmk list snapshots id=068b140e-186f-4436-93ec-ba56ebcc1ee7 listall=true filter=physicalsize,virtualsize,state
{
  "count": 1,
  "snapshot": [
    {
      "physicalsize": 0,
      "state": "BackedUp",
      "virtualsize": 171798691840
    }
  ]
}

[CJBecker]

Also for a test:

UPDATE snapshot_store_ref SET display = 0 WHERE id = 129917;
Query OK, 1 row affected (0.004 sec)
Rows matched: 1  Changed: 1  Warnings: 0

I can see the correct information via API:

cmk list snapshots id=068b140e-186f-4436-93ec-ba56ebcc1ee7 listall=true filter=physicalsize,virtualsize,state
{
  "count": 1,
  "snapshot": [
    {
      "physicalsize": 65756332032,
      "state": "BackedUp",
      "virtualsize": 171798691840
    }
  ]
}

I believe that the default behavior in the past with my configuration was to retain the reference information, as in the original post, while displaying the physical size. Unless there's something specific to my setup, but I haven't noticed any errors or messages in the logs.

[GiulianoMaras]

I'm also affected by this issue in version 4.19.1.1
If setting the db "display" field to "0" is it a workaround? My "display" filed is showing 1

Will this affect anything else?

[Jayd603]

Same here.. strangely a few volume snapshots show the correct size, most show 0. These are all to NFS

[tdtmusic2]

Same for me, but the other way around, I used secondary storage up until yesterday when I switched that option to primary (ceph pool). All the snapshots are 0 in physical size but they seem to be fine when reverting to them. Confusing.