Description of problem: Version-Release number of selected component (if applicable): rhv-log-collector-analyzer-0.2.16-0.el7ev.noarch How reproducible: everytime Steps to Reproduce: 1. set size of the image to wrong value 2. run rhv-image-discrepancies Actual results: image 403d7f53-3f04-4cbd-aafb-93f32151aa54 has a different attribute capacity on storage(962592768) and on DB(1073741824) engine=# select storage_id,image_group_id, image_guid,size from all_disks_including_snapshots where disk_alias='CentOS-7-x86_64-Minimal-1810.iso'; storage_id | image_group_id | image_guid | size --------------------------------------+--------------------------------------+--------------------------------------+----------- 6814fac1-2e9a-4ab3-bbfe-02a14c2049fe | 700ba928-dfba-4242-866e-1c0b7a205e3b | 403d7f53-3f04-4cbd-aafb-93f32151aa54 | 962592768 # su vdsm -s /bin/sh -c 'qemu-img info /dev/6814fac1-2e9a-4ab3-bbfe-02a14c2049fe/403d7f53-3f04-4cbd-aafb-93f32151aa54' image: /dev/6814fac1-2e9a-4ab3-bbfe-02a14c2049fe/403d7f53-3f04-4cbd-aafb-93f32151aa54 file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 Expected results: the values will be displayed correctly as below: image 403d7f53-3f04-4cbd-aafb-93f32151aa54 has a different attribute capacity on storage(1073741824) and on DB(962592768) Additional info:
Hi Germano, Could you please review this report?
Humpf, they are all inverted, not just size: print("\timage {} has a different attribute {} on storage({}) and on DB({})".format( image, key, db_value, sd_value) ) I'll send a fix along with some other improvements I'm planning after switching to the new sd dump api.
https://code.engineering.redhat.com/gerrit/gitweb?p=rhv-log-collector-analyzer.git;a=commit;h=f5378e14543217f2e74dfe3e64976f7cfdef5c39
Douglas, is the 4.4.z analyser based on the master branch? Shall we raise 4.4.z flag?
(In reply to Germano Veit Michel from comment #4) > Douglas, is the 4.4.z analyser based on the master branch? > > Shall we raise 4.4.z flag? Sure, let's get all acks. (devel, qe, pm)
Verified on: ovirt-engine-4.4.3.8-0.1.el8ev.noarch rhv-log-collector-analyzer-1.0.5-1.el8ev.noarch Steps: 1. set a wrong size value for a random img on db engine=# update images set size = 10000000000 where image_guid='ad116098-16a1-40f5-999e-0a1997ef93f0'; engine=# select storage_id,image_group_id, image_guid,size from all_disks_including_snapshots where image_guid='ad116098-16a1-40f5-999e-0a1997ef93f0'; storage_id | image_group_id | image_guid | size ----------------------------------------------------------------------------------------------------------------+--------------------------------------+--------------------------------------+------------- c9b18e61-7a79-4f36-9348-686cae48a946,aaa103b6-a9f3-4957-89e4-1951daf8d7f7,bccc676d-0602-44b6-927e-42c9c91d132f | f0f4aa50-ac3e-4fac-8cba-31a88a8d8ee4 | ad116098-16a1-40f5-999e-0a1997ef93f0 | 10000000000 (1 row) 2. checked real img size sh-4.4$ qemu-img info /rhev/data-center/mnt/<nfs_export>/aaa103b6-a9f3-4957-89e4-1951daf8d7f7/images/f0f4aa50-ac3e-4fac-8cba-31a88a8d8ee4/ad116098-16a1-40f5-999e-0a1997ef93f0 image: /rhev/data-center/mnt/<nfs_export>/aaa103b6-a9f3-4957-89e4-1951daf8d7f7/images/f0f4aa50-ac3e-4fac-8cba-31a88a8d8ee4/ad116098-16a1-40f5-999e-0a1997ef93f0 file format: qcow2 virtual size: 10 GiB (10737418240 bytes) disk size: 1.93 GiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false 3. # rhv-image-discrepancies ... Image ad116098-16a1-40f5-999e-0a1997ef93f0 has a different attribute capacity on storage(10737418240) and on DB(10000000000) ... Results: size values displayed by rhv-image-discrepancies correctly matching their sources
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Low: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5179
Due to QE capacity we are not going to cover this issue in our automation