После обновления Proxmox VE 9 пропала сеть: как закрепить имена физических интерфейсов и не забыть про firewall

Самая частая авария после мажорного апгрейда гипервизора — не «развалился ZFS» и не «не стартуют виртуалки». Это молчащий сетевой порт: узел загрузился, ядро новое, ZFS в порядке, а vmbr0 пустой, потому что физический интерфейс теперь зовётся иначе. Ниже — почему имена NIC уезжают именно на переходе с Proxmox VE 8.4 на 9.x, что на самом деле делает штатный инструмент pve-network-interface-pinning, какие четыре конфига он правит, какой пятый не правит (и это стреляет не сразу, а через неделю), и как я готовлю такой апгрейд, чтобы не ехать ночью в ЦОД.

Откуда берётся имя enp94s0f0 и почему оно меняется

Имя вида enp94s0f0 нигде на диске не хранится — оно вычисляется заново при каждой загрузке. Этим занимается systemd-udevd: встроенный обработчик net_id смотрит, как устройство подключено к машине (PCI-домен, шина, слот, функция, номер порта на плате, USB-путь), и собирает из этого предсказуемое имя. Префикс en — Ethernet; дальше o<index> для распаянных на материнке портов, p<bus>s<slot> для карт в PCI-слотах, f<function> для многофункциональных адаптеров, x<MAC> — когда больше не за что зацепиться. Логика здравая: имя стабильно, пока железо стоит в том же слоте. Вся проблема в слове «пока».

Правила сборки имени версионируются — это и есть naming scheme. Новая версия systemd приносит новую схему, и Proxmox VE 9 приехал на Debian 13 «Trixie», а версия 9.2 (релиз 21 мая 2026) — ещё и на ядре 7.0 вместо ветки 6.x. Здесь вылезает вторая причина переименований, про которую забывают: дело не только в systemd. В официальном руководстве по апгрейду с 8 на 9 это записано прямым текстом — новое ядро распознаёт больше особенностей железа, например виртуальные функции, а имя интерфейса выводится из PCI(e)-адреса, поэтому часть сетевых карт может сменить имя, и сетевую конфигурацию придётся править.

Самый частый сценарий, который я вижу на практике, — десятигигабитные Intel X710/XXV710 (драйвер i40e) и карты Mellanox ConnectX. Драйвер в новом ядре начинает отдавать ядру phys_port_name, systemd честно дописывает к имени суффикс порта: было enp94s0f0 — стало enp94s0f0np0. Три символа. Для администратора — косметика, для ifupdown2 — совершенно другое устройство, которого в системе нет. Второй по частоте сценарий — сервер с включённым SR-IOV: ядро видит виртуальные функции, перестраивается нумерация, и «уезжает» уже не суффикс, а номер шины.

Ломается всё дальше по цепочке. Файл /etc/network/interfaces читается буквально: если в bridge-ports написано enp94s0f0, а такого интерфейса нет, мост поднимется пустым — без аплинка. Если это был bond, вы получите bond0 без слейвов. Диагностически это выглядит издевательски: ip -br link показывает vmbr0 и bond0 (у bond без слейвов обычно NO-CARRIER), ошибок в логе почти нет, ifupdown2 лишь вскользь ругается на отсутствующий порт, а трафика нет вообще. Узел при этом живой, диски крутятся, ВМ запущены — просто не видны никому, включая вас.

• /etc/network/interfaces — bridge-ports, bond-slaves, iface-секции физических портов
• /etc/pve/nodes/<node>/host.fw — правила брандмауэра узла с привязкой -i <iface>
• /etc/pve/firewall/cluster.fw — правила уровня датацентра (см. отдельный раздел ниже)
• /etc/pve/sdn/controllers.cfg и /etc/pve/sdn/fabrics.cfg — интерфейсы для EVPN/BGP и фабрик
• самописное: post-up/pre-up хуки, ethtool/tc в interfaces, keepalived, frr, шаблоны мониторинга

net.naming-scheme: почему я на него не полагаюсь

