qemu-img measure is incorrect when using discard-no-unref

Goal

In oVirt we put qcow2 images into LVM Logical volumes with thin provisioning. Now during a commit of a snapshot from an offline VM I encountered an issue which leads me to creating this request.

Lets take the snapshot:

# qemu-img info /dev/6aade004-95dd-46b9-b00e-777d44264818/4eb72376-5e1d-47fc-81de-ce0a2e2541e5
image: /dev/6aade004-95dd-46b9-b00e-777d44264818/4eb72376-5e1d-47fc-81de-ce0a2e2541e5
file format: qcow2
virtual size: 85 GiB (91268055040 bytes)
disk size: 0 B
cluster_size: 65536
backing file: be885e9a-190e-43c8-b429-8678a153b099 (actual path: /dev/6aade004-95dd-46b9-b00e-777d44264818/be885e9a-190e-43c8-b429-8678a153b099)
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: /dev/6aade004-95dd-46b9-b00e-777d44264818/4eb72376-5e1d-47fc-81de-ce0a2e2541e5
    protocol type: host_device
    file length: 5.75 GiB (6174015488 bytes)
    disk size: 0 B

And the base:

# qemu-img info /dev/6aade004-95dd-46b9-b00e-777d44264818/be885e9a-190e-43c8-b429-8678a153b099
image: /dev/6aade004-95dd-46b9-b00e-777d44264818/be885e9a-190e-43c8-b429-8678a153b099
file format: qcow2
virtual size: 85 GiB (91268055040 bytes)
disk size: 0 B
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: /dev/6aade004-95dd-46b9-b00e-777d44264818/be885e9a-190e-43c8-b429-8678a153b099
    protocol type: host_device
    file length: 12.5 GiB (13421772800 bytes)
    disk size: 0 B

Those reside in 2 logical volumes: The base:

  be885e9a-190e-43c8-b429-8678a153b099 6aade004-95dd-46b9-b00e-777d44264818 -wi-a-----  12.50g                                                    

The snapshot:

  4eb72376-5e1d-47fc-81de-ce0a2e2541e5 6aade004-95dd-46b9-b00e-777d44264818 -wi-a-----   5.75g   

Now to commit the snapshot, oVirt has the following flow:

• Activate both LV's
• Run a qemu-img measure on the snapshot
• If the required size > size of the base volume -> Extend base volume
• Commit snapshot
• Remove snapshot LV

But the measure is not reliable in this case. Cause: Base

# qemu-img measure -O qcow2 /dev/6aade004-95dd-46b9-b00e-777d44264818/be885e9a-190e-43c8-b429-8678a153b099
required size: 13415219200
fully allocated size: 91282210816
bitmaps size: 0

Snapshot

# qemu-img measure -O qcow2 /dev/6aade004-95dd-46b9-b00e-777d44264818/4eb72376-5e1d-47fc-81de-ce0a2e2541e5
required size: 3491168256
fully allocated size: 91282210816
bitmaps size: 0

So, it thinks it will only need 3491168256 bytes to commit the snapshot into the base. BUT this is incorrect, as no new image is created, but the snapshot is commited into the base, causing the base file to grow.

If I simply copy the disks to filesystemm, then I have the following sizes:

 6174015488 - 4eb72376-5e1d-47fc-81de-ce0a2e2541e5
13421772800 - be885e9a-190e-43c8-b429-8678a153b099

Now let's run a commit:

qemu-img commit -p -t none -b be885e9a-190e-43c8-b429-8678a153b099 -f qcow2 4eb72376-5e1d-47fc-81de-ce0a2e2541e5

And that will cause the base to grow to:

13504806912 - be885e9a-190e-43c8-b429-8678a153b099

So it would be great if there was some option/additional command to find out the new end offset when running a commit before actually running it. What are the options in here?