Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

["Samudrala, Sridhar" <sridhar.samudrala@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]


On 2/21/2019 7:33 PM, si-wei liu wrote:
>
>
> On 2/21/2019 5:39 PM, Michael S. Tsirkin wrote:
>> On Thu, Feb 21, 2019 at 05:14:44PM -0800, Siwei Liu wrote:
>>> Sorry for replying to this ancient thread. There was some remaining
>>> issue that I don't think the initial net_failover patch got addressed
>>> cleanly, see:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
>>>
>>> The renaming of 'eth0' to 'ens4' fails because the udev userspace was
>>> not specifically writtten for such kernel automatic enslavement.
>>> Specifically, if it is a bond or team, the slave would typically get
>>> renamed *before* virtual device gets created, that's what udev can
>>> control (without getting netdev opened early by the other part of
>>> kernel) and other userspace components for e.g. initramfs,
>>> init-scripts can coordinate well in between. The in-kernel
>>> auto-enslavement of net_failover breaks this userspace convention,
>>> which don't provides a solution if user care about consistent naming
>>> on the slave netdevs specifically.
>>>
>>> Previously this issue had been specifically called out when IFF_HIDDEN
>>> and the 1-netdev was proposed, but no one gives out a solution to this
>>> problem ever since. Please share your mind how to proceed and solve
>>> this userspace issue if netdev does not welcome a 1-netdev model.
>> Above says:
>>
>>     there's no motivation in the systemd/udevd community at
>>     this point to refactor the rename logic and make it work well with
>>     3-netdev.
>>
>> What would the fix be? Skip slave devices?
>>
> There's nothing user can get if just skipping slave devices - the name 
> is still unchanged and unpredictable e.g. eth0, or eth1 the next 
> reboot, while the rest may conform to the naming scheme (ens3 and 
> such). There's no way one can fix this in userspace alone - when the 
> failover is created the enslaved netdev was opened by the kernel 
> earlier than the userspace is made aware of, and there's no 
> negotiation protocol for kernel to know when userspace has done 
> initial renaming of the interface. I would expect netdev list should 
> at least provide the direction in general for how this can be solved...
>
Is there an issue if slave device names are not predictable? The user/admin scripts are expected
to only work with the master failover device.
Moreover, you were suggesting hiding the lower slave devices anyway. There was some discussion
about moving them to a hidden network namespace so that they are not visible from the default namespace.
I looked into this sometime back, but did not find the right kernel api to create a network namespace within
kernel. If so, we could use this mechanism to simulate a 1-netdev model.


> -Siwei
>
>

[-- Attachment #2: Type: text/html, Size: 4363 bytes --]