Bug 1060781 - The remove network action by vdsm causes the main bond interface to go down up
Summary: The remove network action by vdsm causes the main bond interface to go down up
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.4.0
Assignee: Antoni Segura Puimedon
QA Contact: Martin Pavlik
Whiteboard: network
Depends On:
Blocks: 1072407 rhev3.4beta 1142926
TreeView+ depends on / blocked
Reported: 2014-02-03 15:32 UTC by Dave Sullivan
Modified: 2019-04-28 10:06 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Removing a network no longer causes VDSM to take the main bond interface down. Previously, removing a network caused VDSM to take the main bond interface down, and that caused a short loss of communication for the networks using the bond interface. The bond interface is put into a down state now only if it is meant to stay down or be removed.
Clone Of:
: 1072407 (view as bug list)
Last Closed: 2014-06-09 13:28:56 UTC
oVirt Team: Network
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0504 normal SHIPPED_LIVE vdsm 3.4.0 bug fix and enhancement update 2014-06-09 17:21:35 UTC
oVirt gerrit 25003 'None' 'MERGED' 'ifcfg: Do not take bond/nic down when removing one of their multiple nets' 2019-11-22 10:38:20 UTC

Description Dave Sullivan 2014-02-03 15:32:57 UTC
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

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):


How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 2 Dave Sullivan 2014-02-03 16:44:36 UTC
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.

Comment 3 Dan Kenigsberg 2014-02-03 18:32:30 UTC
This bug seems like the twin of bug 982632 - Configuring a vlanned network over an existing and used interface takes down the interface

Comment 4 Dave Sullivan 2014-02-11 13:58:49 UTC
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.

Comment 5 Dan Kenigsberg 2014-02-11 17:10:38 UTC
I was not alluding that it was an identical twin: bug 982632 spoke about adding network, and this one - about removing them.

Comment 6 Dave Sullivan 2014-02-24 20:32:20 UTC
Shouldn't this get zstream'd, seems like a bad bug to me

Comment 13 Martin Pavlik 2014-03-13 10:00:32 UTC
works on av2.1
[root@dell-r210ii-08 ~]# rpm -q vdsm

no packet loss while removing one VLAN from top of bond with multiple VLANs

Comment 14 errata-xmlrpc 2014-06-09 13:28:56 UTC
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.


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