Непредсказуемые сетевые имена.

Если ты прочитаешь документацию по реализации предсказуемых имён в systemd-udev, то увидишь, что один из критериев именования - номер устройства на шине PCI / PCI-E.

Ты изменил порядок устройств на шине - изменились имена устройств.

Как-то, так, всё очень предсказуемо, т.е. согласно документации.

Можешь вернуть eth* имена и прописать в udev правила с привязкой имён устройств к маку. Даже назначить те же имена, что были до изменения расположения устройств на шине PCI / PCI-E.

Товарищи, читайте документацию и будет вам счастье. )))

За подробностями вот: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

What precisely has changed in v197?
With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.

Как-то, так, всё очень предсказуемо, т.е. согласно документации.

В документации может быть написано что новое имя будет в виде случайного uuid и это к предсказуемости отношения не имеет.

Более того, даже если в голове просчитать как поменяются имена, согласно документации толку от этого ровно ноль, конфигурация ранее привязанная к именам сломается гарантированно. Хоть ты предскажешь имена, хоть нет, полезешь исправлять.

Единственный выход это заранее прибить имя к устройству, но тогда эта «предсказуемая» смена имён имеет ровно никакого смысла.

Вот эти вот имена назначаемые устройствам, должны быть не именами, а просто дополнительными метками, такими что ранее настроенная конфигурация не ломалась, но ты мог по этой метке узнать где конкретно сейчас вставлено устройство.

https://www.altlinux.org/NetworkDevicesName

Более того, даже если в голове просчитать как поменяются имена, согласно документации толку от этого ровно ноль, конфигурация ранее привязанная к именам сломается гарантированно. Хоть ты предскажешь имена, хоть нет, полезешь исправлять.

Единственный выход это заранее прибить имя к устройству, но тогда эта «предсказуемая» смена имён имеет ровно никакого смысла.

Я и не сказал, что это можно предсказать. Там же написано, что схема именования устройств приближена к нумерации устройств в BIOS (UEFI) и она тебе гарантирует, что от перезагрузки к перезагрузке имена сетевых устройств будут одинаковыми.

У меня была ситуация и не раз, когда на старой схеме именования устройств eth* менялись номера сетевых устройств при перезагрузке.

Они зависели от порядка инициализации (загрузки модуля, инициализации драйвером устройства) ядром Linux.

При чём, если не путаю это даже как-то происходило когда ни аппаратная часть не менялась, ни ядро не пересобиралось.

Это потом я уже в /etc/udev/rules.d/70-persistent-net.rules прописал правило для привязки к маку.

А так, если собрать ядро с другим набором драйверов и имена сетевых устройств в eth* схеме менялись, но это без наличия файла /etc/udev/rules.d/70-persistent-net.rules.

Потом, когда в udev Леннарт добавил такое поведение я в начале, конечно плевался, как и все и даже какое-то время использовал старую схему, её и сейчас можно включить.

Но в механике, предложенной леннартом, с привязкой к номерам устройств BIOS (UEFI) имя сетевого интерфейса не изменится в случае отсутствия модуля ядра или порядка загрузки модулей ядром.

Единственная проблема - изменение конфигурации оборудования, как у автора.

Так что везде есть свои нюансы, просто нужно учитывать.

Вот эти вот имена назначаемые устройствам, должны быть не именами, а просто дополнительными метками, такими что ранее настроенная конфигурация не ломалась, но ты мог по этой метке узнать где конкретно сейчас вставлено устройство.

Если ты посмотришь логи ядра Linux, то оно по прежнему так и инициализирует сетевые интерфейсы как eth*, а потом udev их переименовывает согласно предсказуемой схеме.

Чтобы быть жёстко уверенным - прописывай имена в /etc/udev/rules.d/70-persistent-net.rules.

но ты мог по этой метке узнать где конкретно сейчас вставлено устройство

Напиши об этом Леннарту, может реализует или реализуй сам.

Да, без перевода сложно разобраться, английский язык очень сложен.

Ты можешь через параметры ядра заставить Linux использовать старые имена типа eth0:

net.ifnames=0

Но они тебе не всрались, если ты не понимаешь зачем это может пригодиться.

А зачем может пригодиться? По мне, что так, что так доступ к сетевым интерфейсам одинаков.

Ну разве что циклом в скрипте перебирать удобнее.

А зачем может пригодиться?

При использовании Network Manager и тп - низачем. Это виртуалкопроблемы

В proxmox и так поголовно имена интерфейсов в ВМ всегда ens18.

Да и нет никаких проблем, что так, что так.

Какие у тебя проблемы с именами интерфейсов в ВМ?

Хотя скажу, что аппаратная конфигурация ВМ не часто меняется на кластерах виртуализаци, что админимтрирую.

С XEN и VMare ESXi тоже не помню каких-то проблем.

Аналогично просто с QEMU / KVM.

Так в чём проблема? С виртуалками что так, что так просто.

На OpenStack oVirt тоже вроде бы нет проблем.

На самих узлах Proxmox имена физических сетевых интерфейсов eno1, eno2 … enoN.

Ну а проверить имя сетевого интерфейса в случае изменения конфигурации сервера - дело исполнителя работ.

Но соглашусь, что в случае смены имени менять потом конфигурацию ВМ придётся для настройки мостов.

https://learn.microsoft.com/ru-ru/troubleshoot/azure/virtual-machines/linux/cannot-connect-debian-linux

как пример биопроблем любителей виртуального секса с линуксом

Это высосанная из пальца проблема. Понятно, что нужно проверить конфигурацию оборудования и мена интерфейсов. Просто нужно об этом знать.

Но имеет место быть, да.

Спасибо за уточнение!

С net.ifnames=0 тоже нужно учитывать, что при переносе VM, если сменился MAC адрес и существует файл /etc/udev/rules.d/70-persistent-net с определением привязки eth0 к старому мак адресу - в новой ВМ среде интерфейс будет eth1.