Description of problem: It's not possible to modify the ovirtmgmt network on a host which hosts the engine because it is running the engine. When for example I would like to move ovirtmgmt to use jumbo frames eg. MTU 9000 it would not allow me to do so and give me an error: "Error while executing action Setup Networks: Network is currently being used" This is expected however the list thinks vdsm should better handle this and requested I open this bug. A worthy note, modifying the ifcfg-ovirtmgmt manually and restarting the engine was the current work around. This error kept me stumped for quite some time because I wanted to try add other VLANs at the same time, which succeeded after I stopped attempting to modify ovirtmgmt. I'm not sure if this should be considered a vdsm bug - sorry. Version-Release number of selected component (if applicable): ovirt-hosted-engine-setup-1.2.0-0.0.master.20140117.gitfaf77a5.el6.noarch ovirt-hosted-engine-ha-1.1.0-0.0.master.20140118.git3db8f76.el6.noarch vdsm-4.14.0-32.git1d4cc4e.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Install hosted-engine 2. Attempt to modify ovirtmgmt through the engine Actual results: Engine will disallow the action Expected results: Engine should work in collaboration with vdsm to allow the action. Or at the least, it would be nice for it to warn the user that ovirtmgmt cannot be modified. Additional info:
Verifying with the network team; Livnat, how do you think a resolution to this flow should look like?
Hi Andrew, Could you attach also engine.log, vdsm.log and supervdsm.log ?
Created attachment 854125 [details] vdsm.log Attached is the following: engine.log - from HOSTED_ENGINE vdsm.log - from centos 6.5 host supervdsm.log - from centos 6.5 host I attempted to modify the MTU down from 4000 to 3900 and then sync the network on the centos 6.5 host using the engine.
Created attachment 854126 [details] supervdsm.log
Created attachment 854127 [details] engine.log
In my opinion, it's a Vdsm missing feature - we do not allow changing any property of a VM network while it is used by VMs. Adding this feature is not trivial since we change a network's configuration by removing it first (which fails and should fail when a Vm is using it) and re-add it later. Thus, I do not see this being changed before v3.5.
The vdsm patches are already merged, so moving to the engine side where work still remains...
Dan, Can you please specify the use cases & exact changes of VM network that we aim for ?
Vdsm supports moving a bridge on top of another nic/bond and changing it vlan tagging - basically any topology change - while the bridge is in use. As of today, Vdsm still does not support changing the IP address of a bridge while it is in use, so it should still be blocked by Engine (or fixed in Vdsm side).
1. Making changes through setup networks dialog - currently (master) vdsm do not allow changing nic/bond under a used bridge. (accepted by ibarkan). Meaning engine does not block such operation. 2. Changing network on the DC level (MTU/VLAN) is blocked by engine (master) when a running VM uses the network.
Created attachment 1052367 [details] supervdsm.log related to blocking the change of an underlying NIC Traceback (most recent call last): File "/usr/share/vdsm/supervdsmServer", line 110, in wrapper res = func(*args, **kwargs) File "/usr/share/vdsm/supervdsmServer", line 217, in setupNetworks return setupNetworks(networks, bondings, **options) File "/usr/share/vdsm/network/api.py", line 879, in setupNetworks keep_bridge=keep_bridge) File "/usr/share/vdsm/network/api.py", line 215, in wrapped ret = func(**attrs) File "/usr/share/vdsm/network/api.py", line 455, in _delNetwork _validateDelNetwork(network, vlan, bonding, nics, bridged, _netinfo) File "/usr/share/vdsm/network/api.py", line 409, in _validateDelNetwork assertBridgeClean(network, vlan, bonding, nics) File "/usr/share/vdsm/network/api.py", line 343, in assertBridgeClean ' %s connected' % (bridge, brifs)) ConfigNetworkError: (28, u"bridge mgm has interfaces set([u'vnet1', u'vnet2']) connected")
(In reply to Yevgeny Zaspitsky from comment #11) > Created attachment 1052367 [details] > supervdsm.log related to blocking the change of an underlying NIC > > Traceback (most recent call last): > File "/usr/share/vdsm/supervdsmServer", line 110, in wrapper > res = func(*args, **kwargs) > File "/usr/share/vdsm/supervdsmServer", line 217, in setupNetworks > return setupNetworks(networks, bondings, **options) > File "/usr/share/vdsm/network/api.py", line 879, in setupNetworks > keep_bridge=keep_bridge) > File "/usr/share/vdsm/network/api.py", line 215, in wrapped > ret = func(**attrs) > File "/usr/share/vdsm/network/api.py", line 455, in _delNetwork > _validateDelNetwork(network, vlan, bonding, nics, bridged, _netinfo) > File "/usr/share/vdsm/network/api.py", line 409, in _validateDelNetwork > assertBridgeClean(network, vlan, bonding, nics) > File "/usr/share/vdsm/network/api.py", line 343, in assertBridgeClean > ' %s connected' % (bridge, brifs)) > ConfigNetworkError: (28, u"bridge mgm has interfaces set([u'vnet1', > u'vnet2']) connected") fixed in vdsm in https://gerrit.ovirt.org/#/c/43710/
Verified on - 3.6.0-0.12.master.el6 with vdsm-4.17.3-1.el7ev.noarch
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.