Physical size for QCOW2 volumes with backing file

[shwstppr]

When returning the physical size for a QCOW2 volume, which has a backing file (ROOT volumes especially), the size of the backing file is not considered.

What I get in the UI,

What I see in storage,

[root@ref-trl-11214-k-Mol9-rositsa-kyuchukova-kvm1 d20888cd-7e52-3481-b54f-80e14ff02320]# qemu-img info 3e33e73e-a71d-4022-8b80-680ea1d2adc2
image: 3e33e73e-a71d-4022-8b80-680ea1d2adc2
file format: qcow2
virtual size: 8 GiB (8589934592 bytes)
disk size: 1.87 GiB
cluster_size: 65536
backing file: /mnt/d20888cd-7e52-3481-b54f-80e14ff02320/f53fa557-1606-11f1-ac81-1e001a0002e1
backing file format: qcow2
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: 3e33e73e-a71d-4022-8b80-680ea1d2adc2
    protocol type: file
    file length: 1.87 GiB (2007171072 bytes)
    disk size: 1.87 GiB
[root@ref-trl-11214-k-Mol9-rositsa-kyuchukova-kvm1 d20888cd-7e52-3481-b54f-80e14ff02320]# ll -h /mnt/d20888cd-7e52-3481-b54f-80e14ff02320/f53fa557-1606-11f1-ac81-1e001a0002e1
-rw-r--r--. 1 root root 1.7G Mar  2 08:44 /mnt/d20888cd-7e52-3481-b54f-80e14ff02320/f53fa557-1606-11f1-ac81-1e001a0002e1
[root@ref-trl-11214-k-Mol9-rositsa-kyuchukova-kvm1 d20888cd-7e52-3481-b54f-80e14ff02320]# ll -h 3e33e73e-a71d-4022-8b80-680ea1d2adc2
-rw-r--r--. 1 root root 1.9G Mar  2 15:51 3e33e73e-a71d-4022-8b80-680ea1d2adc2
[root@ref-trl-11214-k-Mol9-rositsa-kyuchukova-kvm1 d20888cd-7e52-3481-b54f-80e14ff02320]# pwd
/mnt/d20888cd-7e52-3481-b54f-80e14ff02320

While the template can be backing for multiple ROOT volumes, shouldn't the physical size of each volume also include the backing file size?
In the above case, shouldn't it be 3.77G?

This could create issues when sizes are retrieved by any external systems, and while checking for resource limits for backups, etc.

[rajujith]

@shwstppr, possibly the physical size is ideal for usage and billing, not for backups. Maybe we should create a total_chain_size for such scenarios?

https://docs.cloudstack.apache.org/en/4.22.0.0/adminguide/backup_and_recovery.html#configuring-resource-limits-on-backups