Первое, что советуют на форумах, — прибить версию схемы именования параметром ядра net.naming-scheme=<версия>, например net.naming-scheme=v252. Механизм рабочий: systemd-udevd будет собирать имена по правилам старой версии, даже если сам systemd обновился. На узле, который годами жил с eno1/eno2 и где переименование вызвано именно скачком версии systemd, это спасает.

Но продавать это как гарантию нельзя, и документация Proxmox тут честнее многих статей: даже с закреплённой версией схемы именования имена сетевых устройств всё равно могут измениться из-за обновлений ядра или драйвера. То есть ровно тот случай с i40e и phys_port_name, который встречается чаще всего, наш параметр не лечит. Имя изменилось не потому, что поменялись правила, а потому, что поменялись входные данные для этих правил.

Мой вывод простой: net.naming-scheme — это страховка от одного из двух источников проблемы, и как единственная мера она не годится. Я ставлю её только там, где нет возможности пройтись пиннингом по всем узлам прямо сейчас, и всегда воспринимаю как временную меру до окна обслуживания. Настоящее решение — .link-файлы, привязанные к MAC-адресу: они не зависят ни от версии схемы, ни от того, что придумал драйвер.

Если всё-таки ставите — помните, что в Proxmox два разных загрузчика и два разных места правки. На системах с ZFS/UEFI и proxmox-boot-tool это /etc/kernel/cmdline, на классическом GRUB — /etc/default/grub.

# systemd-boot / proxmox-boot-tool (типично для установки на ZFS)
proxmox-boot-tool status
sed -i '1 s/$/ net.naming-scheme=v252/' /etc/kernel/cmdline   # параметры должны остаться в одной строке
proxmox-boot-tool refresh

# классический GRUB
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="\(.*\)"/GRUB_CMDLINE_LINUX_DEFAULT="\1 net.naming-scheme=v252"/' /etc/default/grub
update-grub

# проверить после перезагрузки
cat /proc/cmdline

• `net.naming-scheme=v252` фиксирует правила systemd, но не входные данные от ядра и драйвера
• параметр действует на все интерфейсы узла сразу, точечно его не применить
• после правки cmdline — `proxmox-boot-tool refresh` или `update-grub`, иначе параметр не попадёт в загрузку
• контроль после ребута — `cat /proc/cmdline` и `ip -br link`
• параметр — временная мера до окна обслуживания, постоянное решение — .link-файлы по MAC

pve-network-interface-pinning: что он делает на самом деле

В Proxmox VE 9 появился штатный инструмент pve-network-interface-pinning. Он берёт все физические интерфейсы, у которых ещё нет своего .link-файла, и генерирует для каждого файл-описание в /usr/local/lib/systemd/network. Внутри — привязка к MAC-адресу и жёстко заданное имя. Имена по умолчанию идут с префиксом nic. В документации примеры с nic1/nic2, но в исходном коде инструмента счётчик начинается с нуля, и на живых стендах я вижу nic0 — не привязывайтесь к номеру глазами, всегда сверяйтесь с MAC внутри файла. Файлы называются по шаблону 50-pmx-<имя>.link.

Ключевое, за что я этот инструмент и полюбил: он не ограничивается генерацией .link-файлов, а идёт и заменяет старое имя интерфейса в конфигурации. Правятся четыре вещи — /etc/network/interfaces, файл брандмауэра узла /etc/pve/nodes/<nodename>/host.fw, а также /etc/pve/sdn/controllers.cfg и /etc/pve/sdn/fabrics.cfg. Раньше это была ручная работа с grep и риском забыть половину.

Работает он аккуратно: изменённые конфиги пишутся рядом с оригиналами с суффиксом .new, чтобы вы могли посмотреть глазами, что именно инструмент собрался поменять. Откат до перезагрузки тривиален — документация формулирует это буквально так: если вы видите проблемные изменения или хотите отменить сделанное инструментом до перезагрузки, просто удалите все .new-файлы и соответствующие link-файлы. Изменения пиннинга вступают в силу только после ребута узла — иначе и быть не может, имена присваиваются на этапе загрузки.

