[summary] virtio network device failover writeup

Michael S. Tsirkin
Thu, 21 Mar 2019 12:37:29 -0000

On Thu, Mar 21, 2019 at 12:07:57PM +0200, Liran Alon
wrote:
> >>>> 2) It brings non-intuitive customer experience. For
example, a customer may attempt to analyse connectivity issue by checking the
connectivity
> >>>> on a net-failover slave (e.g. the VF) 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
instead of MAC. (Similar to as done in NetVSC). E.g. Provide a virtio-net
interface to get PCI slot where the matching VF will be hot-plugged by
hypervisor.
> >>>> 3) Have an explicit virtio-net control message to command
hypervisor to switch data-path from virtio-net to VF and vice-versa. Instead of
relying on intercepting the PCI master enable-bit
> >>>> as an indicator on when VF is about to be set up. (Similar
to as done in NetVSC).
> >>>>
> >>>> Is there any clear issue we see regarding the above
suggestion?
> >>>>
> >>>> -Liran
> >>>
> >>> The issue would be this: how do we avoid conflicting with
namespaces
> >>> created by users?
> >>
> >> This is kinda controversial, but maybe separate netns names into 2
groups: hidden and normal.
> >> To reference a hidden netns, you need to do it explicitly.
> >> Hidden and normal netns names can collide as they will be
maintained in different namespaces (Yes I?m overloading the term namespace
here?).
> >
> > Maybe it's an unnamed namespace. Hidden until userspace gives it a
name?
>
> This is also a good idea that will solve the issue. Yes.
>
> >
> >> Does this seems reasonable?
> >>
> >> -Liran
> >
> > Reasonable I'd say yes, easy to implement probably no. But maybe I
> > missed a trick or two.
>
> BTW, from a practical point of view, I think that even until we figure out
a solution on how to implement this,
> it was better to create an kernel auto-generated name (e.g.
?kernel_net_failover_slaves")
> that will break only userspace workloads that by a very rare-chance have a
netns that collides with this then
> the breakage we have today for the various userspace components.
>
> -Liran

It seems quite easy to supply that as a module parameter. Do we need two
namespaces though? Won't some userspace still be confused by the two
slaves sharing the MAC address?

--
MST