Короткий ответ

Management Proxmox почти всегда сидит на vmbr0. Любой ifdown vmbr0 по SSH — лотерея. Правьте /etc/network/interfaces с IPMI/консоли, применяйте ifupdown2 так, чтобы адрес pve1 (10.0.10.11) не исчезал на середине. Не переносите шлюз на slave-порт bond, не оставляйте IP на eno1 и на vmbr0 одновременно.

Гостевые tap держатся за bridge: сломанный vmbr0 валит и SSH, и VM.

Симптомы и как отличить

Типичная картина:

  • после «Apply» в GUI узел недоступен, VM на этом узле без сети;
  • ip -br a: vmbr0 DOWN или без IP;
  • дубли шлюза, трафик management ушёл не туда;
  • corosync на том же мосту — узел «выпал».

Отличия:

Что видноКуда
Хост доступен, одна VM нетСеть VM
VLAN tagVLAN
GUI 8006 нет, SSH естьВеб-интерфейс
Узел offline в кластереУзел выпал

Возможные причины

  1. IP повесили на физический порт вместо bridge.
  2. Slave eno1 не в vmbr0, мост пустой.
  3. Bond без bond-mode, оба линка без LACP на коммутаторе.
  4. Шлюз не на management VLAN.
  5. ifupdown2 reload оборвал SSH до применения новой маски.
  6. Второй vmbr перехватил default route.

Диагностика

С консоли BMC, не с единственного SSH:

pveversion
ip -br addr
ip route
cat /etc/network/interfaces
bridge link
systemctl status networking --no-pager

Сверьте: address 10.0.10.11 на vmbr0, bridge-ports указывает на реальный NIC или bond0, gateway в той же L3-сети.

grep -E 'vmbr|bond|gateway|address' /etc/network/interfaces
ss -lntp | grep 22

Решение

Сценарий A. IP на eno1, мост без адреса

Канон PVE: физический порт без IP, IP на vmbr0, порт в bridge-ports. Правьте файл, применяйте с консоли:

ifreload -a
ip -br addr
ip route

Проверьте SSH с другой машины до закрытия KVM.

Сценарий B. Bond

На коммутаторе LACP должен совпадать с bond-mode 802.3ad (или active-backup, если LACP нет). Не смешивайте. vmbr0 как bridge-ports bond0. IP не на членах bond.

Сценарий C. Потеряли шлюз

Верните gateway в stanza vmbr0. Два default route — уберите лишний. Management DNS в /etc/resolv.conf не заменяет маршрут.

Сценарий D. Нужно сменить IP узла в кластере

Это не «поменять address и всё». Есть процедура смены IP PVE в кластере (corosync). Не делайте только в interfaces. См. также узел выпал.

Сценарий E. Откат

Верните сохранённый interfaces, ifreload -a. Если файл уже испорчен — с ISO chroot/редактируйте с live, если узел не грузит сеть.

ifupdown2, OVS и порядок stanza

PVE 8 штатно с ifupdown2. Синтаксис source-directory /etc/network/interfaces.d плюс основной файл. Правка только GUI может переписать ручные комментарии. Перед Apply копируйте файл:

cp -a /etc/network/interfaces /root/interfaces.$(date +%F-%H%M)
python3 -c 'print("backup ok")'
ifquery vmbr0
ifquery eno1

ifquery показывает, как ifupdown2 понимает stanza. Ошибка «bridge vmbr0 doesn't exist» после reboot — auto vmbr0 забыли, или bridge-ports указывает на имя, которого нет (enp3s0 vs eno1 после смены ядра/именования).

Не ставьте gateway и на vmbr0, и на vmbr0.20. Один default. Policy routing для corosync — только если вы его сознательно строили.

Смешение OVS (ovs_type) и linux vmbr на одном порту без схемы заканчивается потерей management. Если в файле уже ovs — не копируйте в него linux-примеры из этой статьи один в один; чините в той модели, которая стоит.

После успешного ifreload проверьте не только ping шлюза, но и pvecm status: corosync мог сидеть на втором IP, который вы сняли.

Как проверить, что проблема устранена

С рабочей станции: SSH 10.0.10.11, GUI :8006. На узле:

ip -br addr show vmbr0
bridge link
pvecm status
qm status 101

vmbr0 UP с адресом. Гость на vmbr0 пингует шлюз. Кластер видит pve1. После ребута узла (окно) сеть поднимается без ручного ifup. Маршрут один default.

Именование NIC после обновления ядра (eno1 → enp1s0) ломает bridge-ports. Перед reboot из-за ядра сверьте ip link и файл interfaces. Если предстоит обновление, заложите BMC и копию interfaces в том же окне, не «сеть потом».

Если не помогло

  • LACP flapping: пауза на коммутаторе, неверный hash.
  • VLAN-aware bridge сломан после правки bridge-vids — VLAN.
  • Open vSwitch смешан с linux bridge без плана.
  • NetworkManager/чужой скрипт переписывает interfaces — уберите конфликт.
  • После правки нет corosync: отдельный ring на другом NIC — его тоже проверьте.

Профилактика

  • Любая смена vmbr0 — только с BMC и копией файла.
  • Management VLAN отдельно от VM, если политика позволяет.
  • Не тестировать LACP в рабочий час на единственном линке.
  • Мониторинг IP pve1 и pvecm.
  • ifupdown2 из дистрибутива PVE, не «настройка как на Ubuntu Desktop».

FAQ

ifreload -a vs ребут?

ifreload применяет diff. Ребут — полный подъём. После рискованной смены bond планируйте ребут в окно, не надейтесь только на reload.

Можно ли держать management на vmbr0 вместе с VM?

Да, так часто и есть. Тогда ошибка в мосте бьёт по всему. Отдельный NIC на management снижает риск.

Нужен ли bridge-stp off?

На PVE по умолчанию STP обычно off. Не включайте STP, не согласовав с коммутатором.

GUI Network Apply vs правка файла?

GUI пишет тот же interfaces. На сломанном SSH GUI не спасёт — консоль.

Почему VM живы, а SSH на хост нет?

IP хоста сняли с моста, tap гостей ещё в bridge. Гости в L2 могут общаться, management — нет.

Можно ли повесить IP хоста на bond, а vmbr0 оставить без адреса?

На PVE management обычно на bridge, а bond — только bridge-ports. IP на bond мимо моста ломает модель и tap гостей. Исключение — отдельный NIC только под corosync без VM. Не копируйте «как на Ubuntu без hypervisor».