+++ This bug was initially created as a clone of Bug #1362393 +++ Description of problem: [OVS] - Not possible to sync the ovirtmgmt network once moving from legacy type cluster to ovs type cluster. When moving host from legacy type cluster to ovs type, the management network is out-of-sync because of the legacy/ovs deference, when we trying to sync the management network(press the 'Sync Al Networks' button), the switch type synced with success, but now another parameter is out-of-sync and it's the host QoS. engine report that on the host there is no longer 50 ls configured, although there was before moving from legacy type to ovs. caps on legacy cluster: networks = {'ovirtmgmt': {'addr': '10.35.128.23', 'bridged': True, 'cfg': {'BOOTPROTO': 'dhcp', 'DEFROUTE': 'yes', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'STP': 'off', 'TYPE': 'Bridge'}, 'dhcpv4': True, 'dhcpv6': False, 'gateway': '10.35.128.254', 'hostQos': {'out': {'ls': {'d': 0, 'm1': 0, 'm2': 50}}}, 'iface': 'ovirtmgmt', 'ipv4addrs': ['10.35.128.23/24'], 'ipv6addrs': [], 'ipv6autoconf': False, 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['ens1f0'], 'stp': 'off', 'switch': 'legacy'}} caps after moving to ovs type cluster and before syncing the switch type parameter: networks = {'ovirtmgmt': {'addr': '10.35.128.23', 'bridged': True, 'cfg': {'BOOTPROTO': 'dhcp', 'DEFROUTE': 'yes', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'STP': 'off', 'TYPE': 'Bridge'}, 'dhcpv4': True, 'dhcpv6': False, 'gateway': '10.35.128.254', 'hostQos': {'out': {'ls': {'d': 0, 'm1': 0, 'm2': 50}}}, 'iface': 'ovirtmgmt', 'ipv4addrs': ['10.35.128.23/24'], 'ipv6addrs': [], 'ipv6autoconf': False, 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['ens1f0'], 'stp': 'off', 'switch': 'legacy'}} caps after syncing the switch type parameter: networks = {'ovirtmgmt': {'addr': '10.35.128.23', 'bond': '', 'bridged': True, 'dhcpv4': True, 'dhcpv6': False, 'gateway': '10.35.128.254', 'iface': 'ovirtmgmt', 'ipv4addrs': ['10.35.128.23/24'], 'ipv6addrs': [], 'ipv6autoconf': False, 'ipv6gateway': '::', 'mtu': 1500, 'netmask': '255.255.255.0', 'nics': ['ens1f0'], 'ports': ['ens1f0'], 'stp': False, 'switch': 'ovs'}} the host QoS parameter is no longer reported in caps and this is why network considered as out-of-sync Version-Release number of selected component (if applicable): 4.0.2.3-0.1.el7ev vdsm-4.18.9-1.el7ev.x86_64 openvswitch-2.4.1-1.git20160727.el7_2.x86_64 How reproducible: 100 Steps to Reproduce: 1. Add host to rhev-m 4.0.2 to legacy type cluster 2. Create ovs type cluster and move the host to this cluster(maintenance) 3. Sync the network/s on host Actual results: ovirtmgmt network is still reported as out-of-sync, cause of the host QoS(ls=50) parameter Expected results: management network should be synced --- Additional comment from Michael Burman on 2016-08-02 02:47:38 EDT --- When moving the host back to legacy type cluster we still can't sync back the host QoS parameter. --- Additional comment from Michael Burman on 2016-08-02 07:14:19 EDT --- This is seems to be the lack of host QoS support in the native ovs feature. --- Additional comment from Red Hat Bugzilla Rules Engine on 2016-08-04 08:41:16 EDT --- Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
*** This bug has been marked as a duplicate of bug 1362393 ***
See BZ 1362393
verification failed because we did not make sure we use ovs with a fix for bug 1397050. I hope we can retry in the future, but currently this bug is deferred.