Bug 1015009 - Default route is not set properly for management network if downstream/upstream engine and VDSM are mixed
Default route is not set properly for management network if downstream/upstre...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.3.0
Unspecified Unspecified
low Severity high
: ---
: 3.4.0
Assigned To: Assaf Muller
Martin Pavlik
network
: Triaged
Depends On:
Blocks: 1013611 1068929 rhev3.4beta 1142926
  Show dependency treegraph
 
Reported: 2013-10-03 05:53 EDT by Bala.FA
Modified: 2016-02-10 14:46 EST (History)
15 users (show)

See Also:
Fixed In Version: av1
Doc Type: Bug Fix
Doc Text:
Default route is now enabled for management network irrespective of device name.
Story Points: ---
Clone Of:
: 1068929 (view as bug list)
Environment:
Last Closed: 2014-06-09 09:25:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 22720 None None None Never
oVirt gerrit 23182 None None None Never
oVirt gerrit 23232 None None None Never
oVirt gerrit 24631 None None None Never
oVirt gerrit 24677 None None None Never

  None (edit)
Description Bala.FA 2013-10-03 05:53:42 EDT
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:
Comment 1 Assaf Muller 2013-10-03 10:04:48 EDT
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
Comment 2 Dan Kenigsberg 2013-10-03 11:30:22 EDT
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?
Comment 3 Bala.FA 2013-10-04 01:02:26 EDT
Yes. RHS-specific downstream only patch for this issue fixes.  I just opened up in rhevm/vdsm as per chat with amuller.
Comment 4 Dan Kenigsberg 2013-12-24 09:43:33 EST
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.
Comment 5 Assaf Muller 2013-12-24 12:35:51 EST
Posted VDSM patch. Equivalent engine patch is required for a bug fix.
Comment 6 Dan Kenigsberg 2014-02-03 07:44:46 EST
commit f029545bdac640fccf0dec17209655d9d482d0d1
Author: Assaf Muller <amuller@redhat.com>
Date:   Sun Jan 12 11:50:36 2014 +0200

    Extend setupNetworks API to accept defaultRoute

merged into ovirt-3.4.
Comment 7 Moti Asayag 2014-02-17 15:01:15 EST
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 ?
Comment 8 Assaf Muller 2014-02-18 05:44:19 EST
Sent a patch to VDSM to fix this.
Comment 10 Dan Kenigsberg 2014-02-19 10:09:36 EST
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.
Comment 11 Moti Asayag 2014-02-19 10:17:26 EST
Moving to POST till engine's patch is merged.
Comment 12 Martin Pavlik 2014-03-13 05:12:52 EDT
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
Comment 13 errata-xmlrpc 2014-06-09 09:25:19 EDT
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

Note You need to log in before you can comment on or make changes to this bug.