Если вам не нужен массовый прогон, есть точечный режим: --interface указывает конкретную карту, --target-name задаёт желаемое имя, --prefix меняет префикс для пакетной генерации. Я обычно предпочитаю осмысленные имена вместо nicN: uplink0, stor0, corosync0 — через полгода это экономит минуты на каждом инциденте.

# пакетно, все физические интерфейсы, префикс по умолчанию nic
pve-network-interface-pinning generate

# точечно, с явным именем
pve-network-interface-pinning generate --interface enp94s0f0np0 --target-name uplink0

# что сгенерировалось
ls -l /usr/local/lib/systemd/network/
cat /usr/local/lib/systemd/network/50-pmx-uplink0.link

# сравнить старый и новый interfaces бок о бок (так предлагает документация)
diff -y /etc/network/interfaces /etc/network/interfaces.new

Содержимое .link-файла предельно простое — привязка к MAC-адресу и жёсткое имя. Именно поэтому решение и устойчиво: MAC не зависит ни от версии схемы именования, ни от того, что нового драйвер рассказал ядру про порт.

[Match]
MACAddress=aa:bb:cc:dd:ee:ff
Type=ether

[Link]
Name=uplink0

• `pve-network-interface-pinning generate` — прогнать по всем физическим интерфейсам
• `pve-network-interface-pinning generate --prefix uplink` — свой префикс вместо nic
• `pve-network-interface-pinning generate --interface enp1s0 --target-name if42` — точечно, с явным именем
• `ls -l /usr/local/lib/systemd/network/` — посмотреть, что сгенерировалось
• `for f in $(find /etc/network /etc/pve -name '*.new'); do diff -u ${f%.new} $f; done` — просмотреть все подготовленные правки одним махом

Пятый файл, который инструмент не правит: cluster.fw

А теперь самое неприятное и самое ценное в этой статье. Инструмент правит host.fw, но конфигурацию брандмауэра уровня датацентра — /etc/pve/firewall/cluster.fw — он не обновляет автоматически. Это записано в документации отдельным предупреждением, и это ровно тот тип бага, который не проявляется в момент работ. Сеть после ребута поднялась, ВМ доступны, кластер собран, инженер закрывает задачу. А потом через несколько дней выясняется, что перестал ходить трафик, разрешённый правилом с привязкой к физическому интерфейсу: имя в правиле указывает на устройство, которого больше нет, правило просто не срабатывает.

Логика простая: имя интерфейса в правиле встречается в опции -i. Если у вас в cluster.fw есть строки вида IN ACCEPT -source 10.20.0.0/24 -i eno2 -p tcp -dport 8007, после пиннинга их надо переписать руками. Правило не выдаст ошибки, не подсветится красным, оно просто перестанет матчиться. Проверяйте не только cluster.fw, но и группы правил (security groups) и алиасы — они лежат в том же файле.

По моему опыту тем же грепом полезно пройтись ещё по нескольким местам, которых нет в списке инструмента: SDN-зоны и vnet'ы (в списке автоматически правимых только controllers.cfg и fabrics.cfg), собственные post-up/pre-up хуки в interfaces с ethtool и tc, конфиги frr и keepalived, если вы их держите вне SDN, а также шаблоны и элементы данных мониторинга — Zabbix и Prometheus node_exporter собирают метрики по имени интерфейса, и после переименования у вас тихо обнулятся графики по трафику.

И сразу успокою по поводу того, что трогать не нужно. Corosync ссылается на узлы по IP-адресам в ring0_addr/ring1_addr, а не по именам интерфейсов, — переименование ему безразлично. Ceph настраивается подсетями в public_network/cluster_network — тоже мимо. Виртуальные машины и контейнеры привязаны к мостам (bridge=vmbr0), а имена мостов инструмент не меняет вовсе — он работает только с физическими устройствами. Хранилища, ZFS-пулы, HA-группы не затрагиваются. Паниковать надо ровно в трёх местах: interfaces, брандмауэр, SDN.

