[summary] virtio network device failover writeup

Liran Alon
Thu, 21 Mar 2019 12:48:05 -0000

> On 21 Mar 2019, at 14:37, Michael S. Tsirkin <mst at redhat.com>
wrote:
>
> 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?

That?s one reasonable option.
Another one is that we will indeed change the mechanism by which we determine a
VF should be bonded with a virtio-net device.
i.e. Expose a new virtio-net property that specify the PCI slot of the VF to be
bonded with.

The second seems cleaner but I don?t have a strong opinion on this. Both seem
reasonable to me and your suggestion is faster to implement from current state
of things.

-Liran

>
> --
> MST