Currently OVF disks are created as preallocated disk:

<disk href="/ovirt-engine/api/disks/d6ac0ab5-bd39-4e19-8306-fd3bd36d64ac" id="d6ac0ab5-bd39-4e19-8306-fd3bd36d64ac">
<name>OVF_STORE</name>
<alias>OVF_STORE</alias>
<content_type>ovf_store</content_type>
<format>raw</format>
<provisioned_size>134217728</provisioned_size>
<actual_size>61440</actual_size>
<sparse>false</sparse>
...
</disk>

On file storage, the OVF is created preallocated, but on the first write, it is
truncated to the size of the tar by:

    cmd = [
        constants.EXT_DD,
        "of=%s" % dstImgPath,
        "bs=%s" % MiB,
        # Ensure that data reach physical storage before returning.
        "conv=fsync",
    ]   

This truncates the output file on file storage.

# ls -lhs /rhev/data-center/mnt/nfs1:_export_1/56ecc03c-4bb5-4792-8971-3c51ea924d2e/images/d6ac0ab5-bd39-4e19-8306-fd3bd36d64ac
total 1.1M
 28K -rw-rw----. 1 vdsm kvm  25K Aug 11 13:18 adc60bd9-c0f3-4a49-a859-caf6562c79c4
1.0M -rw-rw----. 1 vdsm kvm 1.0M May 16 20:58 adc60bd9-c0f3-4a49-a859-caf6562c79c4.lease
4.0K -rw-r--r--. 1 vdsm kvm  429 Aug 11 13:18 adc60bd9-c0f3-4a49-a859-caf6562c79c4.meta

# cat /rhev/data-center/mnt/nfs1:_export_1/56ecc03c-4bb5-4792-8971-3c51ea924d2e/images/d6ac0ab5-bd39-4e19-8306-fd3bd36d64ac/adc60bd9-c0f3-4a49-a859-caf6562c79c4.meta
CAP=134217728
CTIME=1589651890
DESCRIPTION={"Updated":true,"Size":25088,"Last Updated":"Tue Aug 11 13:18:39 IDT 2020","Storage Domains":[{"uuid":"56ecc03c-4bb5-4792-8971-3c51ea924d2e"}],"Disk Description":"OVF_STORE"}
DISKTYPE=OVFS
DOMAIN=56ecc03c-4bb5-4792-8971-3c51ea924d2e
FORMAT=RAW
GEN=0
IMAGE=d6ac0ab5-bd39-4e19-8306-fd3bd36d64ac
LEGALITY=LEGAL
PUUID=00000000-0000-0000-0000-000000000000
TYPE=PREALLOCATED
VOLTYPE=LEAF
EOF

Truncating in vdsm is a bug, but this was done since the first version introducing
this feature, so all OVF disks on file storage are truncated.

We have several options to fix this:

- Fix vdsm to avoid truncating

But this is not really needed since this is not a disk image. Truncating files
is good for OVF storage, and simplifies working with them.

- Change engine to create raw-sparse image

I'm not sure why we use preallocated disk. Maybe to ensure that we always have 
space to write into the file? This is broken by vdsm truncating the file, so this feature
never worked, and we can change it safely.

- Fix engine to keep the right size of the OVF disk

Each time the engine update OVF disk, it can update the size in the db.
Or run Volume.getInfo() before download, updating the size - this is needed
for any disk.

- Use the size from the OVF description as the ticket size:

    DESCRIPTION={"Updated":true,"Size":25088,"Last Updated":"Tue Aug 11 13:18:39 IDT 2020",
    "Storage Domains":[{"uuid":"56ecc03c-4bb5-4792-8971-3c51ea924d2e"}],"Disk Description":"OVF_STORE"}

This looks like the best way since it will work for both file and block storage.

Raising the severity to 'high', as this is a major feature to be able to reflect to the user the correct image size.

After debugging this bug, I see the most propper solution is to do it in VDSM side, not the engine side. 
so, we return the correct size value for the capacity, or, maybe fix the capacity to represent the correct value.

