Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1093046

Summary: Host doesn't become non-operational when required network bridge isn't connected to any interface
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: ovirt-engineAssignee: Barak <bazulay>
Status: CLOSED CURRENTRELEASE QA Contact: GenadiC <gcheresh>
Severity: low Docs Contact:
Priority: low    
Version: 3.4.0CC: bazulay, danken, gklein, lpeer, mburman, myakove, nyechiel, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone: ovirt-3.6.0-rcKeywords: Reopened
Target Release: 3.6.0Flags: ylavi: Triaged+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 3.6.0-0.0.master.20150412172306.git55ba764.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-20 01:11:49 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:
Attachments:
Description Flags
vdscaps file
none
vdsstats file
none
vdsm log none

Description GenadiC 2014-04-30 13:21:55 UTC
Description of problem:
If you remove the required network from the Host, it will stay operational, thought should change the state to non-operational.
Host will become non-operational only if you put that host to maintenance and reactivate it again

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


How reproducible:
Always

Steps to Reproduce:
1. Put the required network on Host
2. Remove that network from Host
3. Wait for several minutes

Actual results:
Host stays in operational state

Expected results:
Host should become non-operational after 5 minutes

Additional info:

Comment 1 Moti Asayag 2014-04-30 21:06:21 UTC
With current implementation, host monitoring only concerns the health of the nics reported by VDSM, on which a required network is configured.

A missing required network will be detected by the getCapabilities, which invoked each time a network command was engaged or when a host is activated.

Bug 999947 ([RFE] Refresh Network configuration periodically) will solve this case as well.

Therefore I'm closing this bug as duplicated. Please share this use case in 
Bug 999947, so it will be added to the test plan, once implemented.

*** This bug has been marked as a duplicate of bug 999947 ***

Comment 2 GenadiC 2014-05-01 12:55:20 UTC
Created attachment 891504 [details]
vdscaps file

Comment 3 GenadiC 2014-05-01 12:56:05 UTC
Created attachment 891505 [details]
vdsstats file

Comment 4 GenadiC 2014-05-01 13:05:17 UTC
Created attachment 891518 [details]
vdsm log

Comment 5 GenadiC 2014-05-01 13:26:37 UTC
Host indeed becomes non-operational when you remove required network from the Host NIC.
I got to situation where it didn't work when I had some other bridge stucked on the interface.
Then I got the required network bridge as not connected to any interface on the bridge (as there was other bridge connected to the interface) with brctl show.
All logs are attached

Comment 6 Dan Kenigsberg 2014-05-07 11:24:54 UTC
I see that the "slim" bridge has stayed behind, but no "slim" network is reported. Such condition should not be considered as where the network is available.

'networks': {'rhevm': {'iface': 'rhevm', 'addr': '10.35.128.12', 'cfg': {'DEFROUTE': 'yes', 'DELAY': '0', 'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'STP': 'no', 'DEVICE': 'rhevm', 'TYPE': 'Bridge', 'ONBOOT': 'yes'}, 'ipv6addrs': ['fe80::21d:9ff:fe68:71c1/64'], 'gateway': '10.35.128.254', 'netmask': '255.255.255.0', 'stp': 'off', 'bridged': True, 'mtu': '1500', 'ipv6gateway': '::', 'ports': ['eth0']}, 'mnb': {'iface': u'eth1', 'addr': '', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'bridged': False, 'interface': u'eth1', 'ipv6gateway': '::', 'gateway': ''}}

Comment 9 Lior Vernia 2014-09-02 14:23:22 UTC
Doesn't seem like a regression/blocker, was likely always like this for bridges not connected to any interface.

Comment 11 Lior Vernia 2015-04-26 13:35:57 UTC
Looking at the current engine code I think this might already be fixed. Please let us know...

Comment 12 Michael Burman 2015-04-27 16:40:19 UTC
Verified on - 3.6.0-0.0.master.20150412172306.git55ba764.el6

Host become non-operational after 10 seconds or less, right after approving Setup Networks operation.