search for: netn

Hi David, Michael, Stefan, I'm restarting to work on this topic since Kata guys are interested to have that, especially on the guest side. While working on the v2 I had few doubts, and I'd like to have your suggestions: 1. netns assigned to the device inside the guest Currently I assigned this device to 'init_net'. Maybe it is better if we allow the user to decide which netns assign to the device or to disable this new feature to have the same behavior as before (host reachable from any netns). I t...

Hi David, Michael, Stefan, I'm restarting to work on this topic since Kata guys are interested to have that, especially on the guest side. While working on the v2 I had few doubts, and I'd like to have your suggestions: 1. netns assigned to the device inside the guest Currently I assigned this device to 'init_net'. Maybe it is better if we allow the user to decide which netns assign to the device or to disable this new feature to have the same behavior as before (host reachable from any netns). I t...

...Stefano Garzarella wrote: > Hi David, Michael, Stefan, > I'm restarting to work on this topic since Kata guys are interested to > have that, especially on the guest side. > > While working on the v2 I had few doubts, and I'd like to have your > suggestions: > > 1. netns assigned to the device inside the guest > > Currently I assigned this device to 'init_net'. Maybe it is better > if we allow the user to decide which netns assign to the device > or to disable this new feature to have the same behavior as before > (host reachabl...

...Stefano Garzarella wrote: > Hi David, Michael, Stefan, > I'm restarting to work on this topic since Kata guys are interested to > have that, especially on the guest side. > > While working on the v2 I had few doubts, and I'd like to have your > suggestions: > > 1. netns assigned to the device inside the guest > > Currently I assigned this device to 'init_net'. Maybe it is better > if we allow the user to decide which netns assign to the device > or to disable this new feature to have the same behavior as before > (host reach...

...ng the connectivity on the net-failover master netdev shows correct connectivity. >>>>>>>>>> >>>>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>>>> 2) Match the virtio-net and...

...ng the connectivity on the net-failover master netdev shows correct connectivity. >>>>>>>>>> >>>>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>>>> 2) Match the virtio-net and...

...vity when in-fact checking the connectivity on the net-failover master netdev shows correct connectivity. >>>>>>>> >>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>> 2) Match the virtio-net and the VF based on...

...vity when in-fact checking the connectivity on the net-failover master netdev shows correct connectivity. >>>>>>>> >>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>> 2) Match the virtio-net and the VF based on...

...he net-failover master netdev shows correct connectivity. >>>>>>>>>>>> >>>>>>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>>>>>> 2) Match th...

...he net-failover master netdev shows correct connectivity. >>>>>>>>>>>> >>>>>>>>>>>> The set of changes I vision to fix our issues are: >>>>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>>>>>>>> 2) Match th...

On 12/07/2023 17:48, Ido Schimmel wrote: > On Tue, Jul 11, 2023 at 04:54:15PM -0700, Kuniyuki Iwashima wrote: >> When we create an L2 loop on a bridge in netns, we will see packets storm >> even if STP is enabled. >> >> # unshare -n >> # ip link add br0 type bridge >> # ip link add veth0 type veth peer name veth1 >> # ip link set veth0 master br0 up >> # ip link set veth1 master br0 up >> # ip l...

When we create an L2 loop on a bridge in netns, we will see packets storm even if STP is enabled. # unshare -n # ip link add br0 type bridge # ip link add veth0 type veth peer name veth1 # ip link set veth0 master br0 up # ip link set veth1 master br0 up # ip link set br0 type bridge stp_state 1 # ip link set br0 up # sleep 30...

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in different...

Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) in vsock. As we partially discussed in the multi-transport proposal [1], it could be nice to support network namespace in vsock to reach the following goals: - isolate host applications from guest applications using the same ports with CID_ANY - assign the same CID of VMs running in different...

...vity on the net-failover master netdev shows correct connectivity. > >>>>>>>>>> > >>>>>>>>>> The set of changes I vision to fix our issues are: > >>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. > >>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). > >>>>>>>>>> 2) Match the virt...

...> > > OK. Now what happens if master is moved to another namespace? Do we need > > > to move the slaves too? > > > > No. Why would we move the slaves? The whole point is to make most customer ignore the net-failover slaves and remain them ?hidden? in their dedicated netns. > > We won?t prevent customer from explicitly moving the net-failover slaves out of this netns, but we will not move them out of there automatically. > > > The 2-device netvsc already handles case where master changes namespace. Is it by moving slave with it? -- MST

...> > > OK. Now what happens if master is moved to another namespace? Do we need > > > to move the slaves too? > > > > No. Why would we move the slaves? The whole point is to make most customer ignore the net-failover slaves and remain them ?hidden? in their dedicated netns. > > We won?t prevent customer from explicitly moving the net-failover slaves out of this netns, but we will not move them out of there automatically. > > > The 2-device netvsc already handles case where master changes namespace. Is it by moving slave with it? -- MST

...t;> OK. Now what happens if master is moved to another namespace? Do we need >>>> to move the slaves too? >>> >>> No. Why would we move the slaves? The whole point is to make most customer ignore the net-failover slaves and remain them ?hidden? in their dedicated netns. >>> We won?t prevent customer from explicitly moving the net-failover slaves out of this netns, but we will not move them out of there automatically. >> >> >> The 2-device netvsc already handles case where master changes namespace. > > Is it by moving slave wit...

...master netdev shows correct connectivity. > >>>>>>>>>>>> > >>>>>>>>>>>> The set of changes I vision to fix our issues are: > >>>>>>>>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. > >>>>>>>>>>>> (E.g. Configure the net-failover VF slave in some special way). > >>>>>>>>>>>> 2...

...but will see no connectivity when in-fact checking the connectivity on the net-failover master netdev shows correct connectivity. >>>>>> >>>>>> The set of changes I vision to fix our issues are: >>>>>> 1) Hide net-failover slaves in a different netns created and managed by the kernel. But that user can enter to it and manage the netdevs there if wishes to do so explicitly. >>>>>> (E.g. Configure the net-failover VF slave in some special way). >>>>>> 2) Match the virtio-net and the VF based on a PV attribute...