• `grep -rnE '\b(en[ospx][0-9a-z.]*|eth[0-9]+|nic[0-9]+)\b' /etc/pve/firewall/ /etc/pve/sdn/ /etc/network/` — найти все упоминания имён
• `pve-firewall compile | less` — посмотреть итоговый набор правил, который реально собирается
• `pve-firewall status` — убедиться, что брандмауэр вообще включён и правила применились
• проверить security groups и IPSet внутри cluster.fw, а не только тело файла
• проверить элементы данных мониторинга по имени интерфейса

Разбор из практики: кластер агентства «Ключ и Метр», апгрейд 8.4 → 9.2

Агентство недвижимости «Ключ и Метр», 21 рабочее место: риелторы, юрист по сделкам, бухгалтерия, пара менеджеров по аренде. Серверная — шкаф в офисе. Небольшой кластер из трёх узлов Proxmox VE 8.4 на Dell R450: по два порта Intel X710 в bond0 (LACP, 2×10G) под весь продуктивный трафик и по два порта встроенной сетевой карты под corosync — ring0 и ring1 на отдельных 1G-линках, физически разведённых. 18 виртуальных машин, из них 7 — продуктив: 1С, терминальный сервер, база объектов и CRM, файловый сервер со сканами договоров и выписок ЕГРН. Апгрейд на 9.2 планировали давно, окно взяли ночное, все инструкции из wiki прошли, pve8to9 отработал без ошибок.

Первый узел встал нормально — на нём аплинком тестовой сети были встроенные гигабитные порты, имена не поменялись. Второй узел после ребута из кластера не выпал (спасибо разнесённому corosync — он жил на встроенных портах и продолжал работать), но 6 ВМ, среди них 1С и терминальный сервер, остались без сети. В консоли iDRAC картина классическая: bond0 без единого слейва, vmbr0 без портов. ip -br link показал enp94s0f0np0 и enp94s0f1np1 вместо ожидаемых enp94s0f0/enp94s0f1 — драйвер i40e в ядре 7.0 начал отдавать phys_port_name, systemd честно дописал суффиксы. В конфиге, разумеется, старые имена.

Первую помощь оказали руками прямо из консоли: правка bond-slaves в /etc/network/interfaces на новые имена, ifreload -a, сеть поднялась за 40 секунд. Общий простой сегмента — 34 минуты, из них 26 ушло на «а что вообще случилось» и логин в iDRAC, потому что пароль от него лежал в другом хранилище. После этого третий узел уже обновляли по-человечески: сначала ребут, потом консоль, потом сеть. На третьем, кстати, имена не менялись вообще — карта другой ревизии. Тот самый случай, когда в одном кластере после апгрейда часть узлов с новыми именами, часть со старыми; ровно про это на форуме Proxmox есть тред про непоследовательный нейминг после перехода с 8.4 на 9.2, и штатный ответ разработчиков — прогнать pve-network-interface-pinning generate на отставшем узле.

Через неделю в следующее окно прогнали пиннинг на всех трёх узлах: uplink0/uplink1 для X710, corosync0/corosync1 для встроенных портов. Проверили .new-файлы диффом, перезагрузили по одному с ожиданием восстановления HA. И вот тут выстрелила мина: в cluster.fw жило правило IN ACCEPT -source 10.20.30.0/24 -i eno2 -p tcp -dport 8007, разрешавшее доступ к Proxmox Backup Server с сегмента резервного копирования. eno2 стал corosync0, правило умерло молча, бэкапы всех 18 ВМ начали падать по таймауту. Заметили на четвёртые сутки — по алерту «задание бэкапа не выполнялось N часов», а не по самому файрволу. Для агентства, где в 1С и на файловом сервере лежат подписанные договоры и задатки по текущим сделкам, это было самое неприятное. Итог: 34 минуты простоя 1С и терминалов в рабочее утро и четверо суток без свежих резервных копий — и ровно ноль из этого было бы, если бы пиннинг и правка cluster.fw делались до, а не после первого ребута.

