Bug 1310435
| Summary: | default team profile should load some default config | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vladimir Benes <vbenes> |
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | aloughla, bgalvani, dcbw, fgiudici, lrintel, rkhan, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-03 19:07:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Could be a dupe of bug 1294728 Created attachment 1135508 [details]
team: expose current device configuration through D-Bus and nmcli
NM should not modify the value of team.config as specified by user.
The current team configuration is something associated with the device
and should be exposed in the output of "nmcli device show", as for
example:
# nmcli -f all d show team0
GENERAL.DEVICE: team0
GENERAL.TYPE: team
GENERAL.NM-TYPE: NMDeviceTeam
[...]
TEAM.SLAVES: ens11 ens10
TEAM.CONFIG: { "device": "team0", "ports": { "ens10": { "link_watch": { "name": "ethtool" } }, "ens11": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
CONNECTIONS.AVAILABLE-CONNECTION-PATHS: /org/freedesktop/NetworkManager/Settings/{1}
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: 9951a625-cd24-4a69-b236-7c1674033ce1 | t0
IP4.ADDRESS[1]: 9.9.9.9/32
IP4.GATEWAY:
IP6.ADDRESS[1]: fe80::7258:9848:e7b2:db52/64
IP6.GATEWAY:
Vladimir, what do you think, would this be helpful?
Attached patch implements the new property.
(In reply to Beniamino Galvani from comment #2) > Created attachment 1135508 [details] > team: expose current device configuration through D-Bus and nmcli > > NM should not modify the value of team.config as specified by user. > The current team configuration is something associated with the device > and should be exposed in the output of "nmcli device show", as for > example: > > # nmcli -f all d show team0 > GENERAL.DEVICE: team0 > GENERAL.TYPE: team > GENERAL.NM-TYPE: NMDeviceTeam > [...] > TEAM.SLAVES: ens11 ens10 > TEAM.CONFIG: { "device": "team0", "ports": { > "ens10": { "link_watch": { "name": "ethtool" } }, "ens11": { "link_watch": { > "name": "ethtool" } } }, "runner": { "name": "roundrobin" } } > CONNECTIONS.AVAILABLE-CONNECTION-PATHS: > /org/freedesktop/NetworkManager/Settings/{1} > CONNECTIONS.AVAILABLE-CONNECTIONS[1]: > 9951a625-cd24-4a69-b236-7c1674033ce1 | t0 > IP4.ADDRESS[1]: 9.9.9.9/32 > IP4.GATEWAY: > IP6.ADDRESS[1]: fe80::7258:9848:e7b2:db52/64 > IP6.GATEWAY: > > Vladimir, what do you think, would this be helpful? > > Attached patch implements the new property. Would this work dynamically with newly attached devices? I mean if devices in config would change with every single upping? Scratch build would be probably the best for testing. Thanks! (In reply to Vladimir Benes from comment #3) > > Vladimir, what do you think, would this be helpful? > > > > Attached patch implements the new property. > > Would this work dynamically with newly attached devices? I mean if devices > in config would change with every single upping? Scratch build would be > probably the best for testing. Thanks! Yes, NM will query the configuration to teamd every time a team device is activated. This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Created attachment 1157942 [details]
[PATCH v2] team: expose current device configuration through D-Bus and nmcli
Patch slightly improved and rebased on current master.
there are still several things to be solved:
1. team slave doesn't have config after restart it does have but assumed connection is created, the original one doesn't have it. Maybe we can solve this in another bug.
normal team slave created via nmcli con add ...
team-port.config: --
vs
assumed connection after NM restart
team-port.config: {
"link_watch": {
"name": "ethtool"
}
}
2. master connection still goes to assumed one if slave was connected after master
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection up id team
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection up id ethernet-eth1
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
[root@qe-dell-ovs5-vm-7 ~]# systemctl restart NetworkManager
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection
NAME UUID TYPE DEVICE
ethernet-eth1 8d3a3f60-4d68-4d79-bc86-a96fd0e541dd 802-3-ethernet eth1
team 2bef45ac-3a01-4ec8-9499-44f0a3b0da1e team nm-team
testeth0 abc13c91-7049-4a99-8f6f-9b4b2dbc0856 802-3-ethernet eth0
[root@qe-dell-ovs5-vm-7 ~]# systemctl restart NetworkManager
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection
NAME UUID TYPE DEVICE
eth1 b2889feb-20a5-48f6-ac4f-879ad905f0de 802-3-ethernet eth1
nm-team 0e45261e-e44d-4b22-ac16-d61fa9a2ddf8 team nm-team
testeth0 abc13c91-7049-4a99-8f6f-9b4b2dbc0856 802-3-ethernet eth0
I will attach logs from these attempts in next comment
this is somehow weird both connections are listed:
[root@qe-dell-ovs5-vm-7 ~]# nmcli -f all d show nm-team
<snip>
TEAM.SLAVES: eth1
TEAM.CONFIG: { "device": "nm-team", "ports": { "eth1": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
CONNECTIONS.AVAILABLE-CONNECTION-PATHS: /org/freedesktop/NetworkManager/Settings/{13,10}
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: 0e45261e-e44d-4b22-ac16-d61fa9a2ddf8 | nm-team
CONNECTIONS.AVAILABLE-CONNECTIONS[2]: 2bef45ac-3a01-4ec8-9499-44f0a3b0da1e | team
but more often the behavior is as follows:
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection up id ethernet-eth1
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection s -a
NAME UUID TYPE DEVICE
ethernet-eth1 8d3a3f60-4d68-4d79-bc86-a96fd0e541dd 802-3-ethernet eth1
team 2bef45ac-3a01-4ec8-9499-44f0a3b0da1e team nm-team
testeth0 abc13c91-7049-4a99-8f6f-9b4b2dbc0856 802-3-ethernet eth0
[root@qe-dell-ovs5-vm-7 ~]# systemctl restart NetworkManager
[root@qe-dell-ovs5-vm-7 ~]# nmcli connection s -a
NAME UUID TYPE DEVICE
eth1 bda187d7-9d9e-4ef2-afce-3a0a13956452 802-3-ethernet eth1
nm-team 09f60bf3-2122-441b-b4bb-fd4d7e2a9ac1 team nm-team
testeth0 abc13c91-7049-4a99-8f6f-9b4b2dbc0856 802-3-ethernet eth0
logs attached in next comment
Created attachment 1158222 [details]
first correct restart and second incorrect
Created attachment 1158223 [details]
first incorrect restart (second use case)
(In reply to Vladimir Benes from comment #11) > there are still several things to be solved: > > 1. team slave doesn't have config after restart it does have but assumed > 2. master connection still goes to assumed one if slave was connected after > master Yeah, these issues are tracked in bug 1294728 and should now be solved on master branch (but are independent from the request in this bug to provide a way to show the current team configuration). update_connection() does: + teamd_read_config (device); + g_object_set (G_OBJECT (s_team), NM_SETTING_TEAM_CONFIG, priv->config, NULL); I think update_connection() should preferably create a NMConnection without touching the device. That is, it should not re-read the internal priv->config property. priv->config should already be up-to-date, so re-reading is not necessary. If it invalid/out-dates, that is a bug to be fixed somewhere else, not by update_connection(). I get a compiler-warning: nm-device-team.c:48:1: error: unused function '_notify' [-Werror,-Wunused-function] NM_GOBJECT_PROPERTIES_DEFINE (NMDeviceTeam, ^ ../../../shared/nm-macros-internal.h:338:20: note: expanded from macro 'NM_GOBJECT_PROPERTIES_DEFINE' static inline void \ you could fix that by using NM_GOBJECT_PROPERTIES_DEFINE_BASE() instead. But even better, just use it: - g_object_notify (G_OBJECT (self), NM_DEVICE_TEAM_CONFIG); + _notify (self, PROP_TEAM_CONFIG); libnm/nm-device-team.c leaks priv->config. Otherwise, lgtm Created attachment 1161496 [details] [PATCH v3] team: expose current device configuration through D-Bus and nmcli (In reply to Thomas Haller from comment #15) > I think update_connection() should preferably create a NMConnection without > touching the device. That is, it should not re-read the internal > priv->config property. priv->config should already be up-to-date, so > re-reading is not necessary. If it invalid/out-dates, that is a bug to be > fixed somewhere else, not by update_connection(). Unfortunately priv->config can be NULL during startup when we are waiting for the D-Bus watch to signal the appearance of the owner (see commit [1]) and so it is necessary to read it. And if we have to read it, probably it's also a good idea to save it in the device object? > I get a compiler-warning: > libnm/nm-device-team.c leaks priv->config. Fixed both, thanks. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=28274495d61cb434272e0e2307dfd824ee78de8e (In reply to Beniamino Galvani from comment #16) > Created attachment 1161496 [details] > [PATCH v3] team: expose current device configuration through D-Bus and nmcli > > (In reply to Thomas Haller from comment #15) > > I think update_connection() should preferably create a NMConnection without > > touching the device. That is, it should not re-read the internal > > priv->config property. priv->config should already be up-to-date, so > > re-reading is not necessary. If it invalid/out-dates, that is a bug to be > > fixed somewhere else, not by update_connection(). > > Unfortunately priv->config can be NULL during startup when we > are waiting for the D-Bus watch to signal the appearance of the owner > (see commit [1]) and so it is necessary to read it. And if we have to > read it, probably it's also a good idea to save it in the device object? Now it is read only when necessary. That looks right to me now. v3 lgtm lgtm Patch applied to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3c649e6429908e0b83bc176f8349c72ebd61ad60 Beniamino what about this:
# nmcli connection add type team
# nmcli connection add type ethernet ifname eth1 con-name team-eth1 master team
# nmcli device
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected testeth0
eth1 ethernet connected team-eth1
nm-team team connected team
# nmcli -f all device show nm-team
TEAM.CONFIG: { "device": "nm-team", "runner": { "name": "roundrobin" } }
shouldn't this reflect eth1?
and:
# nmcli connection up id team-eth1
TEAM.CONFIG: { "device": "nm-team", "runner": { "name": "roundrobin" } }
# nmcli connection up id team
TEAM.CONFIG: { "device": "nm-team", "runner": { "name": "roundrobin" } }
and after I've finally see result:
# nmcli connection up id team-eth1
TEAM.CONFIG: { "device": "nm-team", "ports": { "eth1": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
^^ is this caused by lack of config in team-port?
and:
# nmcli connection down team-eth1
# nmcli -f all device show nm-team
TEAM.CONFIG: { "device": "nm-team", "ports": { "eth1": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
^^ should this be reflected or not?
teamdctl says:
# teamdctl nm-team state dump
{
"setup": {
"daemonized": false,
"dbus_enabled": true,
"debug_level": 0,
"kernel_team_mode_name": "roundrobin",
"pid": 32465,
"pid_file": "/var/run/teamd/nm-team.pid",
"runner_name": "roundrobin",
"zmq_enabled": false
},
"team_device": {
"ifinfo": {
"dev_addr": "52:54:00:77:c5:53",
"dev_addr_len": 6,
"ifindex": 20,
"ifname": "nm-team"
}
}
}
(In reply to Vladimir Benes from comment #21) > Beniamino what about this: > # nmcli connection add type team > # nmcli connection add type ethernet ifname eth1 con-name team-eth1 master > team > # nmcli device > DEVICE TYPE STATE CONNECTION > eth0 ethernet connected testeth0 > eth1 ethernet connected team-eth1 > nm-team team connected team > # nmcli -f all device show nm-team > TEAM.CONFIG: { "device": "nm-team", > "runner": { "name": "roundrobin" } } > > shouldn't this reflect eth1? The property value should be aligned with the output of: # teamdctl nm-team config dump but after bringing the connection up it takes some seconds to refresh. So, if teamdctl doesn't show eth1, nmcli will not do it either. > > and after I've finally see result: > # nmcli connection up id team-eth1 > TEAM.CONFIG: { "device": "nm-team", > "ports": { "eth1": { "link_watch": { > "name": "ethtool" } } }, "runner": { > "name": "roundrobin" } } > > ^^ is this caused by lack of config in team-port? No, probably you only have to wait few seconds for the configuration to appear it teamdctl and nmcli. > and: > # nmcli connection down team-eth1 > # nmcli -f all device show nm-team > TEAM.CONFIG: { "device": "nm-team", > "ports": { "eth1": { "link_watch": { > "name": "ethtool" } } }, "runner": { > "name": "roundrobin" } } > > ^^ should this be reflected or not? Here NM takes the configuration from teamd and so if 'teamdctl nm-team config dump' still contains the eth1 port, there's no way NM can show something different, as "ports" JSON node is entirely created and managed in memory by teamd... my observations:
[root@qe-dell-ovs5-vm-50 NetworkManager]# teamdctl nm-team state dump
{
"ports": {
"eth1": {
"ifinfo": {
"dev_addr": "fe:06:73:cf:c1:5a",
"dev_addr_len": 6,
"ifindex": 25,
"ifname": "eth1"
},
"link": {
"duplex": "full",
"speed": 10000,
"up": true
},
"link_watches": {
"list": {
"link_watch_0": {
"delay_down": 0,
"delay_up": 0,
"down_count": 0,
"name": "ethtool",
"up": true
}
},
"up": true
}
}
},
"setup": {
"daemonized": false,
"dbus_enabled": true,
"debug_level": 0,
"kernel_team_mode_name": "roundrobin",
"pid": 1425,
"pid_file": "/var/run/teamd/nm-team.pid",
"runner_name": "roundrobin",
"zmq_enabled": false
},
"team_device": {
"ifinfo": {
"dev_addr": "fe:06:73:cf:c1:5a",
"dev_addr_len": 6,
"ifindex": 64,
"ifname": "nm-team"
}
}
}
[root@qe-dell-ovs5-vm-50 NetworkManager]# nmcli -f all device show nm-team
GENERAL.DEVICE: nm-team
GENERAL.TYPE: team
GENERAL.NM-TYPE: NMDeviceTeam
GENERAL.VENDOR:
GENERAL.PRODUCT:
GENERAL.DRIVER: team
GENERAL.DRIVER-VERSION: 3.10.0-433.el7.x86_64
GENERAL.FIRMWARE-VERSION:
GENERAL.HWADDR: FA:B0:61:3F:C8:8A
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.REASON: 0 (No reason given)
GENERAL.UDI: /sys/devices/virtual/net/nm-team
GENERAL.IP-IFACE: nm-team
GENERAL.IS-SOFTWARE: yes
GENERAL.NM-MANAGED: yes
GENERAL.AUTOCONNECT: yes
GENERAL.FIRMWARE-MISSING: no
GENERAL.NM-PLUGIN-MISSING: no
GENERAL.PHYS-PORT-ID: --
GENERAL.CONNECTION: team
GENERAL.CON-UUID: e0bdef95-808c-447b-9525-df99a7314a92
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
GENERAL.METERED: no (guessed)
CAPABILITIES.CARRIER-DETECT: yes
CAPABILITIES.SPEED: unknown
CAPABILITIES.IS-SOFTWARE: yes
TEAM.SLAVES: eth1
TEAM.CONFIG: { "device": "nm-team", "runner": { "name": "roundrobin" } }
CONNECTIONS.AVAILABLE-CONNECTION-PATHS: /org/freedesktop/NetworkManager/Settings/{13}
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: e0bdef95-808c-447b-9525-df99a7314a92 | team
<..snip..>
so this is inconsistent and I think the removal is not correct either. Maybe it's connected to bug 1347015 as it looks like NM and teamd have some problem together.
As for the reproducer I use just very basic commands for adding team and slave w/o any configs.
have to move back to assigned as slave removal is not reflected:
[root@wlan-r2s5 NetworkManager]# systemctl restart NetworkManager
[root@wlan-r2s5 NetworkManager]# nmcli device
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected testeth0
eth1 ethernet disconnected --
eth10 ethernet disconnected --
eth2 ethernet disconnected --
eth3 ethernet disconnected --
eth4 ethernet disconnected --
eth5 ethernet disconnected --
eth6 ethernet disconnected --
eth7 ethernet disconnected --
eth8 ethernet disconnected --
eth9 ethernet disconnected --
wlp4s0 wifi unavailable --
lo loopback unmanaged --
[root@wlan-r2s5 NetworkManager]# nmcli connection add type team ifname team0
Connection 'team-team0' (50b6768e-2644-4770-953e-a3e818cb953d) successfully added.
[root@wlan-r2s5 NetworkManager]# nmcli connection add type ethernet slave-type team master team0 ifname eth1
Connection 'ethernet-eth1' (9b7449c7-c4fd-4020-b3d0-8ec8bf38260f) successfully added.
[root@wlan-r2s5 NetworkManager]# nmcli -f all d show team0
GENERAL.DEVICE: team0
GENERAL.TYPE: team
GENERAL.NM-TYPE: NMDeviceTeam
GENERAL.VENDOR:
GENERAL.PRODUCT:
GENERAL.DRIVER: team
GENERAL.DRIVER-VERSION: 3.10.0-435.el7.x86_64
GENERAL.FIRMWARE-VERSION:
GENERAL.HWADDR: C2:ED:38:31:03:74
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.REASON: 0 (No reason given)
GENERAL.UDI: /sys/devices/virtual/net/team0
GENERAL.IP-IFACE: team0
GENERAL.IS-SOFTWARE: yes
GENERAL.NM-MANAGED: yes
GENERAL.AUTOCONNECT: yes
GENERAL.FIRMWARE-MISSING: no
GENERAL.NM-PLUGIN-MISSING: no
GENERAL.PHYS-PORT-ID: --
GENERAL.CONNECTION: team-team0
GENERAL.CON-UUID: 50b6768e-2644-4770-953e-a3e818cb953d
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
GENERAL.METERED: no (guessed)
CAPABILITIES.CARRIER-DETECT: yes
CAPABILITIES.SPEED: unknown
CAPABILITIES.IS-SOFTWARE: yes
TEAM.SLAVES: eth1
TEAM.CONFIG: { "device": "team0", "ports": { "eth1": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
CONNECTIONS.AVAILABLE-CONNECTION-PATHS: /org/freedesktop/NetworkManager/Settings/{13}
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: 50b6768e-2644-4770-953e-a3e818cb953d | team-team0
IP4.ADDRESS[1]: 192.168.100.239/24
IP4.GATEWAY: 192.168.100.1
IP4.DNS[1]: 192.168.100.1
DHCP4.OPTION[1]: requested_ms_classless_static_routes = 1
DHCP4.OPTION[2]: requested_domain_search = 1
DHCP4.OPTION[3]: requested_host_name = 1
DHCP4.OPTION[4]: requested_time_offset = 1
DHCP4.OPTION[5]: requested_domain_name = 1
DHCP4.OPTION[6]: requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION[7]: requested_classless_static_routes = 1
DHCP4.OPTION[8]: dhcp_server_identifier = 192.168.100.1
DHCP4.OPTION[9]: requested_wpad = 1
DHCP4.OPTION[10]: requested_broadcast_address = 1
DHCP4.OPTION[11]: next_server = 192.168.100.1
DHCP4.OPTION[12]: expiry = 1466689002
DHCP4.OPTION[13]: requested_interface_mtu = 1
DHCP4.OPTION[14]: requested_subnet_mask = 1
DHCP4.OPTION[15]: routers = 192.168.100.1
DHCP4.OPTION[16]: dhcp_message_type = 5
DHCP4.OPTION[17]: ip_address = 192.168.100.239
DHCP4.OPTION[18]: broadcast_address = 192.168.100.255
DHCP4.OPTION[19]: requested_static_routes = 1
DHCP4.OPTION[20]: dhcp_renewal_time = 120
DHCP4.OPTION[21]: dhcp_lease_time = 240
DHCP4.OPTION[22]: requested_nis_servers = 1
DHCP4.OPTION[23]: requested_ntp_servers = 1
DHCP4.OPTION[24]: requested_domain_name_servers = 1
DHCP4.OPTION[25]: dhcp_rebinding_time = 210
DHCP4.OPTION[26]: domain_name_servers = 192.168.100.1
DHCP4.OPTION[27]: subnet_mask = 255.255.255.0
DHCP4.OPTION[28]: network_number = 192.168.100.0
DHCP4.OPTION[29]: requested_routers = 1
DHCP4.OPTION[30]: requested_nis_domain = 1
IP6.ADDRESS[1]: fe80::582d:2753:606e:77b2/64
IP6.GATEWAY:
[root@wlan-r2s5 NetworkManager]# nmcli connection delete id ethernet-eth1
Connection 'ethernet-eth1' (9b7449c7-c4fd-4020-b3d0-8ec8bf38260f) successfully deleted.
[root@wlan-r2s5 NetworkManager]# nmcli device
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected testeth0
team0 team connected team-team0
eth1 ethernet disconnected --
eth10 ethernet disconnected --
eth2 ethernet disconnected --
eth3 ethernet disconnected --
eth4 ethernet disconnected --
eth5 ethernet disconnected --
eth6 ethernet disconnected --
eth7 ethernet disconnected --
eth8 ethernet disconnected --
eth9 ethernet disconnected --
wlp4s0 wifi unavailable --
lo loopback unmanaged --
[root@wlan-r2s5 NetworkManager]# teamdctl team0 state dump
{
"setup": {
"daemonized": false,
"dbus_enabled": true,
"debug_level": 2,
"kernel_team_mode_name": "roundrobin",
"pid": 11350,
"pid_file": "/var/run/teamd/team0.pid",
"runner_name": "roundrobin",
"zmq_enabled": false
},
"team_device": {
"ifinfo": {
"dev_addr": "7e:0f:24:8c:a2:6f",
"dev_addr_len": 6,
"ifindex": 35,
"ifname": "team0"
}
}
}
[root@wlan-r2s5 NetworkManager]# nmcli -f all d show team0
GENERAL.DEVICE: team0
GENERAL.TYPE: team
GENERAL.NM-TYPE: NMDeviceTeam
GENERAL.VENDOR:
GENERAL.PRODUCT:
GENERAL.DRIVER: team
GENERAL.DRIVER-VERSION: 3.10.0-435.el7.x86_64
GENERAL.FIRMWARE-VERSION:
GENERAL.HWADDR: 7E:0F:24:8C:A2:6F
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.REASON: 0 (No reason given)
GENERAL.UDI: /sys/devices/virtual/net/team0
GENERAL.IP-IFACE: team0
GENERAL.IS-SOFTWARE: yes
GENERAL.NM-MANAGED: yes
GENERAL.AUTOCONNECT: yes
GENERAL.FIRMWARE-MISSING: no
GENERAL.NM-PLUGIN-MISSING: no
GENERAL.PHYS-PORT-ID: --
GENERAL.CONNECTION: team-team0
GENERAL.CON-UUID: 50b6768e-2644-4770-953e-a3e818cb953d
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
GENERAL.METERED: no (guessed)
CAPABILITIES.CARRIER-DETECT: yes
CAPABILITIES.SPEED: unknown
CAPABILITIES.IS-SOFTWARE: yes
TEAM.SLAVES:
TEAM.CONFIG: { "device": "team0", "ports": { "eth1": { "link_watch": { "name": "ethtool" } } }, "runner": { "name": "roundrobin" } }
CONNECTIONS.AVAILABLE-CONNECTION-PATHS: /org/freedesktop/NetworkManager/Settings/{13}
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: 50b6768e-2644-4770-953e-a3e818cb953d | team-team0
IP4.ADDRESS[1]: 192.168.100.239/24
IP4.GATEWAY: 192.168.100.1
IP4.DNS[1]: 192.168.100.1
DHCP4.OPTION[1]: requested_ms_classless_static_routes = 1
DHCP4.OPTION[2]: requested_domain_search = 1
DHCP4.OPTION[3]: requested_host_name = 1
DHCP4.OPTION[4]: requested_time_offset = 1
DHCP4.OPTION[5]: requested_domain_name = 1
DHCP4.OPTION[6]: requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION[7]: requested_classless_static_routes = 1
DHCP4.OPTION[8]: dhcp_server_identifier = 192.168.100.1
DHCP4.OPTION[9]: requested_wpad = 1
DHCP4.OPTION[10]: requested_broadcast_address = 1
DHCP4.OPTION[11]: next_server = 192.168.100.1
DHCP4.OPTION[12]: expiry = 1466689002
DHCP4.OPTION[13]: requested_interface_mtu = 1
DHCP4.OPTION[14]: requested_subnet_mask = 1
DHCP4.OPTION[15]: routers = 192.168.100.1
DHCP4.OPTION[16]: dhcp_message_type = 5
DHCP4.OPTION[17]: ip_address = 192.168.100.239
DHCP4.OPTION[18]: broadcast_address = 192.168.100.255
DHCP4.OPTION[19]: requested_static_routes = 1
DHCP4.OPTION[20]: dhcp_renewal_time = 120
DHCP4.OPTION[21]: dhcp_lease_time = 240
DHCP4.OPTION[22]: requested_nis_servers = 1
DHCP4.OPTION[23]: requested_ntp_servers = 1
DHCP4.OPTION[24]: requested_domain_name_servers = 1
DHCP4.OPTION[25]: dhcp_rebinding_time = 210
DHCP4.OPTION[26]: domain_name_servers = 192.168.100.1
DHCP4.OPTION[27]: subnet_mask = 255.255.255.0
DHCP4.OPTION[28]: network_number = 192.168.100.0
DHCP4.OPTION[29]: requested_routers = 1
DHCP4.OPTION[30]: requested_nis_domain = 1
IP6.ADDRESS[1]: fe80::582d:2753:606e:77b2/64
IP6.GATEWAY:
waiting some more time doesn't help
There were a couple of problems: we should read the ActualConfig instead of the Config so that non-active port are excluded; and we didn't update the configuration after the slaves changed. Unfortunately there is no asynchronous way to know when changes in the configuration are applied, so we must schedule a timer to read it again after some time (which kinda sucks). Please review last two patches in bg/team-conf-expose-rh1310435-v2 (for convenience based on bg/team-conf-read-rh1257237). looks good to me. bg/team-conf-expose-rh1310435-v2 LGTM Merged to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c44b13f87c21a75c701d1e54d2bb4abe48084ab4 dynamic config is correctly created and appending and removing slaves is reflected 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. https://rhn.redhat.com/errata/RHSA-2016-2581.html |
Description of problem: When default team profile is created it's (according to teamdctl) set as round-robin. [vbenes@trautenberg ~]$ sudo teamdctl nm-team state dump { "setup": { "daemonized": false, "dbus_enabled": true, "debug_level": 0, "kernel_team_mode_name": "roundrobin", "pid": 29998, "pid_file": "/var/run/teamd/nm-team.pid", "runner_name": "roundrobin", "zmq_enabled": false }, "team_device": { "ifinfo": { "dev_addr": "02:f6:da:7c:d9:d3", "dev_addr_len": 6, "ifindex": 14, "ifname": "nm-team" } } } But this config is not visible anywhere via NM, not in ifcfg, not via nmcli team.config: -- This causes lack of information in GUI tools using NM as underlying layer. Version-Release number of selected component (if applicable): NetworkManager-1.0.6-27.el7.x86_64 How reproducible: always Steps to Reproduce: 1.nmcli connection add type team ip4 1.2.3.6/24 2.nmcli con edit team 3.print Actual results: team.config: -- Expected results: at least some basic info about settup that was used. Additional info: