Bug 1269167 - Setup Network operations will fail if one of the networks has been changed(vlan for example) and can't be synced back to host
Setup Network operations will fail if one of the networks has been changed(vl...
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network (Show other bugs)
x86_64 Linux
unspecified Severity medium (vote)
: ovirt-4.0.0-alpha
: ---
Assigned To: nobody nobody
Michael Burman
Depends On:
  Show dependency treegraph
Reported: 2015-10-06 09:43 EDT by Michael Burman
Modified: 2016-02-10 14:16 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-10 07:02:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑4.0.0?
rule-engine: planning_ack?
mburman: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Michael Burman 2015-10-06 09:43:39 EDT
Description of problem:
Setup Network operations will fail if one of the networks has been changed(vlan for example or any other change) and can't be synced to back to host.

For example -->
2 networks attached to 1 NIC
1 vlan network
1 VM network
If changing the vlan network to be VM network, setup network command will sent and fail to sync the network to host. From here, any change that i will try to perform via Setup networks window i will fail with error:
Error while executing action: 

Cannot setup Networks. At most one VLAN-untagged Logical Network is allowed on a NIC (optionally in conjunction with several VLAN Logical Networks). The following Network Interfaces violate that : enp6s0. 

Until i will take care the unsynced network all of the setup networks commands will fail because the cannot do action of 2 VM networks on 1 NIC. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. 2 networks attached to 1 NIC - 1 vlan network and 1 VM network
2. Change and edit the vlan network to be non-vlan
3. Try to perform some other Setup Networks operations

Actual results:
All setup networks commands will fail until i will take care the unsynced network

Expected results:
Such operations should be blocked by engine. If i'm changing the network to be non-vlan, engine should recognize that this network can't live together with the other VM network on host and block the change.
- This could happen as well with changing to not supported MTU as well and cause such behavior. Such scenario should be blocked as well.
Comment 1 Barak 2015-10-21 05:42:53 EDT
Sorry this bug is entirely unclear.
Please use the axact dialogs you used specify exactly what butten pressed.
And what exactly failed (and at what point of time)
Comment 2 Michael Burman 2015-10-21 08:07:49 EDT
Hi Barak,

Ok, i will try to make it clearer :

1) Create 1 VM network 'net-1' via Networks tab (press 'ok' to approve operation)
2) Create 1 VM vlan 'net-2' tagged network via Networks tab(press 'ok' to approve operation)
3) Attach both networks to 1 NIC on host via the Setup Networks dialog and approve operation
4) Via the Networks tab, edit 'net-2' (the vlan network) to be non-vlan network and press 'ok' to approve operation.

Results -->
- Setup networks command is sent to host, but failed, because 2 non-vlan networks can't live together.  
- 'net-2' network now considered as unsynced network and reported as 'out-of-sync' in the 'out-of-sync' column and in the setup networks dialog. 
There is now a difference on the vlan property for 'net-2' network between DC and HOST.

* So the problem is that step 4 wasn't blocked by engine like we would like it to behave. Engine should recognize that performing action like on step 4 should be blocked, because 2 non-vlan networks can't live together on 1 NIC.
And because step 4 wasn't blocked by engine, we have now situation on which 'net-2' is unsynced and we can't perform any other setup network operation on the host and we can't sync both networks. 
All we can do is detach 'net-2 from host or to edit it back to vlan network. 

Hope this was much clearer, 
Comment 3 Alona Kaplan 2015-12-06 09:32:53 EST
Hi Michael,

I don't understand why do you think step 4 should be blocked.
What if the network is used by multiple hosts, do you think that if the 'setupNetworks' operation may fall on one of the host the vlan change of the network should be blocked?

When changing a property like 'vlanId' on the network two actions are performed-
1. Changing the vlan of the network.
2. Updating all the hosts that are using the network.

Step 2 can fail on a specific host for multiple reasons- can do action failure, host that is down or any other reason. That doesn't mean that step 1 and step 2 for all the other hosts should be blocked.

And also, the setup networks of the host with the unsync network is not blocked. Only updates on the nic that contains the problematic network are block. You can do changes on the other nics.
Comment 4 Michael Burman 2015-12-06 10:43:26 EST
Hi Alona, 

As agreed, we need to discuss this with Meni and Danken .
Comment 5 Dan Kenigsberg 2015-12-10 07:02:05 EST
As far as I understand, multi-host networking action behaves as planned. We should not fail the action on the whole DC just because one of the hosts has a conflicting local configuration.

such host ends up with a network in an out-of-sync state, to be solved manually by the user (by forcing Sync or removing an offending config).

I would not like to add another validation, unless many customers complain, as we are commonly asked "not to nanny the user".

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