search for: team0

...> clients will not know to establish a new connection and will still > > attempt to send packets on the old connection. In this case, they > > should get a RST from the takeover node's TCP stack... so, this is > > strange. > Yes, we have a flat /16 network on team0 and man /24 subnets on > team1. It _feels_ like the clients on the team1 network are affected > more often but OTOH there are _much_ more clients in that network... OK, let's keep that in mind. :-) > Speaking of the wiki: https://wiki.samba.org/index.php/Setting_up_CTDB_for_Clustere...

...and everything works as expected. Now in order to get better performance we want to add a VF "ens2", but we don't want a new IP address. Now if I understand correctly what will happen is that when "ens2" appears on the system teamd will then create a new team interface "team0". Before teamd can enslave ens1 it has to down the interface if I understand things correctly. This means that we have to disrupt network traffic in order for this to work. To give you an idea of where we were before this became about trying to do this in the team or bonding driver, we were d...

...and everything works as expected. Now in order to get better performance we want to add a VF "ens2", but we don't want a new IP address. Now if I understand correctly what will happen is that when "ens2" appears on the system teamd will then create a new team interface "team0". Before teamd can enslave ens1 it has to down the interface if I understand things correctly. This means that we have to disrupt network traffic in order for this to work. To give you an idea of where we were before this became about trying to do this in the team or bonding driver, we were d...

.... Now in order to get better >>performance we want to add a VF "ens2", but we don't want a new IP >>address. Now if I understand correctly what will happen is that when >>"ens2" appears on the system teamd will then create a new team >>interface "team0". Before teamd can enslave ens1 it has to down the > > No, you don't understand that correctly. > > There is always ens1 and team0. ens1 is a slave of team0. team0 is the > interface to use, to set ip on etc. > > When ens2 appears, it gets enslaved to team0 as well. &g...

.... Now in order to get better >>performance we want to add a VF "ens2", but we don't want a new IP >>address. Now if I understand correctly what will happen is that when >>"ens2" appears on the system teamd will then create a new team >>interface "team0". Before teamd can enslave ens1 it has to down the > > No, you don't understand that correctly. > > There is always ens1 and team0. ens1 is a slave of team0. team0 is the > interface to use, to set ip on etc. > > When ens2 appears, it gets enslaved to team0 as well. &g...

...orks as expected. Now in order to get better >performance we want to add a VF "ens2", but we don't want a new IP >address. Now if I understand correctly what will happen is that when >"ens2" appears on the system teamd will then create a new team >interface "team0". Before teamd can enslave ens1 it has to down the No, you don't understand that correctly. There is always ens1 and team0. ens1 is a slave of team0. team0 is the interface to use, to set ip on etc. When ens2 appears, it gets enslaved to team0 as well. >interface if I understand th...

...o get better >>>performance we want to add a VF "ens2", but we don't want a new IP >>>address. Now if I understand correctly what will happen is that when >>>"ens2" appears on the system teamd will then create a new team >>>interface "team0". Before teamd can enslave ens1 it has to down the >> >> No, you don't understand that correctly. >> >> There is always ens1 and team0. ens1 is a slave of team0. team0 is the >> interface to use, to set ip on etc. >> >> When ens2 appears, it gets e...

...;>>>performance we want to add a VF "ens2", but we don't want a new IP >>>>address. Now if I understand correctly what will happen is that when >>>>"ens2" appears on the system teamd will then create a new team >>>>interface "team0". Before teamd can enslave ens1 it has to down the >>> >>> No, you don't understand that correctly. >>> >>> There is always ens1 and team0. ens1 is a slave of team0. team0 is the >>> interface to use, to set ip on etc. >>> >>>...

...;>>>performance we want to add a VF "ens2", but we don't want a new IP >>>>address. Now if I understand correctly what will happen is that when >>>>"ens2" appears on the system teamd will then create a new team >>>>interface "team0". Before teamd can enslave ens1 it has to down the >>> >>> No, you don't understand that correctly. >>> >>> There is always ens1 and team0. ens1 is a slave of team0. team0 is the >>> interface to use, to set ip on etc. >>> >>>...

On Wed, Dec 16, 2015 at 4:47 PM, Earl A Ramirez <earlaramirez at gmail.com> wrote: > I don't see 'System' in any of the CentOS 7.2.1511 boxes or VMs that were > recently upgraded: > ?Hi Earl, Have you tried a new install?? I agree, upgraded installations do not seem to be affected.

