Bug 2018971

> This bug will be fixed together with the option to configure the initial
> size for block-based scratch disks and can be tested by setting the
> 'BackupBlockScratchDiskInitialSizePercents' configuration value to 100%.

bug 2018986

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

How to reproduce and verify:

Steps to Reproduce:

Raw disk:
1. Start vm with 10g raw disk
2. Start backup
3. Verify that scratch disk initial size should be 11g
   (we allocate about 1g extra for qcow2 metadata)

Qcow2 disk based on a template:
1. Start VM with qcow2 disk based on template
2. Start backup
3. Verify that scratch disk initial size is 1g more than the size reported
   by qemu-img measure.

To measure the disk you can use:

    # virsh -r dumpxml vm-name

find the disk path in the xml, measure the disk with qemu-img measure

    # qemu-img measure -O qcow2 /path/to/disk/from/xml
    ...
    required: 2684354560

(this is only an example, your actual disk may be smaller or larger)

Add 1g:

    2684354560 + 1073741824 * 1.1 = 4133906022

Get the backup xml:

    # virsh -r backup-dumpxml vm-name

Find the scratch disk path in the xml

    /rhev/data-center/mnt/blockSD/domain-id/images/disk-id/volume-id

Check the size of the logical volume:

    # lvs domain-id/volume-id

The size should be 3.875g.

Version:
ovirt-engine-4.4.10-0.17.el8ev.noarch / vdsm-4.40.100.1-1.el8ev.x86_64

For the raw disk flow, everything works as expected.
For the QCOW disk on block storage, we need also to round up the volume size to a multiply of 128 mib.

Verification flow for qcow2:

1. Set MaxBackupBlockScratchDiskInitialSizePercents to 100% and MinBackupBlockScratchDiskInitialSizeInGB to 1. (via vdsm run - <engine-config -s "MaxBackupBlockScratchDiskInitialSizePercents=100">)
2. Start VM with qcow2 disk based on a template.
3. Start backup - via API
4. Use <virsh -r dumpxml vm-name> on vdsm to find the disk path in the XML. 
5. For the disk of the template I got the following size: 

# qemu-img measure -O qcow2 /rhev/data-center/mnt/blockSD/d106a99f-ed75-4a3f-b50c-6bd002bede3a/images/0e291e06-5089-4321-ad1a-e63200488b8f/3277f5e3-c351-44e0-821f-d452b85eab4d
required size: 3385655296
fully allocated size: 10739318784
bitmaps size: 0

5. Then I used virsh in order to reach the relevant "scratch disk" path.
6. Used command: <vdsm-client StorageDomain dump sd_id=d106a99f-ed75-4a3f-b50c-6bd002bede3a | grep -A 16 018a92c1-c9bd-480e-91ac-df04450f7e58> via vdsm to find the size of the logical volume


        "018a92c1-c9bd-480e-91ac-df04450f7e58": {
            "apparentsize": 4966055936,
            "capacity": 10737418240,
            "ctime": 1638782825,
            "description": "{\"DiskAlias\":\"VM test1100 backup 31f88ccd-7670-469e-b2dc-eb111e6c6820 scratch disk for latest-rhel-guest-image-8.5-infra\",\"DiskDescription\":\"Backup 31f88ccd-7670-469e-b2dc-eb111e6c6820 scratch disk\"}",
            "disktype": "SCRD",
            "format": "COW",
            "generation": 0,
            "image": "11f63d5c-f276-4a30-8223-2c15090fa116",
            "legality": "LEGAL",
            "mdslot": 10,
            "parent": "00000000-0000-0000-0000-000000000000",
            "status": "OK",
            "truesize": 4966055936,
            "type": "SPARSE",
            "voltype": "LEAF"
        },


Summary of disk sizes and calculations:

required size: 3385655296
expected size: (3385655296 + 1073741824) * 1.1 -> 4905336832
actual size:   4966055936

If you round up 4905336832 to a mutiply of 128 MiB:

>>> 4905336832 / (128 * 1024**2)
36.547607421875
>>> 37 * (128 * 1024**2)
4966055936 - as expected

Verification Conclusions:
The sizes of the generated scratch disks were correct.

Bug verified.

This bugzilla is included in oVirt 4.4.10 release, published on January 18th 2022.

Since the problem described in this bug report should be resolved in oVirt 4.4.10 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.

Added Polarion test plan: RHEVM 27932