search for: ens1

.... > > What? You have routes on the team netdev. virtio_net and VF are only > slaves. What are you talking about? I don't get it :/ So lets walk though this by example. The general idea of the base case for all this is somebody starting with virtio_net, we will call the interface "ens1" for now. It comes up and is assigned a dhcp address 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 th...

.... > > What? You have routes on the team netdev. virtio_net and VF are only > slaves. What are you talking about? I don't get it :/ So lets walk though this by example. The general idea of the base case for all this is somebody starting with virtio_net, we will call the interface "ens1" for now. It comes up and is assigned a dhcp address 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 th...

...u have routes on the team netdev. virtio_net and VF are only >> slaves. What are you talking about? I don't get it :/ > >So lets walk though this by example. The general idea of the base case >for all this is somebody starting with virtio_net, we will call the >interface "ens1" for now. It comes up and is assigned a dhcp address >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&quo...

...team netdev. virtio_net and VF are only >>> slaves. What are you talking about? I don't get it :/ >> >>So lets walk though this by example. The general idea of the base case >>for all this is somebody starting with virtio_net, we will call the >>interface "ens1" for now. It comes up and is assigned a dhcp address >>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 >&g...

...team netdev. virtio_net and VF are only >>> slaves. What are you talking about? I don't get it :/ >> >>So lets walk though this by example. The general idea of the base case >>for all this is somebody starting with virtio_net, we will call the >>interface "ens1" for now. It comes up and is assigned a dhcp address >>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 >&g...

..._net and VF are only >>>> slaves. What are you talking about? I don't get it :/ >>> >>>So lets walk though this by example. The general idea of the base case >>>for all this is somebody starting with virtio_net, we will call the >>>interface "ens1" for now. It comes up and is assigned a dhcp address >>>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...

...>>>>> slaves. What are you talking about? I don't get it :/ >>>> >>>>So lets walk though this by example. The general idea of the base case >>>>for all this is somebody starting with virtio_net, we will call the >>>>interface "ens1" for now. It comes up and is assigned a dhcp address >>>>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 ha...

...>>>>> slaves. What are you talking about? I don't get it :/ >>>> >>>>So lets walk though this by example. The general idea of the base case >>>>for all this is somebody starting with virtio_net, we will call the >>>>interface "ens1" for now. It comes up and is assigned a dhcp address >>>>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 ha...

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:

...master devices seems quite natural in this > case. I figured I had overlooked something like that.. Thanks for pointing this out. Okay so I think the phys_port_name approach might resolve the original issue. If I am reading things correctly what we end up with is the master showing up as "ens1" for example and the backup showing up as "ens1nbackup". Am I understanding that right? The problem with the team/bond%d approach is that it creates a new netdevice and so it would require guest configuration changes. > IMHO phys_port_name == "backup" if BACKUP bit is...

...master devices seems quite natural in this > case. I figured I had overlooked something like that.. Thanks for pointing this out. Okay so I think the phys_port_name approach might resolve the original issue. If I am reading things correctly what we end up with is the master showing up as "ens1" for example and the backup showing up as "ens1nbackup". Am I understanding that right? The problem with the team/bond%d approach is that it creates a new netdevice and so it would require guest configuration changes. > IMHO phys_port_name == "backup" if BACKUP bit is...

...> case. >> >> I figured I had overlooked something like that.. Thanks for pointing >> this out. Okay so I think the phys_port_name approach might resolve >> the original issue. If I am reading things correctly what we end up >> with is the master showing up as "ens1" for example and the backup >> showing up as "ens1nbackup". Am I understanding that right? >> >> The problem with the team/bond%d approach is that it creates a new >> netdevice and so it would require guest configuration changes. >> >>> IMHO phy...

...> case. >> >> I figured I had overlooked something like that.. Thanks for pointing >> this out. Okay so I think the phys_port_name approach might resolve >> the original issue. If I am reading things correctly what we end up >> with is the master showing up as "ens1" for example and the backup >> showing up as "ens1nbackup". Am I understanding that right? >> >> The problem with the team/bond%d approach is that it creates a new >> netdevice and so it would require guest configuration changes. >> >>> IMHO phy...

...ral in this > > case. > > I figured I had overlooked something like that.. Thanks for pointing > this out. Okay so I think the phys_port_name approach might resolve > the original issue. If I am reading things correctly what we end up > with is the master showing up as "ens1" for example and the backup > showing up as "ens1nbackup". Am I understanding that right? Yes, provided systemd is new enough. > The problem with the team/bond%d approach is that it creates a new > netdevice and so it would require guest configuration changes. > > &g...

...> >> I figured I had overlooked something like that.. Thanks for pointing > >> this out. Okay so I think the phys_port_name approach might resolve > >> the original issue. If I am reading things correctly what we end up > >> with is the master showing up as "ens1" for example and the backup > >> showing up as "ens1nbackup". Am I understanding that right? > >> > >> The problem with the team/bond%d approach is that it creates a new > >> netdevice and so it would require guest configuration changes. > >&...

...natural in this >> case. > > I figured I had overlooked something like that.. Thanks for pointing > this out. Okay so I think the phys_port_name approach might resolve > the original issue. If I am reading things correctly what we end up > with is the master showing up as "ens1" for example and the backup > showing up as "ens1nbackup". Am I understanding that right? > > The problem with the team/bond%d approach is that it creates a new > netdevice and so it would require guest configuration changes. > >> IMHO phys_port_name == "bac...

...> I figured I had overlooked something like that.. Thanks for pointing >>>> this out. Okay so I think the phys_port_name approach might resolve >>>> the original issue. If I am reading things correctly what we end up >>>> with is the master showing up as "ens1" for example and the backup >>>> showing up as "ens1nbackup". Am I understanding that right? >>>> >>>> The problem with the team/bond%d approach is that it creates a new >>>> netdevice and so it would require guest configuration changes...

...> I figured I had overlooked something like that.. Thanks for pointing >>>> this out. Okay so I think the phys_port_name approach might resolve >>>> the original issue. If I am reading things correctly what we end up >>>> with is the master showing up as "ens1" for example and the backup >>>> showing up as "ens1nbackup". Am I understanding that right? >>>> >>>> The problem with the team/bond%d approach is that it creates a new >>>> netdevice and so it would require guest configuration changes...

...gt; >>> I figured I had overlooked something like that.. Thanks for pointing >>> this out. Okay so I think the phys_port_name approach might resolve >>> the original issue. If I am reading things correctly what we end up >>> with is the master showing up as "ens1" for example and the backup >>> showing up as "ens1nbackup". Am I understanding that right? >>> >>> The problem with the team/bond%d approach is that it creates a new >>> netdevice and so it would require guest configuration changes. >>> &...