Bug 1993839

Summary: [RFE] Move volume_utilization_chunk_mb from vdsm to engine
Product: [oVirt] ovirt-engine Reporter: Benny Zlotnik <bzlotnik>
Component: BLL.StorageAssignee: Pavel Bar <pbar>
Status: CLOSED DUPLICATE QA Contact: Avihai <aefrat>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.8CC: ahadas, bugs, michal.skrivanek
Target Milestone: ---Keywords: FutureFeature, ZStream
Target Release: ---Flags: sbonazzo: ovirt-4.5-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-20 11:56:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Benny Zlotnik 2021-08-16 08:52:35 UTC
Description of problem:
Since we started using qemu-img measure to determine the size of the target volume when copying, the target initial size might be too small depending on the amount of data written, this may lead to forcing extension very quickly which may pause the VM

Patch[1] attempts to alleviate the situation by adding at least 1GB to the initial size, but a better solution would be to use volume_utilization_chunk_mb instead, this value is currently set in vdsm. By moving it to the engine users would no longer need to set it separately on each host and the initial size would correctly match custom sizes that were tested and tuned by users instead of the default 1GB

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
[1] https://gerrit.ovirt.org/c/ovirt-engine/+/111978

[2] https://github.com/oVirt/vdsm/blob/d0d9758197996c636ad328145f9999a7595064a2/lib/vdsm/common/config.py.in#L331

Comment 3 Sandro Bonazzola 2022-03-29 16:16:40 UTC
We are past 4.5.0 feature freeze, please re-target.

Comment 4 Michal Skrivanek 2022-04-20 11:56:03 UTC
with thin provisioning improvements in bug 2051997 and followup improvements in 4.5.0 this is not really needed

Comment 5 Arik 2022-04-24 19:48:17 UTC

*** This bug has been marked as a duplicate of bug 1958032 ***