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

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-06-06 03:45:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: 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):

How reproducible:

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 2016-05-23 09:21:17 EDT
oVirt 4.0 beta has been released, moving to RC milestone.
Comment 4 Yaniv Lavi 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.
Comment 6 Yaniv Lavi 2018-06-06 03:45:23 EDT
Closing old RFEs, please reopen if still needed.
Patches are always welcomed.

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