Bug 1060781

Summary:	The remove network action by vdsm causes the main bond interface to go down up
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Dave Sullivan <dsulliva>
Component:	vdsm	Assignee:	Antoni Segura Puimedon <asegurap>
Status:	CLOSED ERRATA	QA Contact:	Martin Pavlik <mpavlik>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.3.0	CC:	bazulay, danken, dsulliva, iheim, lbopf, lpeer, mkalinin, mpavlik, myakove, nyechiel, oblaut, yeylon
Target Milestone:	---	Keywords:	Triaged, ZStream
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	network
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.	Story Points:	---
Clone Of:
Clones:	1072407 (view as bug list)		Environment:
Last Closed:	2014-06-09 13:28:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1072407, 1078909, 1142926

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


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:

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
vdsm-4.14.5-0.el6.x86_64

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.

http://rhn.redhat.com/errata/RHBA-2014-0504.html