RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 798450 - netcf doesn't update the gateway device
Summary: netcf doesn't update the gateway device
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: netcf
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-28 21:35 UTC by Jonathan Bayer
Modified: 2012-08-05 23:04 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-05 23:04:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Script to install necessary RPMs and then to download and install current version of libvirt and virt-manager (1.20 KB, application/x-gzip)
2012-02-28 21:35 UTC, Jonathan Bayer 		no flags Details
View All

Description Jonathan Bayer 2012-02-28 21:35:28 UTC 
Created attachment 566402 [details]
Script to install necessary RPMs and then to download and install current version of libvirt and virt-manager

Description of problem:

Using virt-manager, I converted the gateway device, eth0, into a bridge.  Everything worked except that the routing was not working.  Upon investigation I found that the GATEWAYDEV in /etc/sysconfig/network was not updated, it still said eth0 instead of br0

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  Use virt-manager to change the gateway device into a bridge
2.
3.
  
Actual results:

GATEWAYDEV not updated in /etc/sysconfig/network, causing routing to fail

Expected results:

GATEWAYDEV should have been updated to point to the bridge, br0

Additional info:

This was a fresh, minimal install of 6.1
I downloaded and installed the latest version of virt-manager directly from the website
Comment 2 Laine Stump 2012-05-11 19:47:53 UTC 
This poses an interesting problem, because /etc/sysconfig/network in general (and GATEWAYDEV in particular) is a *system* network configuration setting, while libvirt's virInterface*() APIs are all geared towards configuring a single interface (or related set of interfaces).

The model that the virInterface APIs works well with is when the default gateway is specified in the configuration for one of the interfaces.

One possibility would be to add an optional gatewayDev='yes|no' attribute to each interface's <route> element, but this would lead to ambiguity (what should happen if gatewayDev='yes' is encountered when defining a new interface if it's already set for an existing interface? error or override? And what if <route gateway> is also set for that interface? Should we then still set GATEWAY=x.x.x.x in that interface's ifcfg file? Or, because gatewayDev is also set, only set GATEWAY=x.x.x.x in /etc/sysconfig/network? And where does the DEFROUTE setting in the ifcfg file fit into all of this?

Or should these settings in /etc/sysconfig/network be considered deprecated, and any encounter with them cause GATEWAY=x.x.x.x to be set in the relevant ifcfg file? I haven't encountered a system that used
Comment 3 Laine Stump 2012-05-18 18:14:02 UTC 
Bug 822989 is a related problem.
Comment 5 RHEL Program Management 2012-07-10 08:27:42 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 6 RHEL Program Management 2012-07-11 00:02:57 UTC 
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 7 Laine Stump 2012-08-05 23:04:05 UTC 
Examination of the NetworkManager source, as well as experimentation (and a discussion with NM's main developer) revealed that NM doesn't support GATEWAYDEV (or GATEWAY). This being the case, it appears that getting a default route by way of specifying GATEWAYDEV or GATEWAY in /etc/sysconfig/network is deprecated in favor of setting GATEWAY[n] and DEFROUTE in the individual ifcfg-* files in /etc/sysconfig/network-scripts (which give as much control, but in a more useful manner)

Based on that investigation, I'm closing this bug as WONTFIX. If that has an adverse impact on you, please open a ticket with Red Hat support to escalate the issue appropriately.
Note You need to log in before you can comment on or make changes to this bug.