[systemd-devel] Better network naming on Hyper-V/Azure?

[Lennart Poettering]

On Mo, 06.01.20 15:36, Stephen Hemminger (stephen at networkplumber.org) wrote:

> About a year ago there was some discussion on having persistent network names
> on Hyper-V/Azure. Haiyang did some patches to add an attribute which
> could be used by udev to do this. But there are some reluctance because
> of how the channel id works.
>
> The motivation to provide network naming is to allow vmbus to change to parallel probing.
> Right now probing is serialized so naming is always in same order.
>
> My question is what exactly does systemd/udev need to provide persistent
> naming. The obvious ones are:
>   1. Must be unique (although PCI slot isn't)

It's not unique per bus? huh?

>   2. Must be persistent across reboot.
>   3. Must be stable if device is removed.

Yes, these three are the idea.

> There are more questions.
>   1. Is there a particular ordering and non-reuse requirement.
>      Obviously, names have to be 15 characters or less but what
>   else.

No ordering or non-reuse requirements are made. I mean, the device
path names are in particular defined so that they stable even if you
replace your PCI network card by a different one, hence in that case
absolutely are reused by a different device, and that's intentional.

Yeah must fit in IFNAMSIZ. And probably shouldn't include "/", control
chars, whitespace and some other weird chars that apps don't like. But
that's the same for all network interfaces, whether managed by udev
predictable naming or not...

>   2. How to handle the device associated with Accelerated Networking?
>      Do you want to hide or rename the VF that is associated with the
>      virtual device?

I have no idea what that means, what is Accelerated Networking?

> There are a couple of other quirks:
>   1. The current cloudinit and other startup applications require eth0 as
>      the administrative and always there interface, hard wired into the
>      code. How to handle that?

if you have multiple devices and want a specific one to be named eth0
then this is inhrently racy since we can't sensibly rename the device
like that in userspace because we'd always race against the kernel's
own naming regime.

Naming an interface "eth0" only really works if you have only one
interface or if you don't care about the names at all. If you have
multiple then pick different names outside of the ethX namespace the
kernel allocates from.

In the case where you only have a single interface or don't care about
the name then drop in a .link file that matches the interface
generically and sets NamePolicy=kernel so that the kernel name is used
as it is.

>   2. Hyper-V has the ability for host administrator to assign a name, but
>      it is more of a free form string so it is used as default
>      network description.

Current systemd git has support for assigning "alternative" ifnames to
devices, using that new kernel feature. On kernels that support that
we'll initialize the alternative ifnames to all names we could
possibly come up with (i.e. so that an interface always be be referred
to by its by-path, by-slot, by-mac name equally). Since the
alternative ifnames are not IFNAMSIZ long (but 128 chars long) maybe
they are suitable to use for these hyperv "free form string" if that
makes sense given the charset restrictions.

>   3. Azure has names as part of the CLI for manipulating VM's but these
>      are not currently exposed to guest. If this could happen would it help or
>      hurt.

I mean, we are happy to make use of any names that make sense. Not
sure why hyperv needs three different symbolic names for each
interface, but if it is how it is, then we can toally expose them all
;-).

Lennart

--
Lennart Poettering, Berlin