Bug 1303407 - [RFE][HostQoS] - modify hostQoS of existing networks instead of reconfiguring the network
[RFE][HostQoS] - modify hostQoS of existing networks instead of reconfiguring...
Status: NEW
Product: vdsm
Classification: oVirt
Component: Core (Show other bugs)
4.17.19
x86_64 Linux
medium Severity medium (vote)
: ovirt-4.3.0
: ---
Assigned To: Edward Haas
Michael Burman
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-31 08:52 EST by Michael Burman
Modified: 2017-08-16 04:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.3+
ylavi: planning_ack+
danken: devel_ack+
myakove: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 53548 master ABANDONED net: Apply Host QoS changes on the fly 2016-07-30 21:58 EDT

  None (edit)
Description Michael Burman 2016-01-31 08:52:44 EST
Description of problem:
[HostQoS] - Vdsm recognizes a change in hostQoS every reboot.

ifcfg doesn't persist hostQoS at all and initscripts can't handle it during the boot process. 
Because of that vdsm will recognize a change every reboot for network that was configured with host QoS and will touch it during the reboots.

supervdsm.log -->
 
restore-net::INFO::2016-01-31 12:58:05,486::vdsm-restore-net-config::265::root::(_find_changed_or_missing) qosvlan2 is different or missing from persistent configuration. current: {'vlan': '168', 'nic': 'enp12s0f1
', 'dhcpv6': False, 'mtu': '1500', 'bootproto': 'none', 'stp': False, 'bridged': True, 'defaultRoute': False}, persisted: {'dhcpv6': False, u'bridged': True, u'nic': u'enp12s0f1', u'vlan': '168', u'mtu': '1500', '
bootproto': 'none', 'stp': False, u'hostQos': {u'out': {u'rt': {u'm2': 400000000}, u'ul': {u'm2': 500000000}, u'ls': {u'm2': 70}}}, 'defaultRoute': False}

restore-net::INFO::2016-01-31 13:10:33,953::vdsm-restore-net-config::261::root::(_find_changed_or_missing) n3 is different or missing from persistent configuration. current: {'nic': 'ens1f1', 'dhcpv6': False, 'mtu': '1500', 'bootproto': 'none', 'stp': False, 'bridged': True, 'defaultRoute': False}, persisted: {u'hostQos': {u'out': {u'rt': {u'm2': 400000000}, u'ul': {u'm2': 500000000}, u'ls': {u'm2': 60}}}, u'nic': u'ens1f1', 'dhcpv6': False, u'mtu': '1500', 'bootproto': 'none', 'stp': False, u'bridged': True, 'defaultRoute': False}


Version-Release number of selected component (if applicable):
vdsm-4.17.19-0.el7ev.noarch
3.6.3-0.1.el6

How reproducible:
100

Steps to Reproduce:
1. Attach network with hostQoS configured to host via Setup Networks
2. Reboot server 

Actual results:
vdsm recognize a change in hostQoS and touch the network during the boot

Expected results:
vdsm shouldn't recognize a change between the current and persistent on network with hostQoS configured. vdsm should handle this.
Comment 1 Dan Kenigsberg 2016-01-31 10:28:19 EST
Vdsm's recognition that initiscript has not configured hostQoS on the network is *not* a bug. It is the right thing for Vdsm to do, since initscripts has no facilities for setting ovirt-style hostQoS.

The only issue here is that Vdsm should simply add the missing hostQoS, and not drop the network and re-add it.
Comment 2 Sandro Bonazzola 2016-05-02 06:06:23 EDT
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Comment 3 Yaniv Lavi (Dary) 2016-05-23 09:21:17 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 4 Yaniv Lavi (Dary) 2016-05-23 09:24:12 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 5 Edward Haas 2017-08-16 03:32:36 EDT
This is in fact a RFE that can handle other on-the-fly settings and not be limited by QoS config.

I suggest we revisit this feature as part of the new suggested VDSM networking setup flow.

Note You need to log in before you can comment on or make changes to this bug.