Description of problem: Customer is testing after_network_setup hook which integrates with setupNetworks api. It was noticed that a remove nework action by vdsm caues the main bond interface to go down up. This occurs even when the host is Active. Causing interruptions to guest network traffic is not desired. I think the correct behavior should be similar to the path taken by the rhevm-shell 'remove nic ...': [RHEVM shell (connected)]# action nic bond0.3456 detach --host-identifier lb0145 error: status: 409 reason: Conflict detail: Cannot edit Network while Host is Active, change the Host to Maintenance mode and try again. Version-Release number of selected component (if applicable): 3.3.0 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Reproducer Steps Hypervisor / host setup with bond0 having p1p1 and p1p2 NICs. Add one or more networks to bond0 via your preferred method. Without other scripts the easiest way to test the setupNetworks() API right now is to use the GUI. Ensure your host is active/Up. Add a new test network to your datacenter and cluster, then add this to the hypervisor that's your test subject. Next use the Host -> Network Interfaces -> Setup Host Networks dialog(this uses the setupNetworks() API) to remove the test network. Now observe the supervdsm log on the hypervisor. Alternatively, have a network test active on one of the other networks during the removal action and you'll see packets lost.
This bug seems like the twin of bug 982632 - Configuring a vlanned network over an existing and used interface takes down the interface
It does look like a twin of bug 982632 but as that shows fixed and customer saw this with 3.3.0 GA it seems there is still an issue here to be worked out.
I was not alluding that it was an identical twin: bug 982632 spoke about adding network, and this one - about removing them.
Shouldn't this get zstream'd, seems like a bad bug to me
works on av2.1 [root@dell-r210ii-08 ~]# rpm -q vdsm vdsm-4.14.5-0.el6.x86_64 no packet loss while removing one VLAN from top of bond with multiple VLANs
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0504.html