Description of problem: When converting from Raw-preallocated-incremental_disabled to Cow-Thin-incremental_enabled, the actual size becomes bigger than the provisioned size. When converting to a Thin disk we expect the size to be smaller than the actual size, but instead, the disk gets bigger after the disk convert. This happens only on block storage type. Version-Release number of selected component (if applicable): ovirt-engine-4.5.1.3-654.af4ac851f145.33.el8ev.noarch vdsm-4.50.2-1.el8ev How reproducible: 100% Steps to Reproduce: 1. Create a disk with API request: {{ENV_Hostname}}/api/disks <disk> <storage_domains> <storage_domain id="{{ISCSI_SD}}"/> </storage_domains> <name>ISCSI_Raw-Preallocated-Disabled</name> <provisioned_size>1073741824</provisioned_size> <format>raw</format> <sparse>false</sparse> <backup>None</backup> </disk> 2. wait until the disk is in ok status and convert with the following request {{ENV_Hostname}}/api/disks/{{ISCSI_Raw-Preallocated-Disabled}}/convert <action> <disk> <format>cow</format> <sparse>true</sparse> <backup>incremental</backup> </disk> </action> Actual results: Before the convert: <actual_size>1073741824</actual_size> <provisioned_size>1073741824</provisioned_size> After the disk convert: <actual_size>1207959552</actual_size> <provisioned_size>1073741824</provisioned_size> Expected results: After the diskconvert: The actual size should be smaller than the provisioned size since the disk was converted when it was empty. Additional info: Actually, this bug fix (https://bugzilla.redhat.com/show_bug.cgi?id=2076047) leads to this situation In order to avoid this, I suggest two steps of conversion in such a scenario. For example: First, convert the format type and then the allocation policy from preallocated to Sparse.
(In reply to sshmulev from comment #0) > Expected results: > After the diskconvert: > The actual size should be smaller than the provisioned size since the disk > was converted when it was empty. Benny, is it a fair assumption? note that the disk was raw+preallocated - does qemu-img check if the blocks are empty or not? I doubt it and if it doesn't then having actual size > provisioned size (due to the metadata) makes sense..
i guess you can sparsify before/after?
(In reply to Michal Skrivanek from comment #2) > i guess you can sparsify before/after? Right, Benny and I discussed that offline and concluded we'll add that to the documentation of the API that sparsify can be executed afterwards in this case
This bug has low overall severity and is not going to be further verified by QE. If you believe special care is required, feel free to properly align relevant severity, flags and keywords to raise PM_Score or use one of the Bumps ('PrioBumpField', 'PrioBumpGSS', 'PrioBumpPM', 'PrioBumpQA') in Keywords to raise it's PM_Score above verification threashold (1000).
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.
It was suggested to convert this case into two separate converts: First, convert the format type and then the allocation policy from preallocated to Sparse. We made this WA to our automation according to this suggestion, since this issue was not closed for the next release. Many builds have passed successfully, but lately, we have seen an issue with this type of conversion: The issue is the size of the disk after the convert The disk is: raw, sparse-False Convert disks format + allocation policy. convert supposed to be : raw/sparse False -> cow/sparse True This one succeeded, the disk changed the types of format and allocation policy, although the size is not as expected for sparse: actual_size after convert should be smaller than the provisioned_size. In this case, it is bigger, why? Before convert: <actual_size>5368709120</actual_size> <sparse>false</sparse> <format>raw</format> <provisioned_size>5368709120</provisioned_size> After convert: <actual_size>6039797760</actual_size> <sparse>true</sparse> <format>cow</format> <provisioned_size>5369757696</provisioned_size>