Re: Better network naming on Hyper-V/Azure?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 10.01.20 15:37, Haiyang Zhang (haiyangz@xxxxxxxxxxxxx) 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.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel