Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1015009

Summary: Default route is not set properly for management network if downstream/upstream engine and VDSM are mixed
Product: Red Hat Enterprise Virtualization Manager Reporter: Bala.FA <barumuga>
Component: vdsmAssignee: Assaf Muller <amuller>
Status: CLOSED ERRATA QA Contact: Martin Pavlik <mpavlik>
Severity: high Docs Contact:
Priority: low    
Version: 3.3.0CC: amuller, asegurap, barumuga, bazulay, danken, dpati, gklein, iheim, lbopf, lpeer, masayag, myakove, nyechiel, pprakash, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
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 13:25:19 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:
Bug Depends On:    
Bug Blocks: 1013611, 1068929, 1078909, 1142926    

Description Bala.FA 2013-10-03 09:53:42 UTC
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 14:04:48 UTC
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 15:30:22 UTC
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 05:02:26 UTC
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 14:43:33 UTC
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 17:35:51 UTC
Posted VDSM patch. Equivalent engine patch is required for a bug fix.

Comment 6 Dan Kenigsberg 2014-02-03 12:44:46 UTC
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 20:01:15 UTC
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 10:44:19 UTC
Sent a patch to VDSM to fix this.

Comment 10 Dan Kenigsberg 2014-02-19 15:09:36 UTC
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 15:17:26 UTC
Moving to POST till engine's patch is merged.

Comment 12 Martin Pavlik 2014-03-13 09:12:52 UTC
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 13:25:19 UTC
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