...---------------------------------------------------------------------- 1 | System <unset> | 2015-12-20 15:17 | Install | 297 $ nmcli con NAME UUID TYPE DEVICE Team connection 1 c179d7da-8f12-4a80-8ce8-1621ba108d8b team team0 team0 slave 2 449506ad-bdc5-49ec-8bb9-5f31a9dbe4e7 802-3-ethernet ens8 team0 slave 1 25d843c0-8835-442e-a126-226dcfa89fe5 802-3-ethernet eth0 eth0 73bda044-f940-40d0-a871-8cf388f65695 802-3-ethernet -- -- Kind Regards Earl Ramirez

Hello I have a problem with attaching VMs to a VLAN interface. Here is my setup: I have several physical hosts connected by a physical switch.  Each host has two NICs leading to the switch, which have been combined into a team, team0. Each host a has a bridge br1, which has team0 as a slave. So communication between hosts is based on the IP address of bridge br1 on each host. Up until recently, using libvirt and KVM, I was creating VMs which had one interface attached the default virtual network and one interface attached...

...aming seems to be bond++ of a sort, so I thought I would at least try it.? So here's the scenario: 1.) Server with two gigabit ethernet ports, two Cisco switches. 2.) During install, used the 'Server with GUI' group and added the virtualization packages. 3.) During install, set up team0 to include the two gig-e ports set up active-backup (two switches). 4.) During install, set up three bridges, with the slave devices being VLANs pointed to the team0 subinterfaces (using VLANs 68, 101, and 302; 101 is to be the management bridge for the host, with guests on all three VLANs).?...

...wrote: >> Hello >> >> I have a problem with attaching VMs to a VLAN interface. >> >> Here is my setup: I have several physical hosts connected by a >> physical switch.  Each host has two NICs leading to the switch, which >> have been combined into a team, team0. Each host a has a bridge br1, >> which has team0 as a slave. So communication between hosts is based >> on the IP address of bridge br1 on each host. >> >> Up until recently, using libvirt and KVM, I was creating VMs which >> had one interface attached the default...

...7 PM, Richard Achmatowicz wrote: > Hello > > I have a problem with attaching VMs to a VLAN interface. > > Here is my setup: I have several physical hosts connected by a physical > switch.  Each host has two NICs leading to the switch, which have been > combined into a team, team0. Each host a has a bridge br1, which has > team0 as a slave. So communication between hosts is based on the IP > address of bridge br1 on each host. > > Up until recently, using libvirt and KVM, I was creating VMs which had > one interface attached the default virtual network and...

...ught I would at least try it. > So > here's the scenario: > > 1.) Server with two gigabit ethernet ports, two Cisco switches. > > 2.) During install, used the 'Server with GUI' group and added the > virtualization packages. > > 3.) During install, set up team0 to include the two gig-e ports set > up > active-backup (two switches). > > 4.) During install, set up three bridges, with the slave devices > being > VLANs pointed to the team0 subinterfaces (using VLANs 68, 101, and > 302; > 101 is to be the management bridge for the h...

On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Tue, Feb 20, 2018 at 11:33:56PM CET, kubakici at wp.pl wrote: >>>>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:

On Wed, Feb 21, 2018 at 8:11 AM, Jiri Pirko <jiri at resnulli.us> wrote: > Wed, Feb 21, 2018 at 04:56:48PM CET, alexander.duyck at gmail.com wrote: >>On Wed, Feb 21, 2018 at 1:51 AM, Jiri Pirko <jiri at resnulli.us> wrote: >>> Tue, Feb 20, 2018 at 11:33:56PM CET, kubakici at wp.pl wrote: >>>>On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote:

...gt;> I have a problem with attaching VMs to a VLAN interface. >>>> >>>> Here is my setup: I have several physical hosts connected by a >>>> physical switch.  Each host has two NICs leading to the switch, >>>> which have been combined into a team, team0. Each host a has a >>>> bridge br1, which has team0 as a slave. So communication between >>>> hosts is based on the IP address of bridge br1 on each host. >>>> >>>> Up until recently, using libvirt and KVM, I was creating VMs which >>>>...

...t;>> >>> I have a problem with attaching VMs to a VLAN interface. >>> >>> Here is my setup: I have several physical hosts connected by a >>> physical switch.  Each host has two NICs leading to the switch, >>> which have been combined into a team, team0. Each host a has a >>> bridge br1, which has team0 as a slave. So communication between >>> hosts is based on the IP address of bridge br1 on each host. >>> >>> Up until recently, using libvirt and KVM, I was creating VMs which >>> had one interface a...