Bug 1643486

Summary: Wrong 'maxBandwidth' sent to vdsm on migration
Product: Red Hat Enterprise Virtualization Manager Reporter: Miguel Martin <mmartinv>
Component: ovirt-engineAssignee: Milan Zamazal <mzamazal>
Status: CLOSED ERRATA QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.6CC: bugs, lsvaty, mzamazal, nobody, rbarry, Rhev-m-bugs, sborella
Target Milestone: ovirt-4.3.2Flags: lsvaty: testing_plan_complete-
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
This release ensures the value of the migration bandwidth limit is correct.
 Story Points: ---
Clone Of: 1643476 Environment:
Last Closed: 2019-05-08 12:38:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1643476    
Bug Blocks:    

Description Miguel Martin 2018-10-26 11:21:16 UTC 
+++ This bug was initially created as a clone of Bug #1643476 +++

Description of problem:

According to the'Table 5.4. Bandwidth Explained' documentation [1]:
~~~
Defined by user (in Mbps). This value is divided by the number of concurrent migrations (default is 2, to account for ingoing and outgoing migration). Therefore, the user-defined bandwidth must be large enough to accommodate all concurrent migrations.

For example, if the Custom bandwidth is defined as 600 Mbps, a virtual machine migration’s maximum bandwidth is actually 300 Mbps. 
~~~

According to the 'lib/vdsm/api/vdsm-api.yml':
~~~
 3312   ┆ ┆ ┆ -   defaultvalue: needs updating                                                                                                                                                              
 3313   ┆ ┆ ┆ ┆ ┆ description: maximal bandwidth used by the migration (MiB/s)                                                                                                                              
 3314             name: maxBandwidth                                                                                                                                                                        
 3315   ┆ ┆ ┆ ┆ ┆ type: int                                                                                                                                                                                 
 3316   ┆ ┆ ┆ ┆ ┆ added: '4.0'                                                                                                                                                                              
 3317                                                                                                                                                         
~~~

The engine is sending the migration bandwidth limit as Mbps but the vdsm interprets it as MiB/s.

[1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/sect-cluster_tasks#Cluster_Migration_Policy_Settings_Explained

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

How reproducible:
Always

Steps to Reproduce:
1. Configure the cluster's migration policy and set the migration bandwidth limit to 10 Mbps

Actual results:
The actual bandwidth consumed is 40Mbps

Expected results:
According to the documentation, and with a max concurrent migrations equals to 2, the actual bandwidth consumed should be 5Mbps.
Comment 1 RHV bug bot 2018-12-10 15:13:37 UTC 
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops
Comment 2 meital avital 2019-01-07 10:02:52 UTC 
Reassigned:
ovirt-engine-4.3.0-0.4.master.20181230173049.gitef04cb4.el7.noarch
qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64
vdsm-4.30.4-81.gitad6147e.el7.x86_64
libvirt-client-4.5.0-10.el7_6.3.x86_64

When setting migration bandwidth limit to 10Mbps, the actual value in source host  virsh domjobinfo is: Memory bandwidth: 52.016 MiB/s

Observing REST API  /ovirt-engine/api/clusters/ shows that the 10Mbps value was set successfully:
      <bandwidth>
        <assignment_method>custom</assignment_method>
        <custom_value>10</custom_value>
      </bandwidth>

Also, need UI fix, the value in Webadmin edit cluster dialog, migration policy => migration bandwidth limit is in Mbps instead of MiB/s
Comment 3 Ryan Barry 2019-01-21 14:54:34 UTC 
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
Comment 5 Milan Zamazal 2019-01-21 15:05:55 UTC 
Based on the discussion in in bug 1643476, moving back to MODIFIED.
Comment 6 meital avital 2019-01-22 09:59:33 UTC 
Verified on:
ovirt-engine-4.3.0-0.4.master.20181230173049.gitef04cb4.el7.noarch
qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64
vdsm-4.30.4-81.gitad6147e.el7.x86_64
libvirt-client-4.5.0-10.el7_6.3.x86_64
Comment 7 RHV bug bot 2019-02-21 17:26:29 UTC 
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops
Comment 9 Raz Tamir 2019-03-05 21:30:32 UTC 
QE verification bot: the bug was verified upstream
Comment 11 errata-xmlrpc 2019-05-08 12:38:43 UTC 
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, 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/RHEA-2019:1085
Comment 12 Daniel Gur 2019-08-28 13:13:28 UTC 
sync2jira
Comment 13 Daniel Gur 2019-08-28 13:17:41 UTC 
sync2jira