Bug 1303407 - [RFE][HostQoS] - modify hostQoS of existing networks instead of reconfiguring the network
Summary: [RFE][HostQoS] - modify hostQoS of existing networks instead of reconfiguring...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: vdsm
Classification: oVirt
Component: Core
Version: 4.17.19
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Edward Haas
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-31 13:52 UTC by Michael Burman
Modified: 2018-06-06 07:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 07:45:23 UTC
oVirt Team: Network
Embargoed:
ylavi: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 53548 0 master ABANDONED net: Apply Host QoS changes on the fly 2016-07-31 01:58:17 UTC

Description Michael Burman 2016-01-31 13:52:44 UTC
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 15:28:19 UTC
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 10:06:23 UTC
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 13:21:17 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 4 Yaniv Lavi 2016-05-23 13:24:12 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 5 Edward Haas 2017-08-16 07:32:36 UTC
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 07:45:23 UTC
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.