Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 786053

Summary: Default gateway need to be separated from interface configurations
Product: [Retired] oVirt Reporter: Sadique Puthen <sputhenp>
Component: vdsmAssignee: Dan Kenigsberg <danken>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: abaron, acathrow, bazulay, iheim, jboggs, lpeer, mburns, Rhev-m-bugs, yeylon, ykaul, zdover
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 786052 Environment:
Last Closed: 2013-03-11 21:48:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 618636    
Bug Blocks:    

Description Sadique Puthen 2012-01-31 09:46:31 UTC
+++ This bug was initially created as a clone of Bug #786052 +++

Description of problem:


Currently, in the network configuration of interfaces on RHEV-M -> hosts tab, RHEV assumes that the default gateway is always a host from the rhevm subnet and need to be routed via rhevm bridge.

This is not always correct. Users need to be given the freedom to configure a default gateway from the subnet of their choice through the interface associated with that subnet.

To make this happen, we should not associate the default gateway configuration to any interface, but make it independent and enter the added default gateway to /etc/sysconfig/network as "GATEWAY=<ip>".

Excerpts from internal discussion:

<snip>

The problem is that if you define a GATEWAY directive in an interface it looks like this: 
In the ifcfg-rhevm file:
GATEWAY=23.2.2.1

The result in the route table as you can see points to a device through which to get to the default gateway. 
default via 23.2.2.1 dev rhevm 

Now if you set a GATEWAY directive in an ifcfg-<device> script and this gateway is not on the same network as the interface this directive is ignored.

VDSM uses the GATEWAY directive in the interface: 
        s = """DEVICE=%s\nTYPE=Bridge\nONBOOT=%s\n""" % (pipes.quote(name), pipes.quote(onboot))
        if ipaddr:
            s = s + 'IPADDR=%s\nNETMASK=%s\n' % (pipes.quote(ipaddr), pipes.quote(netmask))
            if gateway:
                s = s + 'GATEWAY=%s\n' % pipes.quote(gateway)

Thus trying to set a gateway on a different subnet then rhevm on the new dialog indeed results with no gateway.


The solution should be that VDSM will set the gateway in /etc/sysconfig/network.
In this case the gateway device will be auto detected by matching the gateway IP to the interfaces subnet.


In any case we've planned in the new network dialogs to have the default gateway as un-associated with specific interface, VDSM should match that.

</snip>

Use case where this change is required.

===

Take the below example for a customer network.

192.168.1.0/24 = Internal eth0 -> rhevm network and there is no default gateway on this network.

192.168.2.0/24 = Internal eth1 -> stoage network and there is no default gateway on this network.

193.168.1.0/24 = Public network where eth2 -> display bridge is configured and has a default gateway configured.

194.168.1.0/24 = Public network where eth3 -> guest bridge is configured and may or may not have a gw.

RHEVM-GUI only allows to configure a default gateway via rhevm and gateway should be from 192.168.1.0/24 network which does not exist. (Configuring a default gw from 193.168.1.0/24 via rhevm does not make sense, though it's possible.) It will not allow to configure a default gw from 193.168.1.0/24 via display bridge or 194.168.1.0/24 network via guest bridge unless we do f2 and configure it manually.

In the above configuration spice connection will not be possible unless we do f2 and manually configure default gw.

This above was possible in 2.2 and missing from rhev3.

Comment 1 Itamar Heim 2013-03-11 21:48:34 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Comment 2 Sadique Puthen 2013-05-30 12:46:41 UTC

*** This bug has been marked as a duplicate of bug 618636 ***