Red Hat Bugzilla – 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
Last modified: 2016-02-10 14:16:20 EST
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):
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
All setup networks commands will fail until i will take care the unsynced network
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.
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)
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.
- 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,
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.
As agreed, we need to discuss this with Meni and Danken .
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".