Created attachment 966887 [details] excert from /var/log/messages Description of problem: while NetworkManager running cannot create a team device. teamd -d succeeds, but the device is immediately disapeared. Version-Release number of selected component (if applicable): [root@localhost ~]# yum info NetworkManager Loaded plugins: langpacks Installed Packages Name : NetworkManager Arch : x86_64 Epoch : 1 Version : 0.9.10.0 Release : 14.git20140704.fc21 [root@localhost ~]# yum info teamd Loaded plugins: langpacks Installed Packages Name : teamd Arch : x86_64 Version : 1.14 Release : 1.fc21 How reproducible: Always. Steps to Reproduce: 1.Test system is F21 Server KVM with functioning Linux Bridged eth0 and functioning OVS-bridged eth1 2.Try to create a team device e.g. 'teamd -d' 3.no team device exists in 'ip link' Actual results: /var/log/messages shows device created and immediately destroyed by NetworkManager Expected results: team device should be created and useable. Additional info: teamd device creation is fully functional on Fedora 21 after executing systemctl stop NetworkManager.service This seems to be a NetworkManager regression as I have it working under F20. Initially raised problem on teamd mailing list where Jiri Pirko suggetsed that I contact NetworkManager folks. Another potential data point: nmcli however was able to create a team device- (not that that was much use to me with thi Regression) see: https://lists.fedorahosted.org/pipermail/libteam/2014-December/000330.html
This is clearly an NM bug and NM should not be doing this. NM should be treating the team interface as an externally-created interface that NM does not touch until the user requests NM to do so (if ever).
Taking this. I've done changes related to this in master and will backport the fix.
lr/teamd-rh1172734 ready for review.
Also, the connection assumption does not really work without: https://github.com/jpirko/libteam/commit/870be5ad91ca0bf380dc3ffcad919ec94ff28958
If you want nm_device_team_watch_dbus() to be called for all NMDeviceTeam objects, you should override constructed() and do it there, rather than doing it from the _new* methods. Other than that, looks good.
(In reply to Dan Winship from comment #5) > If you want nm_device_team_watch_dbus() to be called for all NMDeviceTeam > objects, you should override constructed() and do it there, rather than > doing it from the _new* methods. Okay, that avoid some code duplication too. Done. > Other than that, looks good. Updated branch: lr/teamd-rh1172734
looks good, although: >+ if (G_OBJECT_CLASS (nm_device_team_parent_class)->constructed) >+ G_OBJECT_CLASS (nm_device_team_parent_class)->constructed (object); You don't actually need the if(); GObjectClass defines a dummy constructed() method, specifically so that you can chain up without needing to check that it's non-NULL first.
Pushed to master 8c32ea9 libnm-glib/nm-client: zero the CheckConnectivityData structure 15acfac team: improve handling of externally managed devices (rh #1172734) 03a5a85 team: get configuration only when teamd appears on bus for externally added interfaces 744e35e Revert "team: start teamd when ensuring team connection else teamdctl_connect() fails" Backported to 0.9.10 branch as well; along with a related fix by Thomas colin, the package is being built here: http://koji.fedoraproject.org/koji/taskinfo?taskID=8560171 I didn't submit an update yet, but we'll hopefully be releasing a new version of 0.9.10 branch along with a Fedora package update soon.
Great! I can test the fix on the test VM which triggered this bug. @Lubomir I don't see any installables at that link, just src rpms ? Will check back later. Colin.
(In reply to colin from comment #9) > Great! > > I can test the fix on the test VM which triggered this bug. > > @Lubomir I don't see any installables at that link, just src rpms ? The green links are links to successful rebuilds of a src rpm for a particular architecture. Please follow one that ends with your architecture name and you'll be able to download binary packages. It's a "scratch build", the links will expire in around a week I think.
Seems like this was fixed by FEDORA-2015-0529 update NetworkManager-0.9.10.1-1.2.20150109git.fc21 [1]. I intended to wait for an upstream release, but seems like Jirka was faster. [1] https://admin.fedoraproject.org/updates/FEDORA-2015-0529/NetworkManager-0.9.10.1-1.2.20150109git.fc21
Created attachment 992383 [details] Journal output showing failure
This problem has reappeared in NetworkManager-0.9.10.1-1.4.20150115git.fc21.x86_64 - With NetworkManager enabled, the devices managed by teamd are deactivated. I have attached my journal output showing the attempt to start the device with 'nmcli con up team0' which results in an immediate deactivation, the turning off of NetworkManager, and the activation of the interface with 'teamd -g -f /etc/teamd.d/team0.conf -d'
Reopening for continued regression. If a new bug needs to be submitted, I will do so.
(In reply to Dan Mossor from comment #14) > Reopening for continued regression. If a new bug needs to be submitted, I > will do so. Please submit a separate bug -- this seems to be a different issue. Your team daemon has been terminated because a connection was activated on it: Feb 17 22:40:06 hp3.example.net NetworkManager[880]: <info> (team0): disconnecting for new activation request. Unfortunately the log is incomplete so I can't find out what caused it to be activated -- whether it was an user request or autoactivation. In case you'll open another bug, please attach a more complete log, preferrably from the NetworkManager startup. The NetworkManager 1.0 which will be included in Fedora 22 will handle the externally created devices a bit more robustly. Maybe the issue you're experiencing can be avoided with a configuration change though. Thank you.