Bug 1186330
| Summary: | Gateway entry (outside of 'cfg') is not set for non-VM networks | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Lior Vernia <lvernia> | ||||
| Component: | vdsm | Assignee: | Ondřej Svoboda <osvoboda> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Michael Burman <mburman> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.6 | CC: | bazulay, bugs, danken, ecohen, gklein, ibarkan, lsurette, mburman, mgoldboi, rbalakri, yeylon | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 3.6.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | network | ||||||
| Fixed In Version: | vdsm-4.17.0-632.git19a83a2 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-11-04 12:59:25 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: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1070613 | ||||||
| Attachments: |
|
||||||
The fix http://gerrit.ovirt.org/#/c/37440/ has been merged to master. I just noticed that on my EL6 host the routes are almost perfectly duplicated between the 'main' routing table and the table dedicated to the (dynamic, DHCP) source route. Although the dedicated table and the main table differ in the first route (did the kernel really do this?), the default route is the same. The duplication results in the gateway not being reported. # ip route show table 170016670 10.34.60.0/22 via 10.34.63.158 dev ovirtmgmt default via 10.34.63.254 dev ovirtmgmt # ip route show table main 10.34.60.0/22 dev ovirtmgmt proto kernel scope link src 10.34.63.158 default via 10.34.63.254 dev ovirtmgmt The treatment should be as follows: Since VDSM manages its policy routing itself we should skip routes explicitly belonging to the 'main' (254) table. I will try to understand why the gateway for the ovirtmgmt network is duplicated. I assume that the reason to it is due to the ovirtmgmt gateway being default to the whole system. Dan, am I right in this respect? Additional fixed merged. Verified on - 3.6.0-0.0.master.20150412172306.git55ba764.el6
and vdsm-4.17.0-632.git19a83a2.el7.x86_64
vlans = {'bond0.165': {'addr': '5.5.5.9',
'cfg': {'BOOTPROTO': 'none',
'DEFROUTE': 'no',
'DEVICE': 'bond0.165',
'GATEWAY': '5.5.5.254',
'HOTPLUG': 'no',
'IPADDR': '5.5.5.9',
'MTU': '1500',
'NETMASK': '255.255.255.0',
'NM_CONTROLLED': 'no',
'ONBOOT': 'no',
'VLAN': 'yes'},
'dhcpv4': False,
'dhcpv6': False,
'gateway': '5.5.5.254',
'iface': 'bond0',
'ipv4addrs': ['5.5.5.9/24'],
'ipv6addrs': ['fe80::210:18ff:fe24:476e/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '255.255.255.0',
'vlanid': 165}}
'net1': {'addr': '5.5.5.9',
'bridged': False,
'dhcpv4': False,
'dhcpv6': False,
'gateway': '5.5.5.254',
'iface': 'bond0.165',
'interface': 'bond0.165',
'ipv4addrs': ['5.5.5.9/24'],
'ipv6addrs': ['fe80::210:18ff:fe24:476e/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '255.255.255.0'},
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one. |
Created attachment 984634 [details] getVdsCaps Description of problem: When configuring stating boot protocol with gateway for a non-VM network (either VLAN-tagged or not), its gateway is not set though its IP address and subnet are. Version-Release number of selected component (if applicable): Building from current master. How reproducible: Always. Steps to Reproduce: 1. Create non-VM network. 2. Configure on host with static boot protocol, including gateway. 3. Look at the configuration following the setup networks command. Actual results: Gateway entry remains empty (though inside the 'cfg' entry, gateway is set). Expected results: Gateway outside of the 'cfg' entry should be consistent with that inside the 'cfg' entry! Additional info: Note that the problem is on vdsm side - engine sends the proper configuration. Also, attaching output of getVdsCaps.