• причина аварии: драйвер i40e в новом ядре добавил к именам портов суффиксы np0/np1
• время простоя: 34 минуты, из них 26 — поиск причины и пароля от iDRAC
• тихий отказ: правило `-i eno2` в cluster.fw пережило пиннинг и молча перестало срабатывать
• последствие: четверо суток без свежих резервных копий 18 ВМ
• что изменили: слепок NIC до апгрейда, пиннинг и ревизия cluster.fw в одном окне, пароли консоли — в общем сейфе

Мой порядок действий при апгрейде PVE 8 → 9

Порядок, который я применяю на клиентских кластерах, устроен так, чтобы переименование стало ожидаемым событием, а не сюрпризом. Главная идея: снять слепок железа ДО апгрейда, чтобы потом сопоставлять карты по MAC-адресу и PCI-адресу, а не гадать. Пять минут работы избавляют от получаса в консоли ночью.

Дальше — принципиальный момент по последовательности. Есть два подхода, и единого мнения тут нет. Первый: обновиться, посмотреть, что получилось, и уже потом пинить. Второй: сделать пиннинг на PVE 8 заранее, чтобы имена были прибиты к MAC ещё до смены ядра. Второй красивее, но на восьмёрке инструмент есть не везде — всё зависит от версии пакетов на узле. Если command -v pve-network-interface-pinning ничего не вернул, придётся раскладывать .link-файлы руками в /etc/systemd/network по образцу из документации (формат <номер>-<имя>.link, номер меньше 99). Я на боевых кластерах делаю так: заранее руками пиню только аплинки продуктивных мостов и corosync (это две-три карты, десять минут), а полный прогон инструментом делаю уже на девятке в следующее окно. Компромисс, зато первый ребут после апгрейда проходит предсказуемо.

Ещё одна тонкость про приоритеты. systemd ищет .link-файлы в нескольких каталогах, и /etc/systemd/network имеет приоритет выше, чем /usr/local/lib/systemd/network, куда пишет инструмент Proxmox. Если вы когда-то раскладывали свои .link-файлы руками, а потом прогнали генератор — победят ваши старые файлы, а конфиги будут переписаны под новые имена. Получится ровно та авария, которую вы пытались предотвратить. Поэтому перед прогоном инструмента я всегда смотрю, что лежит в /etc/systemd/network.

После ручного создания или правки .link-файлов документация Proxmox требует обновить initramfs — часть переименований отрабатывает ещё на раннем этапе загрузки. Сам pve-network-interface-pinning update-initramfs не вызывает и по документации требует только перезагрузку, но если на узле есть и ручные .link-файлы, я делаю update-initramfs -u -k all в любом случае — это минута и минус один источник непредсказуемости.

# ДО апгрейда: слепок железа, сохранить вне сервера
ip -o link | awk '{print $2, $(NF-2)}' > /root/nic-map-before.txt
lspci -nnk | grep -A3 -i ethernet >> /root/nic-map-before.txt

# ПЕРЕД прогоном инструмента: убедиться, что нет своих .link с более высоким приоритетом
ls -l /etc/systemd/network/

# ПОСЛЕ генерации: просмотреть все подготовленные правки
find /etc/network /etc/pve -name '*.new' -exec sh -c 'diff -u "${0%.new}" "$0"' {} \;

# отдельно — то, что инструмент НЕ правит
grep -nE ' -i (en|eth|nic)' /etc/pve/firewall/cluster.fw

update-initramfs -u -k all
reboot

