Custom network interface names

[dann1]

It is possible to establish user defined names overriding the naming scheme that the operating system might establish.

Those names can be established, for example, with systemd link files or udev rules

[root@rhel9-1013 ~]# cat /etc/systemd/network/10-paco67.link
[Match]
Path=pci-0000:00:04.0

[Link]
Name=paco67

[root@rhel9-1013 ~]# cat /etc/systemd/network/10-paco68.link
[Match]
MACAddress=02:00:d8:27:21:85

[Link]
Name=paco68

[root@rhel9-1013 ~]# cat /etc/udev/rules.d/70-paco.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="02:00:d8:27:21:87", NAME="paco69"
#5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
#    link/ether 02:00:d8:27:21:87 brd ff:ff:ff:ff:ff:ff
#    altname enp0s9
#    altname ens9

[root@rhel9-1013 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:00:ac:14:00:03 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet 172.20.0.3/16 brd 172.20.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::acff:fe14:3/64 scope link
       valid_lft forever preferred_lft forever
4: paco68: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:00:d8:27:21:85 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    altname ens5
5: paco69: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:00:d8:27:21:87 brd ff:ff:ff:ff:ff:ff
    altname enp0s9
    altname ens9
[root@rhel9-1013 ~]# dpdk-devbind.py --status-dev net

Network devices using DPDK-compatible driver
============================================
0000:00:04.0 'Virtio network device 1000' drv=vfio-pci unused=

Network devices using kernel driver
===================================
0000:00:03.0 'Virtio network device 1000' if=eth0 drv=virtio-pci unused=vfio-pci *Active*
0000:00:05.0 'Virtio network device 1000' if=paco68 drv=virtio-pci unused=vfio-pci
0000:00:09.0 'Virtio network device 1000' if=paco69 drv=virtio-pci unused=vfio-pci

Normally this isn't a good idea, but for usability purposes, the administrators might require custom names for given network interfaces. The idea is to allow one-deploy to rename interfaces on a given host.

In the case of interfaces used for SRIOV, the name given to the physical interface will be used as the prefix for the names of each of the virtual function NICs. Such that when the virtual function interfaces are created, they also receive the custom name.

When the interface is vfio-bound this name will be "lost". Some sort of association to this name should be done as well such that the OpenNebula monitoring system is able to detect it. With one-deploy, mapping the interfaces names established on the inventory file on a configuration file in a per-host basis, could very well bet this association. See OpenNebula/one#7509 for vfio interface names monitoring.

[sk4zuzu]

@dann1 I'd rather do that in udev as not everybody will use networkd to manage networking. 🤔

[dann1]

Hi @sk4zuzu, this is just a reference, the goal is to provide the feature, and the implementation (and inventory interface) would be whatever is a better solution.

We also need to match the vfio bound interfaces fake naming according to OpenNebula/one#7509 since. It's not quite clear yet as far as implementation goes, how to establish the ability to remember the interface name.

[sk4zuzu]

@dann1 The more I look at it, the more I think SR-IOV stuff should be handled by networking drivers and monitoring itself. That's because I had to actually repeat (and improve) implementation of PCI device discovery in 49ddadf and it is quite complex jinja code (which is not great). What we are going towards is this situation where OpenNebula may be no longer usable without one-deploy, which has never been the goal of this project. 🤔

[dann1]

I think in this case, for sriov we would just need udev rules with names for each of the vf interfaces after one-deploy enables them.
The monitoring will be handled by the hypervisor monitoring driver pci.rb probe but the logic of how to look for the name after vfio-binding has been done should be done according to how one-deploy establishes this sort of remembrance.

[sk4zuzu]

Sure, I'm just saying, that IMHO the whole PCI passtrough / SR-IOV code should not be done in one-deploy. I guess we will continue this particular approach, then we'll see what happens, won't we? 🤗