(In reply to Ahmad Khiet from comment #3)
> After debugging this bug, I see the most propper solution is to do it in
> VDSM side, not the engine side. 
> so, we return the correct size value for the capacity, or, maybe fix the
> capacity to represent the correct value.

As Nir already mentioned in comment 1, it is better to fix this issue on the engine side 
by creating those disks as raw-sparse on file-base storage domains.

We should also verify that we are able to download the OVF disks correctly by using the right size.

Using raw sparse will likely fix the issue of reporting correct 
actual size for file storage, but it will not fix the issue with
block storage, where the minimal size is 128 MiB.

I think the best way to handle this is to get the volume description:

    DESCRIPTION={"Updated":true,"Size":25088,"Last Updated":"Tue Aug 11 13:18:39 IDT 2020",
    "Storage Domains":[{"uuid":"56ecc03c-4bb5-4792-8971-3c51ea924d2e"}],"Disk Description":"OVF_STORE"}

Parse the json, and use the Size as the ticket size. This way we can
download the right size on every storage.

The issue raised in this bug - reporting incorrect actual size should
not affect the user if they download the OVF volume without specifying
a size.

Ilan, why do you care about the reported actual size for OVF volumes?
How does this affect the user?

Frankly speaking I can not recall which scenario exactly stumbled on this issue for me, since I opened this BZ around 4 months ago.
But even though one can not think of which application should the user encounter this, this is still not right and needs to be fixed.

Misleading or contrary information about the actual size of whatever it could be (disk \ vol) is very problematic in the eyes of tester.
despite the possibility that this issue might not cause an immediate failure of some sort for the end user, it still can damage the reliability of our product in the eyes of the customer. Hence should be treated appropriately.

QE doesn't have enough capacity to verify this bug on the 4.4.5 release.

As I mentioned in my last comment: "QE doesn't have enough capacity to verify this bug on the 4.4.5 release"

Version for testing:

[root@storage-ge12-vdsm1 ~]# rpm -q vdsm
vdsm-4.40.60.3-1.el8ev.x86_64

[root@storage-ge12-vdsm1 ~]# rpm -qa | grep release
rhv-release-4.4.6-4-001.noarch
redhat-release-8.4-0.6.el8.x86_64
redhat-release-eula-8.4-0.6.el8.x86_64

steps for reproduction:
 
I created a 4GB preallocated image on NFS storage (allocation policy == preallocated), the image was created on my GE-12 env (storage domain: nfs_1), (alias: test1030), (description : bugcheck), (id: 9e3c2a1f-2aaf-49fa-8a9a-324eddc83053)


My findings regarding the engine - via CMD:


[root@storage-ge12-vdsm1 ~]# ls -lhs /rhev/data-center/55b87c27-87b1-49d1-9954-9f8d9e37703e/b5ca710b-057a-42ef-8250-3e393c38da61/images/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053
total 4.1G
4.1G -rw-rw----. 1 vdsm kvm 4.0G Apr 14 10:31 d8ccb65c-b45f-45a2-80aa-aa4bb859f211
1.1M -rw-rw----. 1 vdsm kvm 1.0M Apr 14 10:31 d8ccb65c-b45f-45a2-80aa-aa4bb859f211.lease
4.0K -rw-r--r--. 1 vdsm kvm  309 Apr 14 10:31 d8ccb65c-b45f-45a2-80aa-aa4bb859f211.meta





My findings regarding the engine - via API call:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<disk href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053" id="9e3c2a1f-2aaf-49fa-8a9a-324eddc83053">
    <actions>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/reduce" rel="reduce"/>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/copy" rel="copy"/>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/export" rel="export"/>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/move" rel="move"/>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/refreshlun" rel="refreshlun"/>
        <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/sparsify" rel="sparsify"/>
    </actions>
    <name>test1030</name>
    <description>bugcheck</description>
    <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/disksnapshots" rel="disksnapshots"/>
    <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/permissions" rel="permissions"/>
    <link href="/ovirt-engine/api/disks/9e3c2a1f-2aaf-49fa-8a9a-324eddc83053/statistics" rel="statistics"/>
    <actual_size>4311887872</actual_size>
    <alias>test1030</alias>
    <backup>none</backup>
    <content_type>data</content_type>
    <format>raw</format>
    <image_id>d8ccb65c-b45f-45a2-80aa-aa4bb859f211</image_id>
    <propagate_errors>false</propagate_errors>
    <provisioned_size>4294967296</provisioned_size>
    <shareable>false</shareable>
    <sparse>false</sparse>
    <status>ok</status>
    <storage_type>image</storage_type>
    <total_size>4311887872</total_size>
    <wipe_after_delete>false</wipe_after_delete>
    <disk_profile href="/ovirt-engine/api/diskprofiles/8041243f-15d6-46e8-a02a-1ad528008f39" id="8041243f-15d6-46e8-a02a-1ad528008f39"/>
    <quota href="/ovirt-engine/api/datacenters/55b87c27-87b1-49d1-9954-9f8d9e37703e/quotas/c06d1877-49d8-43c2-a1dd-d342bbd1328f" id="c06d1877-49d8-43c2-a1dd-d342bbd1328f"/>
    <storage_domains>
        <storage_domain href="/ovirt-engine/api/storagedomains/b5ca710b-057a-42ef-8250-3e393c38da61" id="b5ca710b-057a-42ef-8250-3e393c38da61"/>
    </storage_domains>
</disk>

Hi Amit, 

I see that the bug is reproduced, and verified as expected.

After looking into this issue with Ahmad - The issue might not yet be resolved.
We should find OVF disk (we have it by default - no need to create)
look at the API for this disk
look at the terminal.
Both sizes should be equal
just make sure the disk resides on file storage (gluster / nfs). 

We should also check in the DB.

(In reply to Amit Sharir from comment #11)
> After looking into this issue with Ahmad - The issue might not yet be
> resolved.
> We should find OVF disk (we have it by default - no need to create)
> look at the API for this disk
> look at the terminal.
> Both sizes should be equal
> just make sure the disk resides on file storage (gluster / nfs). 
> 
> We should also check in the DB.

From comment #9 I can see that you tried to create a disk in order to validate this bug.

This bug refer to OVF_STORE disk only, please verify again.

(In reply to Eyal Shenitzky from comment #12)
> (In reply to Amit Sharir from comment #11)
> > After looking into this issue with Ahmad - The issue might not yet be
> > resolved.
> > We should find OVF disk (we have it by default - no need to create)
> > look at the API for this disk
> > look at the terminal.
> > Both sizes should be equal
> > just make sure the disk resides on file storage (gluster / nfs). 
> > 
> > We should also check in the DB.
> 
> From comment #9 I can see that you tried to create a disk in order to
> validate this bug.
> 
> This bug refer to OVF_STORE disk only, please verify again.

Missed the part that you talked with Ahmad about it and checked on the OVF disk.

update: 

I'm verifying it, just faced some errors in my environment I was setting up storage, I think I need to add a patch for it, if it's not fully updated to db.
tomorrow at scrum I will update this bug status.

I checked the OVF disk image which is stored on file storage (I checked both on Gluster and NFS) and got contradicting results. My verification was done like the steps shown in comment#1. 


version for testing:

# rpm -q vdsm
vdsm-4.40.60.6-1.el8ev.x86_64

# rpm -q ovirt-engine
ovirt-engine-4.4.6.6-0.10.el8ev.noarch

# rpm -qa | grep release
rhv-release-4.4.6-7-001.noarch
redhat-release-8.4-0.6.el8.x86_64
redhat-release-eula-8.4-0.6.el8.x86_64


For example, I got these different results when using the API and terminal for OVF disk <fdf8019c-5a68-405f-89ce-1249a29891d6? : - (4096) VS [25k]


[1]


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<disk href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6" id="fdf8019c-5a68-405f-89ce-1249a29891d6">
    <actions>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/reduce" rel="reduce"/>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/copy" rel="copy"/>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/export" rel="export"/>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/move" rel="move"/>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/sparsify" rel="sparsify"/>
        <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/refreshlun" rel="refreshlun"/>
    </actions>
    <name>OVF_STORE</name>
    <description>OVF_STORE</description>
    <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/permissions" rel="permissions"/>
    <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/disksnapshots" rel="disksnapshots"/>
    <link href="/ovirt-engine/api/disks/fdf8019c-5a68-405f-89ce-1249a29891d6/statistics" rel="statistics"/>
    <actual_size>4096</actual_size>
    <alias>OVF_STORE</alias>
    <backup>none</backup>
    <content_type>ovf_store</content_type>
    <format>raw</format>
    <image_id>cdf1e268-3b4c-474c-bdae-a6d5d1462745</image_id>
    <propagate_errors>false</propagate_errors>
    <provisioned_size>25600</provisioned_size>
    <shareable>false</shareable>
    <sparse>true</sparse>
    <status>ok</status>
    <storage_type>image</storage_type>
    <total_size>4096</total_size>
    <wipe_after_delete>false</wipe_after_delete>
    <disk_profile href="/ovirt-engine/api/diskprofiles/c8e399d4-4cbf-402b-ace1-8222f1bc5dcd" id="c8e399d4-4cbf-402b-ace1-8222f1bc5dcd"/>
    <quota href="/ovirt-engine/api/datacenters/7eeccf19-ed1b-4190-9389-745744844062/quotas/dea77fdc-7aca-429b-9e6d-bf0bf345f430" id="dea77fdc-7aca-429b-9e6d-bf0bf345f430"/>
    <storage_domains>
        <storage_domain href="/ovirt-engine/api/storagedomains/97cd5e5f-212d-41f2-b6dc-31525d78f877" id="97cd5e5f-212d-41f2-b6dc-31525d78f877"/>
    </storage_domains>
</disk>


[2a]


fdf8019c-5a68-405f-89ce-1249a29891d6]# ls -lhs
total 1.1M
 25K -rw-rw----. 1 vdsm kvm  25K May  4 15:50 cdf1e268-3b4c-474c-bdae-a6d5d1462745
1.0M -rw-rw----. 1 vdsm kvm 1.0M May  4 15:49 cdf1e268-3b4c-474c-bdae-a6d5d1462745.lease
 512 -rw-r--r--. 1 vdsm kvm  423 May  4 15:50 cdf1e268-3b4c-474c-bdae-a6d5d1462745.meta
[root@storage-ge2-vdsm1 fdf8019c-5a68-405f-89ce-1249a29891d6]# rpm -q vdsm


[2b]


# cat cdf1e268-3b4c-474c-bdae-a6d5d1462745.meta
CAP=134217728
CTIME=1620132577
DESCRIPTION={"Updated":true,"Size":25600,"Last Updated":"Tue May 04 15:50:00 IDT 2021","Storage Domains":[{"uuid":"97cd5e5f-212d-41f2-b6dc-31525d78f877"}],"Disk Description":"OVF_STORE"}
DISKTYPE=OVFS
DOMAIN=97cd5e5f-212d-41f2-b6dc-31525d78f877
FORMAT=RAW
GEN=0
IMAGE=fdf8019c-5a68-405f-89ce-1249a29891d6
LEGALITY=LEGAL
PUUID=00000000-0000-0000-0000-000000000000
TYPE=SPARSE
VOLTYPE=LEAF
EOF




Actual results:
The sizes reported by the engine, and the actual size differs.

Expected results:
The size reported by the engine should match the actual size of the OVF.

Conclusion:
Failed verification

did you check the database?

did you check the database?

btw, vdsm sets the size in the description and the engine gets it and saves it to the DB.
from what I checked all the sizes are the expected in my environment and I can show you on Sunday.
if there is another issue in vdsm, that's another bug.

either the latest patch is not part of the build in your environment or there is something not clear.
here is a screenshot from my environment to prove that it works as expected and well verified.
(will be attached next comment.

Created attachment 1780471 [details]
screenshot 1

Created attachment 1780472 [details]
screenshot 2

Amit, please make sure that the latest patch fix is part of the build you are using. 
it seems it's not added to the build, I don't know why.

*** Bug 1996123 has been marked as a duplicate of this bug. ***

Verified.
Compared size of an OVF disk resides on NFS/Gluster via Rest API to the actual size on the storage domain successfully.


Versiones:
ovirt-engine-4.5.0-582.gd548206.185.el8ev.noarch
vdsm-4.50.0.5-1.el8ev.x86_64

#NFS
[1]
Rest API:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<disk href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d" id="b471e8e9-8a80-4ad7-bc75-62775dfd2a7d">
    <actions>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/reduce" rel="reduce"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/sparsify" rel="sparsify"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/copy" rel="copy"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/export" rel="export"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/move" rel="move"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/refreshlun" rel="refreshlun"/>
        <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/convert" rel="convert"/>
    </actions>
    <name>OVF_STORE</name>
    <description>OVF_STORE</description>
    <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/disksnapshots" rel="disksnapshots"/>
    <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/permissions" rel="permissions"/>
    <link href="/ovirt-engine/api/disks/b471e8e9-8a80-4ad7-bc75-62775dfd2a7d/statistics" rel="statistics"/>
    <actual_size>68608</actual_size>
    <alias>OVF_STORE</alias>
    <backup>none</backup>
    <content_type>ovf_store</content_type>
    <format>raw</format>
    <image_id>1bd5e52c-fb3d-48a4-9a7c-a4d5d168a135</image_id>
    <propagate_errors>false</propagate_errors>
    <provisioned_size>68608</provisioned_size>
    <shareable>true</shareable>
    <sparse>true</sparse>
    <status>ok</status>
    <storage_type>image</storage_type>
    <wipe_after_delete>false</wipe_after_delete>
    <disk_profile href="/ovirt-engine/api/diskprofiles/dc87f4fe-1c21-4bb1-9152-3835e4cc4325" id="dc87f4fe-1c21-4bb1-9152-3835e4cc4325"/>
    <quota href="/ovirt-engine/api/datacenters/a370dd63-8234-47db-a373-3040ea63f4e1/quotas/309ce2ad-3bc8-4326-9209-e626d95895a0" id="309ce2ad-3bc8-4326-9209-e626d95895a0"/>
    <storage_domains>
        <storage_domain href="/ovirt-engine/api/storagedomains/3ac6c5a1-bc47-42ce-89b5-7182505be26b" id="3ac6c5a1-bc47-42ce-89b5-7182505be26b"/>
    </storage_domains>
</disk>

result:<actual_size>68608</actual_size>

[root@storage-ge-3 b471e8e9-8a80-4ad7-bc75-62775dfd2a7d]# ll
total 1108
-rw-rw----. 1 nobody nobody   68608 Feb 24 14:40 1bd5e52c-fb3d-48a4-9a7c-a4d5d168a135
-rw-rw----. 1 nobody nobody 1048576 Feb 14 13:32 1bd5e52c-fb3d-48a4-9a7c-a4d5d168a135.lease
-rw-r--r--. 1 nobody nobody     423 Feb 24 14:40 1bd5e52c-fb3d-48a4-9a7c-a4d5d168a135.meta


[2]
# cat 1bd5e52c-fb3d-48a4-9a7c-a4d5d168a135.meta
CAP=134217728
CTIME=1644838320
DESCRIPTION={"Updated":true,"Size":68608,"Last Updated":"Thu Feb 24 14:40:41 IST 2022","Storage Domains":[{"uuid":"3ac6c5a1-bc47-42ce-89b5-7182505be26b"}],"Disk Description":"OVF_STORE"}
DISKTYPE=OVFS
DOMAIN=3ac6c5a1-bc47-42ce-89b5-7182505be26b
FORMAT=RAW
GEN=0
IMAGE=b471e8e9-8a80-4ad7-bc75-62775dfd2a7d
LEGALITY=LEGAL
PUUID=00000000-0000-0000-0000-000000000000
TYPE=SPARSE
VOLTYPE=LEAF
EOF



#Gluster
[1]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<disk href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb" id="feff15d3-8cc6-436e-a10f-ba4ba60ce2eb">
    <actions>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/reduce" rel="reduce"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/sparsify" rel="sparsify"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/copy" rel="copy"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/export" rel="export"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/move" rel="move"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/refreshlun" rel="refreshlun"/>
        <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/convert" rel="convert"/>
    </actions>
    <name>OVF_STORE</name>
    <description>OVF_STORE</description>
    <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/disksnapshots" rel="disksnapshots"/>
    <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/permissions" rel="permissions"/>
    <link href="/ovirt-engine/api/disks/feff15d3-8cc6-436e-a10f-ba4ba60ce2eb/statistics" rel="statistics"/>
    <actual_size>47104</actual_size>
    <alias>OVF_STORE</alias>
    <backup>none</backup>
    <content_type>ovf_store</content_type>
    <format>raw</format>
    <image_id>8e0a1831-e7e6-4b24-a638-08cbca344744</image_id>
    <propagate_errors>false</propagate_errors>
    <provisioned_size>47104</provisioned_size>
    <shareable>false</shareable>
    <sparse>true</sparse>
    <status>ok</status>
    <storage_type>image</storage_type>
    <total_size>47104</total_size>
    <wipe_after_delete>false</wipe_after_delete>
    <disk_profile href="/ovirt-engine/api/diskprofiles/40f605bd-1a63-4e1a-8b70-c6f08405f09a" id="40f605bd-1a63-4e1a-8b70-c6f08405f09a"/>
    <quota href="/ovirt-engine/api/datacenters/a370dd63-8234-47db-a373-3040ea63f4e1/quotas/309ce2ad-3bc8-4326-9209-e626d95895a0" id="309ce2ad-3bc8-4326-9209-e626d95895a0"/>
    <storage_domains>
        <storage_domain href="/ovirt-engine/api/storagedomains/ef819e37-986c-4ed9-a3a6-a2c414e3d0c2" id="ef819e37-986c-4ed9-a3a6-a2c414e3d0c2"/>
    </storage_domains>
</disk>

[2]
[root@storage-ge3-vdsm1 feff15d3-8cc6-436e-a10f-ba4ba60ce2eb]# ll
total 1071
-rw-rw----. 1 vdsm kvm   47104 Feb 14 14:32 8e0a1831-e7e6-4b24-a638-08cbca344744
-rw-rw----. 1 vdsm kvm 1048576 Feb 14 13:32 8e0a1831-e7e6-4b24-a638-08cbca344744.lease
-rw-r--r--. 1 vdsm kvm     423 Feb 14 14:32 8e0a1831-e7e6-4b24-a638-08cbca344744.meta

# cat 8e0a1831-e7e6-4b24-a638-08cbca344744.meta
CAP=134217728
CTIME=1644838319
DESCRIPTION={"Updated":true,"Size":47104,"Last Updated":"Mon Feb 14 14:32:03 IST 2022","Storage Domains":[{"uuid":"ef819e37-986c-4ed9-a3a6-a2c414e3d0c2"}],"Disk Description":"OVF_STORE"}
DISKTYPE=OVFS
DOMAIN=ef819e37-986c-4ed9-a3a6-a2c414e3d0c2
FORMAT=RAW
GEN=0
IMAGE=feff15d3-8cc6-436e-a10f-ba4ba60ce2eb
LEGALITY=LEGAL
PUUID=00000000-0000-0000-0000-000000000000
TYPE=SPARSE
VOLTYPE=LEAF
EOF



Expected results:
NFS: Expected size in [1] and [2] should be 68608
Gluster: Expected size in [1] and [2] should be 47104

Actual results:
As expected.

This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022.

Since the problem described in this bug report should be resolved in oVirt 4.5.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.