Description of problem: When 'ovirtmgmt' bridge name is passed from RHSC engine, default route is not set (ie 'DEFROUTE=no' is set in ifcfg-ovirtmgmt). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: As bridge name is passed from the engine, the bridge name needs to configured with default route. Additional info:
I've been talking to the reporter and I'll fill in some information. VDSM needs to allow the management network to insert its default route in the main routing table and to disallow the same action to all other networks. This way the management's network gateway is guaranteed to be the host's default gateway and the engine won't lose connectivity to the host. Currently the engine doesn't flag the management network in any special way. VDSM however does need to treat the management network in a special way because of the aforementioned reason. VDSM flags the management network by its name. Upstream VDSM expects it to be 'ovirtmgmt' and downstream VDSM expects it to be rhevm. The bug happens when you mix and match upstream and downstream engine and VDSM. For example: The engine sends ovirtmgmt and VDSM expects the management network to be rhevm and thus doesn't allow its gateway to be inserted in to the host's main routing table. Possible fixes: * Change the API so that the engine marks the management network, this way VDSM doesn't need to look at the network's name. * Quick hack: Allow both upstream and downstream VDSM to treat both ovirtmgmt and rhevm as the management network. * Allow setting the management network name as a configurable value
Quicker hack: an RHS-specific downstream-only vdsm patch reverting MANAGEMENT_BRIDGE to ovirtmgmt. Why was this bug opened on rhevm's vdsm and not rhsm's? Which vdsm version is it?
Yes. RHS-specific downstream only patch for this issue fixes. I just opened up in rhevm/vdsm as per chat with amuller.
I'd like to fix this in 3.4.0, by having Engine send a "defaultRoute=True" option to the management network. This would allow us to drop any leaving references to the management network name.
Posted VDSM patch. Equivalent engine patch is required for a bug fix.
commit f029545bdac640fccf0dec17209655d9d482d0d1 Author: Assaf Muller <amuller> Date: Sun Jan 12 11:50:36 2014 +0200 Extend setupNetworks API to accept defaultRoute merged into ovirt-3.4.
While verifying the engine patch that should pass the 'defaultRoute' for the management network, I noticed that while the new property appears in vdsm.log: Thread-192::DEBUG::2014-02-17 21:42:12,537::BindingXMLRPC::970::vds::(wrapper) client [10.35.202.52]::call setupNetworks with ({'ovirtmgmt': {'nic': 'eth0', 'bootproto': 'dhcp', 'STP': 'no', 'defaultRoute': True, 'bridged': 'true'}}, {}, {'connectivityCheck': 'false'}) {} flowID [24facceb] I wasn't presented as expected in the ifcfg-ovirtmgmt file: cat ifcfg-ovirtmgmt # Generated by VDSM version 4.14.1-3.el6 DEVICE=ovirtmgmt ONBOOT=yes TYPE=Bridge DELAY=0 BOOTPROTO=dhcp NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes STP=no And for static ip with gateway: Thread-194::DEBUG::2014-02-17 21:48:17,199::BindingXMLRPC::970::vds::(wrapper) client [10.35.202.52]::call setupNetworks with ({'ovirtmgmt': {'nic': 'eth0', 'ipaddr': '10.35.7.15', 'netmask': '255.255.254.0', 'STP': 'no', 'bridged': 'true', 'gateway': '10.35.7.254', 'defaultRoute': True}}, {}, {'connectivityCheck': 'false'}) {} flowID [619ba552] And the content of the ifcfg-ovirtmgmt file: # Generated by VDSM version 4.14.1-3.el6 DEVICE=ovirtmgmt ONBOOT=yes TYPE=Bridge DELAY=0 IPADDR=10.35.7.15 NETMASK=255.255.254.0 GATEWAY=10.35.7.254 BOOTPROTO=none NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes STP=no And this is the relevant snippet from supervdsm.log: MainProcess|Thread-194::DEBUG::2014-02-17 21:48:18,559::configNetwork::250::root::(addNetwork) validating network... MainProcess|Thread-194::INFO::2014-02-17 21:48:18,560::configNetwork::272::root::(addNetwork) Adding network ovirtmgmt with vlan=None, bonding=None, nics=['eth0'], bondingOptions=None, mtu=None, bridged=True, defaultRoute=True,options={'STP': 'no', 'implicitBonding': True} MainProcess|Thread-194::DEBUG::2014-02-17 21:48:18,560::ifcfg::429::root::(_persistentBackup) backing up ifcfg-ovirtmgmt: # original file did not exist MainProcess|Thread-194::DEBUG::2014-02-17 21:48:18,560::ifcfg::519::root::(writeConfFile) Writing to file /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt configuration: # Generated by VDSM version 4.14.1-3.el6 DEVICE=ovirtmgmt ONBOOT=yes TYPE=Bridge DELAY=0 IPADDR=10.35.7.15 NETMASK=255.255.254.0 GATEWAY=10.35.7.254 BOOTPROTO=none NM_CONTROLLED=no IPV6INIT=yes IPV6_AUTOCONF=yes STP=no Shouldn't "DEFROUTE=yes" be added in both cases to ifcfg-ovirtmgmt ?
Sent a patch to VDSM to fix this.
This bug is merged to the ovirt-3.4 stable branch, but it missed the ovirt-3.4.0-beta3; it would be ready for QA only on ovirt-3.4.0 general availability.
Moving to POST till engine's patch is merged.
works in av2.1 [root@dell-r210ii-08 ~]# cat /etc/sysconfig/network-scripts/ifcfg-rhevm # Generated by VDSM version 4.14.5-0.el6 DEVICE=rhevm ONBOOT=yes TYPE=Bridge DELAY=0 BOOTPROTO=dhcp DEFROUTE=yes NM_CONTROLLED=no STP=no [root@dell-r210ii-08 ~]# cat /etc/sysconfig/network-scripts/ifcfg-rhevm # Generated by VDSM version 4.14.5-0.el6 DEVICE=rhevm ONBOOT=yes TYPE=Bridge DELAY=0 IPADDR=10.34.66.81 NETMASK=255.255.255.0 GATEWAY=10.34.66.254 BOOTPROTO=none DEFROUTE=yes NM_CONTROLLED=no STP=no
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