On a centos 7 virtual box, I create a team like this:
nmcli connection add type team con-name team0 ifname veteam0
nmcli connection modify team0 team.config roundrobin.conf
[root@rhce1 ~]# cat roundrobin.conf
{
"device": "team0",
"runner": {"name": "roundrobin"},
"ports": {"enp0s9": {}, "enp0s10": {}}
}
# add slave interfaces
nmcli connection add type team-slave con-name team0-port0 ifname enp0s9 master team0
nmcli connection add type team-slave con-name team0-port1 ifname enp0s10 master team0
I now have the following connections:
[root@rhce1 ~]# nmcli con s
NAME UUID TYPE DEVICE
team0 77869010-af1a-48a5-b10b-c05b3035837f team veteam0
team0-port1 99f54013-b20b-41d2-9661-d654b89870bd 802-3-ethernet enp0s10
team0-port0 3f5e5924-f7f3-409a-b4cb-661904ddbf60 802-3-ethernet enp0s9
Wired connection 1 acc2747d-9576-4ac5-a06a-d45d3a9a4ff4 802-3-ethernet enp0s3
enp0s3 b4db7dd8-8735-4590-b12f-621d1003841a 802-3-ethernet --
hostonly 8993c4c0-fa90-455d-ae83-d1a644c36886 802-3-ethernet enp0s8
This brings all interfaces up correctly:
[root@rhce1 ~]# nmcli dev status
DEVICE TYPE STATE CONNECTION
enp0s10 ethernet connected team0-port1
enp0s3 ethernet connected Wired connection 1
enp0s8 ethernet connected hostonly
enp0s9 ethernet connected team0-port0
veteam0 team connected team0
lo loopback unmanaged --
and I get an IP from dhcp for my virtual team interface:
[root@rhce1 ~]# ip addr show veteam0
6: veteam0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 08:00:27:c7:15:f1 brd ff:ff:ff:ff:ff:ff
inet 10.23.23.104/24 brd 10.23.23.255 scope global dynamic veteam0
valid_lft 1073sec preferred_lft 1073sec
inet6 fe80::a00:27ff:fec7:15f1/64 scope link tentative dadfailed
valid_lft forever preferred_lft forever
(I am aware that in a typical teaming use case, dhcp is probably not being used, but the main problem also exists with static IPs.)
Now I would like to be able to take the connection down, and later up again, without reboot:
[root@rhce1 ~]# nmcli con down team0
[root@rhce1 ~]# nmcli dev status
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet connected Wired connection 1
enp0s8 ethernet connected hostonly
enp0s10 ethernet disconnected --
enp0s9 ethernet disconnected --
lo loopback unmanaged --
[root@rhce1 ~]# nmcli con up team0
Error: Device 'veteam0' is waiting for slaves before proceeding with activation.
[root@rhce1 ~]# nmcli dev status
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet connected Wired connection 1
enp0s8 ethernet connected hostonly
veteam0 team connecting (getting IP configuration) team0
enp0s10 ethernet disconnected --
enp0s9 ethernet unavailable --
lo loopback unmanaged -
Now can get the team interface working half way, by connecting enp0s10 first:
[root@rhce1 ~]# nmcli dev connect enp0s10
Device 'enp0s10' successfully activated with '99f54013-b20b-41d2-9661-d654b89870bd'.
[root@rhce1 ~]# nmcli con up team0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
But my team now just consists of one device:
[root@rhce1 ~]# nmcli dev st
DEVICE TYPE STATE CONNECTION
enp0s10 ethernet connected team0-port1
enp0s3 ethernet connected Wired connection 1
enp0s8 ethernet connected hostonly
veteam0 team connected team0
enp0s9 ethernet unavailable --
lo loopback unmanaged --
My problem is, I currently do not see how to bring enp0s9 up without a reboot, since the device is in state "unavailable". Is my understanding correct, that I should be able to bring enp0s9 up without a reboot, just like enp0s10? To me it looks like there is something fishy with my device enp0s9, but I do not quite see what. I already tried assigning new MAC addresses, but no help. Also, using traditional ifcfg configuration, I can bring my team0 interface up and down without a problem.
Or could it be that my virtual switch (I am using the VirtualBox hostonly network) does not support (? - or needs to be configured to support) teaming?
EDIT: I tried building a team with just one slave. That worked, and I got the same behavior using enp0s9 and enp0s10 - I had to connect the device first bevor I could up the connection. Does this imply my virtual switch is disconnecting one device (which by chance is enp0s9 - but because its deterministic its always enp0s9)?
I don't really need to "Solve" this - I would be happy to give the bounty to someone who helps me understand what is going on.
