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

[Haiyang Zhang]

(resending after subscribed to systemd-devel)

> -----Original Message-----
> From: Lennart Poettering <lennart at poettering.net>
> Sent: Tuesday, January 7, 2020 9:01 AM
> To: Stephen Hemminger <stephen at networkplumber.org>
> Cc: systemd-devel at lists.freedesktop.org; Haiyang Zhang
> <haiyangz at microsoft.com>
> Subject: Re: [systemd-devel] Better network naming on Hyper-V/Azure?
> 
> 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?

On Azure, "Accelerated Networking" means SRIOV / VF NICs.

> 
> > 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
> ;-).

Hyper-V offers netvsc devices (synthetic NICs) in the same sequence across 
reboots, so eth0 ... ethN names will associate to the same vNIC every time 
with Sync-probing currently. 

But if in the future, we enable Async-probing, the naming may not persistent 
across reboots. In my patch set (not yet upstream), I added a new attribute 
(dev_num) in sysfs to keep track of the device channel offer sequence. So user 
mode program can have the option to use this attribute to name NICs, and  
generates the same results for Async-probing as Sync-probing does.

Thanks,
- Haiyang