Bug 1015009

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