|
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
|
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
