Замена сетевой карты в Proxmox VE: настройка интерфейсов
- Почему новая карта — это не просто «воткнул и забыл»
- Аудит перед заменой: что записать, пока всё работает
- Физическая замена и поиск нового интерфейса
- Настройка /etc/network/interfaces: от простого моста до bond + VLAN
- Пиннинг имён: чтобы имя больше не менялось
- Тестирование: как убедиться, что всё живо
- Миграция мостов в кластере: что делать с Corosync и Ceph
- Безопасность сетевых интерфейсов: promisc mode и фильтрация
- Оптимизация для виртуальных машин: VirtIO и multiqueue
- Если всё пошло не так: аварийное восстановление
- Open vSwitch: когда Linux Bridge уже мало
- Чек-лист замены NIC: распечатайте и повесьте в серверной
- Что запомнить
Тикет в мониторинге: «Сетевая нестабильна, пакеты теряются». Вы меняете карту, вставляете новую Intel X710, включаете сервер — и Proxmox не видит сеть. GUI недоступен, SSH молчит, а двадцать виртуалок за этим хостом обслуживают продакшн. Знакомая ситуация? Вся соль в том, что Proxmox при замене сетевой карты может назначить новому интерфейсу другое имя — и конфиг /etc/network/interfaces превращается в тыкву.
Замена NIC в Proxmox VE — рутинная операция при апгрейде серверов, которая требует осторожной настройки для сохранения сетевой связности хоста и виртуальных машин. Одна пропущенная строчка в конфиге — и весь хост с VM становится невидимым для сети. Давайте разберёмся, как делать такие замены спокойно и без downtime на полчаса.
Почему новая карта — это не просто «воткнул и забыл»
Proxmox VE построен на Linux Bridge (те самые vmbr0, vmbr1...). Мост работает как виртуальный коммутатор: физический интерфейс подключается к нему как slave-порт без собственного IP-адреса. Весь адрес, шлюз, маршруты — всё висит на vmbr. Виртуальные машины цепляются к мосту и получают трафик напрямую с физического порта. Для 90% сценариев это даёт минимальные задержки — мост добавляет меньше 10 микросекунд латентности.
Проблема возникает, когда Вы меняете NIC. Linux использует схему Predictable Network Interface Names: имя интерфейса формируется из PCI-адреса, слота, порта. Была карта в слоте PCIe x8 — интерфейс назывался enp3s0. Переставили карту в другой слот или поставили другую модель — получили ens4f0 или enp5s0f0np0. А в /etc/network/interfaces по-прежнему прописан enp3s0 как bridge-ports для vmbr0. Мост не поднимается, сеть мертва, и Вы сидите перед IPMI-консолью, вспоминая vim.
Аудит перед заменой: что записать, пока всё работает
Прежде чем выключать сервер и доставать отвёртку, снимите слепок текущей конфигурации. Три команды, которые сохранят Вам час нервной отладки:
# Текущее состояние интерфейсов — имена, MAC-адреса, IP
ip a > /root/backup_ip_a.txt
# Конфиг сети — это главный файл, который придётся править
cp /etc/network/interfaces /root/interfaces.backup
# PCI-устройства — пригодится для сверки после замены
lspci | grep -i net > /root/backup_lspci.txt
Отдельно зафиксируйте MAC-адрес старой карты — он понадобится, если Вы используете DHCP-резервации или фильтрацию по MAC на коммутаторе.
Теперь про выбор новой карты. Для сервера виртуализации разница между Intel и Realtek — не маркетинг, а инженерная реальность. Если вы только подбираете конфигурацию, стоит сначала разобраться, сколько железа нужно для Proxmox-виртуализации в целом.
| Параметр | Intel (i350, X710, E810) | Realtek (RTL8111, RTL8125) |
|---|---|---|
| CPU offload (TSO, LRO, RSS) | Аппаратный, на чипе NIC | Частично программный, нагружает CPU |
| Нагрузка на CPU при 1 Gbps | 5–8% одного ядра | 15–30% одного ядра |
| Стабильность драйверов в Linux | Эталонная, mainline kernel | Бывают проблемы, особенно в FreeBSD-based системах |
| SR-IOV (проброс в VM) | Полная поддержка (X710, E810) | Отсутствует |
| Цена (б/у, 1GbE dual-port) | 1500–2500 на вторичке | 500–1000, часто встроена в материнку |
Intel-карты разгружают процессор за счёт аппаратного TCP Segmentation Offload и Receive Side Scaling. Для гипервизора, где каждый процент CPU на счету, это не мелочь. Realtek на домашнем NAS — допустимо. Realtek на Proxmox-кластере с Ceph — рецепт для проблем под нагрузкой.
Физическая замена и поиск нового интерфейса
Сервер выключен, карта заменена, питание подано. Подключаемся через IPMI/iKVM/iLO — что есть под рукой. SSH пока недоступен, потому что мост не поднялся (мы же ещё не правили конфиг). Входим через консоль и ищем новый интерфейс:
# Какие сетевые устройства видит ядро прямо сейчас
ip link show
# Детали по PCI — модель, чипсет, слот
lspci | grep -i ethernet
# Если карта только что инициализировалась, полезно глянуть dmesg
dmesg | grep -i eth
Допустим, старый интерфейс назывался enp3s0, а новый получил имя enp5s0f0. Теперь нужно обновить /etc/network/interfaces — заменить старое имя на новое во всех строках, где оно фигурирует.
Настройка /etc/network/interfaces: от простого моста до bond + VLAN
Вот типичный конфиг после чистой установки Proxmox — один мост, одна карта:
auto lo
iface lo inet loopback
iface enp3s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
После замены карты на новую (интерфейс стал enp5s0f0) правим ровно две строки:
iface enp5s0f0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
bridge-ports enp5s0f0
bridge-stp off
bridge-fd 0
Применяем без перезагрузки:
Команда ifreload -a перечитывает конфигурацию и пересоздаёт интерфейсы. Это штатный инструмент Proxmox — он корректно пересобирает мосты и бонды. Если всё сделано правильно, через пару секунд вернётся SSH и веб-интерфейс.
auto enp5s0f0
iface enp5s0f0 inet manual
auto enp5s0f1
iface enp5s0f1 inet manual
auto bond0
iface bond0 inet manual
bond-slaves enp5s0f0 enp5s0f1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer3+4
auto vmbr0
iface vmbr0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
Для VLAN-тегирования — добавьте vlan-aware мост, и VM смогут получать трафик с нужным тегом через настройку в GUI Proxmox:
auto vmbr0
iface vmbr0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
Если нужен Jumbo Frame для Ceph-трафика, добавьте MTU через post-up:
auto enp5s0f0
iface enp5s0f0 inet manual
mtu 9000
auto vmbr1
iface vmbr1 inet static
address 10.10.0.5/24
bridge-ports enp5s0f0
bridge-stp off
bridge-fd 0
mtu 9000
Пиннинг имён: чтобы имя больше не менялось
Proxmox (начиная с версии 8+) предлагает утилиту pve-network-interface-pinning, которая генерирует .link-файлы для systemd и привязывает конкретное имя к MAC-адресу. Это страховка от повторного переименования при обновлении ядра:
# Генерация для всех физических интерфейсов
pve-network-interface-pinning generate
# Привязка конкретного интерфейса к выбранному имени
pve-network-interface-pinning generate --interface enp5s0f0 --target-name nic1
Файлы попадают в /usr/local/lib/systemd/network/. После генерации нужна перезагрузка — ifreload тут не поможет, потому что переименование происходит на уровне udev при старте системы.
Альтернативный способ — создать .link-файл вручную:
# /etc/systemd/network/10-mgmt.link
[Match]
MACAddress=aa:bb:cc:dd:ee:ff
[Link]
Name=mgmt0
Выбирайте понятные имена: mgmt0 для управления, stor0 для storage-сети, ceph0 для кластерного трафика. Через полгода Вы скажете себе спасибо.
Тестирование: как убедиться, что всё живо
Сеть поднялась, SSH работает, GUI открывается. Но расслабляться рано — нужно проверить, что виртуальные машины тоже видят сеть и производительность в норме.
Базовая проверка связности:
# Со стороны хоста
ping -c 5
ping -c 5
# Статус моста — показывает, какие порты подключены
bridge link show
# Убедиться, что карта работает на правильной скорости
ethtool enp5s0f0 | grep Speed
Проверка изнутри VM — зайдите в консоль любой виртуалки и убедитесь, что связность есть. Если VM использует VirtIO-сетевой адаптер, проблем обычно не бывает — мост прозрачно пробрасывает кадры.
Для диагностики на уровне пакетов — tcpdump покажет, ходит ли трафик через новый интерфейс:
# Слушаем трафик на физическом интерфейсе — ARP, ICMP
tcpdump -i enp5s0f0 -c 20 -nn
# Фильтруем по конкретному IP виртуалки
tcpdump -i vmbr0 host 10.0.0.100 -c 10
Если пакеты на физическом интерфейсе есть, а на мосту — нет, проблема в конфигурации bridge-ports. Если пакеты есть на мосту, но VM не отвечает — проверяйте настройки внутри гостевой ОС.
Для нагрузочного тестирования — iperf3 между хостом и другой машиной в сети:
# На удалённой машине (сервер)
iperf3 -s
# На Proxmox-хосте (клиент)
iperf3 -c
Если результат заметно ниже пропускной способности канала — проверяйте negotiation (ethtool), offload-настройки (ethtool -k), кабель (да, бывает).
Логи сетевой подсистемы:
Здесь будут видны ошибки применения конфигурации, проблемы с bond-агрегацией, таймауты LACP.
Миграция мостов в кластере: что делать с Corosync и Ceph
Если Proxmox-хост входит в кластер, замена NIC затрагивает не только локальную сеть. Corosync использует отдельный канал связи между узлами — обычно выделенный интерфейс или VLAN. Если этот интерфейс сменил имя, кластер потеряет кворум.
Проверьте конфигурацию Corosync до замены:
Там будет указан IP-адрес узла (bindnetaddr или ringaddr). Если IP не менялся — Corosync переподключится автоматически, как только мост с этим адресом поднимется. Если менялся — правьте corosync.conf через pvecm или напрямую (с пониманием, что правка идёт на pmxcfs, распределённой файловой системе кластера).
Для Ceph-сети ситуация аналогична. Ceph OSD и MON привязаны к IP-адресам, не к именам интерфейсов. Пока vmbr с нужным адресом поднимается — Ceph переподключится. Если Вы меняете карту, через которую ходит Ceph-трафик, запланируйте maintenance window: выставьте noout флаг на кластере, чтобы OSD не начали ребалансировку за время простоя:
ceph osd set noout
# ... замена карты, правка конфига, ifreload ...
ceph osd unset noout
Без этого флага Ceph через 10 минут (дефолтный mon_osd_down_out_interval) решит, что OSD мертвы, и начнёт перемещать данные. На кластере с терабайтами — это часы лишней нагрузки.
Безопасность сетевых интерфейсов: promisc mode и фильтрация
При замене NIC стоит пересмотреть и настройки безопасности. Linux Bridge по умолчанию переводит физический интерфейс в promiscuous mode — мост должен видеть кадры с MAC-адресами всех VM. Это нормальное поведение для гипервизора, но если Ваш коммутатор логирует promisc-события — будьте готовы к алертам от сетевиков.
Если на хосте живут недоверенные VM (мультитенантная среда, хостинг), включите MAC-фильтрацию на мосту:
# Запрет VM подменять MAC-адрес
bridge link set dev tap100i0 learning off
echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping
Для ebtables-правил, ограничивающих трафик между VM на одном мосту, помните: после ifreload -a правила ebtables сбрасываются. Сохраняйте их в post-up скрипте:
auto vmbr0
iface vmbr0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
bridge-ports enp5s0f0
bridge-stp off
bridge-fd 0
post-up /usr/local/bin/apply-ebtables.sh
Proxmox Firewall (pve-firewall) работает поверх nftables и не зависит от имени физического интерфейса — он привязан к мостам и VM. После замены NIC правила файервола применятся автоматически, если мост поднялся с тем же именем.
Оптимизация для виртуальных машин: VirtIO и multiqueue
Новая карта стоит, мост работает — пора выжать из неё производительность. На стороне VM убедитесь, что сетевой адаптер использует VirtIO (а не эмулированный e1000 или rtl8139). VirtIO-net работает через vhost-net — ядерный модуль, который обрабатывает пакеты без участия QEMU-процесса. Разница в пропускной способности между e1000 и VirtIO на 10GbE-карте — двукратная и выше.
Для VM с интенсивным сетевым трафиком включите multiqueue:
# В конфигурации VM (/etc/pve/qemu-server/
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,queues=4
Количество очередей (queues) должно совпадать с числом vCPU, выделенных VM (но не превышать 16). Внутри гостевой ОС проверьте, что ethtool видит несколько очередей:
На стороне хоста — если NIC поддерживает RSS (а Intel X710/E810 поддерживают), убедитесь, что количество Rx-очередей достаточное:
ethtool -l enp5s0f0
# Если Combined меньше, чем хотелось бы:
ethtool -L enp5s0f0 combined 8
Для Ceph-нод с 25GbE-картами (Intel E810) есть смысл посмотреть в сторону DPDK и OVS-DPDK, но это уже отдельная история — там нужны hugepages, привязка к ядрам и перестройка сетевого стека.
Если всё пошло не так: аварийное восстановление
Главный страх при смене NIC — потерять удалённый доступ к серверу. Несколько приёмов, которые помогут вернуть контроль.
Если ifreload -a не помог и сеть не поднялась — перезагрузитесь. Systemd-сервис pvenetcommit при старте подхватит новую конфигурацию из interfaces.new (если Вы правили через GUI) или напрямую из /etc/network/interfaces.
Если конфиг содержит ошибку и сервер вообще не грузится в сеть — загрузитесь в recovery mode через GRUB. Там будет консоль с доступом к файловой системе, и можно будет откатить interfaces к бэкапу:
cp /root/interfaces.backup /etc/network/interfaces
reboot
Если GRUB недоступен (сервер в дата-центре за тысячу километров) — используйте IPMI/iLO для доступа к KVM-консоли. Это та ситуация, когда IPMI-порт окупает себя целиком.
Open vSwitch: когда Linux Bridge уже мало
Для стандартных инсталляций Linux Bridge покрывает задачи на 100%. Мосты живут в ядре, не зависят от userspace-демонов, и если что-то ломается — масштаб бедствия ограничен. Proxmox SDN (Software Defined Networking) тоже построен поверх Linux Bridge.
Open vSwitch (OVS) становится интересен, когда появляются задачи посложнее: десятки VLAN с гибкой маршрутизацией, port mirroring для IDS, интеграция с OpenFlow-контроллерами. Если вы на этапе выбора платформы, полезно сначала сравнить варианты — у нас есть разбор популярных гипервизоров. OVS — это микс ядерного модуля и userspace-процесса (ovs-vswitchd), и если демон упадёт, сеть ляжет. Зато OVS умеет VXLAN для overlay-сетей между узлами кластера, QinQ (двойная инкапсуляция VLAN) и LACP с адаптивным хэшированием (balance-tcp), которое лучше распределяет трафик от одного клиента по портам бонда.
Конфиг OVS в /etc/network/interfaces выглядит принципиально иначе — физический интерфейс подключается как OVSPort, а IP назначается на OVSIntPort:
auto enp5s0f0
iface enp5s0f0 inet manual
ovs_bridge vmbr0
ovs_type OVSPort
auto host0
iface host0 inet static
address 10.0.0.5/24
gateway 10.0.0.1
ovs_type OVSIntPort
ovs_bridge vmbr0
auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports enp5s0f0 host0
Переход на OVS при замене карты — удобный момент, если Вы давно планировали. Но если единственная задача — заменить NIC и восстановить связность, не усложняйте. Linux Bridge отработает. Как выразился один из разработчиков Proxmox SDN: «Linux Bridge — это целиком ядро. OVS — микс ядра и сервиса. Если сервис упадёт, Вы теряете сеть. Держите проще.»
Чек-лист замены NIC: распечатайте и повесьте в серверной
Коротко, без лирики — порядок действий для замены сетевой карты в Proxmox VE:
- Сохранить ip a, lspci | grep net, /etc/network/interfaces, MAC-адрес старой карты
- Поставить noout на Ceph-кластере (если есть Ceph)
- Мигрировать VM на другие ноды или предупредить владельцев о простое
- Выключить сервер, заменить карту физически
- Загрузиться, подключиться через IPMI-консоль
- Определить имя нового интерфейса: ip link show
- Заменить старое имя на новое в /etc/network/interfaces (через vi или sed)
- Применить: ifreload -a
- Проверить: ping, ethtool, bridge link show, доступность GUI
- Закрепить имя: pve-network-interface-pinning generate → перезагрузка
- Снять noout с Ceph, проверить ceph status
Что запомнить
Замена сетевой карты в Proxmox — операция на пятнадцать минут, если к ней подготовиться. Сделайте бэкап конфига. Узнайте имя нового интерфейса через ip link или lspci. Замените старое имя на новое в /etc/network/interfaces. Примените через ifreload -a. Закрепите имя через .link-файл, чтобы следующее обновление ядра не преподнесло сюрприз.
А для тех, кто меняет карты регулярно (миграции, апгрейды парка), пиннинг интерфейсов по MAC — не опция, а гигиена. Один раз настроили — и больше не вспоминаете про «предсказуемые» имена, которые на деле предсказуемы только для systemd.
