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:
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 ***
Created attachment 891504 [details] vdscaps file
Created attachment 891505 [details] vdsstats file
Created attachment 891518 [details] vdsm log
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
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': ''}}
Doesn't seem like a regression/blocker, was likely always like this for bridges not connected to any interface.
Looking at the current engine code I think this might already be fixed. Please let us know...
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.