Created attachment 995256 [details]
Description of problem:
SetupNetworks > Engine blocking from attaching VM/non VM vlan tagged network with Host QoS configured.
When trying to approve operation via SN:
Error while executing action:
Cannot setup Networks. All or none of the networks attached to an interface must have QoS configured, but on the following interface(s) some of the networks are missing QoS: enp6s0.
2015-02-25 17:18:37,077 WARN [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand] (ajp--127.0.0.1-8702-11) [564d487a] CanDoAction of action 'SetupNetworks' failed for user admin@internal. Reasons: VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,ACTION_TYPE_FAILED_HOST_NETWORK_QOS_INTERFACES_WITHOUT_QOS,$ACTION_TYPE_FAILED_HOST_NETWORK_QOS_INTERFACES_WITHOUT_QOS_LIST enp6s0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create VM/non VM vlan tagged network with Host QoS configured.
2. Try to attach vlan network to NIC
Operation canceled with a wrong error message.
Operation should succeed.
Created attachment 995259 [details]
Engine seems to mistakenly think the interface is shared by other networks, even though the VLAN network is alone there - so shouldn't be any issue (since QoS is configured on all the networks on the interface).
Is this relevant in the new API as well ?
(In reply to Barak from comment #3)
> Is this relevant in the new API as well ?
The bug is in-
It uses- 'NetworkUtils.qosConfiguredOnInterface(iface, network)' to find out whether a the iface has qos configured on it.
- For the 'baseNic' the 'NetworkUtils.qosConfiguredOnInterface(iface, network)' return false, since there is no network on it (the network is null).
- For the 'baseNic.vlan' the the method return true since it has qos.
So 'validateQosNotPartiallyConfigured' considers the qos as partially configured on the nic.
The fix should be that in case there is no network on the nic, it shouldn't be taken in account when validating if the qos in partially configured on then ic.
Verified on - rhevm-3.6.0-0.18.el6.noarch with vdsm-4.17.8-1.el7ev.noarch
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.