• Снять слепок ДО: `ip -o link | awk '{print $2, $(NF-2)}'` и `lspci -nnk | grep -A3 -i ethernet` — сохранить вне сервера
• Проверить доступ к IPMI/iDRAC/iLO и пароль от него — прямо сейчас, а не в момент аварии
• Убедиться, что corosync живёт на отдельных портах от продуктивного bond
• Обновить один узел, дождаться полного восстановления HA, только потом следующий
• После ребута: `ip -br link`, сверить с довыгрузкой; при расхождении — `pve-network-interface-pinning generate`
• Просмотреть все .new-файлы диффом, отдельно вручную проверить /etc/pve/firewall/cluster.fw
• `update-initramfs -u -k all`, затем перезагрузка узла
• После ребута: `pve-firewall compile`, проверка бэкапов и графиков мониторинга

Если сеть уже отвалилась: восстановление с консоли

Ситуация: узел после ребута не отвечает. Заходим через IPMI/iKVM, логинимся под root. Первым делом — не паниковать и не переустанавливать. Смотрим, какие интерфейсы реально видит ядро: ip -br link show. Вы почти наверняка увидите один-два физических порта с незнакомыми именами в состоянии DOWN и пустой мост. Дальше нужно понять, какой из них какой, — и здесь единственный надёжный ключ это MAC-адрес: ip -o link | awk '{print $2, $(NF-2)}' даст пары «имя — MAC», а в вашем слепке до апгрейда (или в записях коммутатора, или в iDRAC на вкладке сетевых устройств) есть соответствие MAC и физического порта.

Если нужно понять, откуда именно взялось новое имя и не будет ли оно ещё раз меняться, помогает udevadm test-builtin net_id /sys/class/net/<имя> — команда покажет все варианты имён, которые udev вычислил для устройства, включая ID_NET_NAME_ONBOARD, ID_NET_NAME_PATH и ID_NET_NAME_MAC. Полезно ровно тем, что видно, по какому именно правилу собралось текущее имя. И проверьте ip link show <имя> на наличие altname: современный systemd-udevd вешает старые имена как альтернативные, и иногда конфиг с прежним именем внезапно начинает работать именно из-за этого. Обольщаться не стоит — altname назначается политикой udev и к инструменту пиннинга отношения не имеет, полагаться на него как на решение нельзя.

Восстановление в две минуты: правим /etc/network/interfaces, подставляя новые имена в bridge-ports и bond-slaves, и делаем ifreload -a. Не reboot, не systemctl restart networking — именно ifreload, он в PVE штатный и применяет конфигурацию без разрыва того, что уже работает. Связь появится сразу. После этого узел доступен по SSH, и дальше уже спокойно, из тёплого кресла, делаем правильно: прогоняем pve-network-interface-pinning, проверяем cluster.fw, обновляем initramfs и планируем ещё один ребут в окно.

# 1. что реально видит ядро
ip -br link show

# 2. сопоставить по MAC со слепком до апгрейда
ip -o link | awk '{print $2, $(NF-2)}'

# 3. откуда взялось имя (все варианты, которые вычислил udev)
udevadm test-builtin net_id /sys/class/net/enp94s0f0np0

# 4. правим bridge-ports / bond-slaves и применяем БЕЗ перезагрузки
nano /etc/network/interfaces
ifreload -a

# 5. контроль
ip -br addr show
pvecm status

Отдельно про кластер. Если узел потерял связь надолго и HA его отфенсил, не спешите поднимать сервисы руками — дайте кластеру собраться, проверьте pvecm status и ha-manager status, убедитесь в кворуме. И проверьте /etc/pve на запись: при потере кворума файловая система pmxcfs уходит в read-only, и вы просто не сможете сохранить правки конфигов брандмауэра, пока кворум не восстановится. Это, кстати, ещё один аргумент в пользу отдельных линков под corosync.

• войти через IPMI/iDRAC/iLO и посмотреть реальные имена: `ip -br link show`
• сопоставить порты по MAC со слепком до апгрейда или с таблицей MAC коммутатора
• подставить новые имена в bridge-ports и bond-slaves в /etc/network/interfaces и выполнить `ifreload -a`
• проверить кворум и HA: `pvecm status`, `ha-manager status`
• уже по SSH: пиннинг, ревизия cluster.fw, плановый ребут в окно

Частые вопросы