[systemd-devel] Better network naming on Hyper-V/Azure?
Haiyang Zhang
haiyangz at microsoft.com
Fri Jan 10 16:17:01 UTC 2020
> -----Original Message-----
> From: Lennart Poettering <lennart at poettering.net>
> Sent: Friday, January 10, 2020 10:55 AM
> To: Haiyang Zhang <haiyangz at microsoft.com>
> Cc: Stephen Hemminger <stephen at networkplumber.org>; systemd-
> devel at lists.freedesktop.org; Michael Kelley <mikelley at microsoft.com>
> Subject: Re: [systemd-devel] Better network naming on Hyper-V/Azure?
>
> On Fr, 10.01.20 15:37, Haiyang Zhang (haiyangz at microsoft.com) wrote:
>
> > > 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.
> >
> > Lennart and other systemd developers:
> >
> > Could you also comment on my proposal above? It's to keep the naming
> results
> > of Async-probing same as that of sync-probing.
>
> I am not sure I follow fully, but if you intend to assign an index to
> each interface that the VM supervisor sets and that we should use to
> name the interface, then that sounds great to me.
>
> However do note that we generally avoid stepping into the naming
> namespace of the kernel. i.e. if your intention to stabilize eth0,
> eth1, eth2 with that, we can't help you, that's generally racy since
> the kernel allocates other interfaces from that namespace too.
>
> My guess is that this is a lot like SR-IOV slot number that we can
> already use to name interfaces, right? If so, supporting things the
> same way sounds totally OK.
Thanks for your explanation. We do want to use the ethN format, and want the
results to be the same between Async and sync probing.
@Stephen Hemminger Since systemd needs to avoid stepping into the kernel
ethN formatting, should we do the synthetic NIC naming inside kernel (netvsc
driver)?
In case of conflicting with other names, like DDA, or VF NICs, it will fall back to
the first available ethN name. I know It's racy, but not worse than current
situation -- even with sync-probing, the name may still be racing with DDA, or
VF NICs. And this is already solvable by systemd which uses PCI slot naming, and
puts them into different naming formats.
Thanks,
- Haiyang
More information about the systemd-devel
mailing list