Смена основного IP-адреса в Proxmox VE: пошаговая инструкция

Есть в жизни админа такой особый вид развлечений — менять IP-адрес на работающем гипервизоре. Казалось бы, что может пойти не так? Правишь пару конфигов, перезапускаешь сеть, и готово. А потом сидишь в серверной в час ночи, подключившись через IPMI, потому что веб-интерфейс на порту 8006 ушёл в небытие вместе со старым адресом. Знакомо? Тогда эта инструкция — для Вас.

Смена основного IP в Proxmox VE — рутинная операция: переезд в другой VLAN, смена провайдера, реорганизация адресного пространства перед миграцией в дата-центр. Если вы ещё на этапе выбора гипервизора для вашей инфраструктуры, стоит заранее учесть особенности сетевой конфигурации каждой платформы. Задача простая ровно до того момента, пока Вы не забудете обновить один файл. Цена ошибки — потеря доступа к управлению, простой виртуальных машин, развал кластера. Proxmox VE network config устроен так, что все компоненты связаны между собой, и изменение IP-адреса сервера затрагивает цепочку зависимостей. Давайте разберёмся, как пройти эту процедуру аккуратно и без приключений.

Зачем вообще трогать IP на гипервизоре

Причин несколько, и все они связаны с изменениями в инфраструктуре:

• Переезд сервера в другой сетевой сегмент или VLAN. Типичная ситуация при росте компании — сеть сегментируется, и гипервизоры переезжают в выделенный management-VLAN. Держать ноду управления в одной подсети с пользовательскими рабочими станциями — так себе идея для безопасности инфраструктуры.
• Смена провайдера или пула публичных адресов. Провайдер выделил новую подсеть — значит, всем серверам нужны новые IP. А если у Вас dedicated-сервер с белым адресом — то без настройки сети Proxmox тут точно не обойтись.
• Подготовка к миграции в дата-центр или облако. Адресное пространство новой площадки не совпадает с текущим, и пересадресация неизбежна. Часто это этап плана по переезду из офисной серверной в коммерческий ЦОД, и здесь важно заранее изучить требования к серверным помещениям новой площадки.
• Реорганизация IP-плана. Сеть 10.0.0.0/8, где всё живёт в одном broadcast-домене, — это технический долг. Рано или поздно его придётся гасить, и Proxmox смена IP станет частью этого процесса.

Каждый из этих сценариев требует осознанного подхода. Менять IP на Proxmox VE — это не «вечерняя правка конфига». Это полноценный change request с планом, окном обслуживания, откатом и тестированием. Предупредите коллег, поставьте задачу в таск-трекер, согласуйте время простоя. Да, даже если «это займёт пять минут».

Почему «просто поменять IP» — плохая идея

Proxmox VE привязывает свой веб-интерфейс к hostname, а hostname резолвится через /etc/hosts. Если Вы поменяли IP в настройках сети, но забыли обновить /etc/hosts, — веб-интерфейс станет недоступен. Вот так просто. Порт 8006 слушает, но pveproxy привязан к адресу, который резолвится из hostname. Результат: браузер показывает «Connection refused», а Вы лихорадочно вспоминаете пароль от IPMI.

Это классическая ловушка «самоблокировки», и попадают в неё регулярно. Proxmox VE network config устроен так, что изменение IP адреса сервера — это не одно действие, а минимум два: файл /etc/network/interfaces и файл /etc/hosts. Пропустите второй — и консоль IPMI/iLO станет Вашим единственным другом.

И это ещё полбеды. Если Proxmox работает в кластере, смена IP одного узла без правильной процедуры разрушит кворум Corosync. Кластер перестанет видеть узел, live-миграция виртуальных машин откажет, репликация остановится, а в худшем случае — встанет весь кластер. Бэкапы, которые отправляются на Proxmox Backup Server с настроенным резервированием по старому адресу, тоже перестанут работать. И мониторинг потеряет связь с нодой, так что Вы даже не сразу узнаете о проблеме — если, конечно, не сидите перед экраном.

Подготовка: что нужно собрать заранее

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

Отдельный пункт — firewall. Если у Вас настроен встроенный Proxmox Firewall или внешний файрвол с правилами, завязанными на IP гипервизора, — их тоже нужно обновить. Иначе после смены адреса трафик будет дропаться, и Вы получите «работает, но не совсем».

Сделайте бэкапы ключевых файлов:

Проверьте доступ к out-of-band управлению (IPMI, iLO, iDRAC). Если у Вас нет физического или консольного доступа к серверу — отложите процедуру до тех пор, пока он не появится. Это не перестраховка, а здравый смысл.

Смена IP на одиночном хосте

Два пути: через веб-интерфейс или через CLI. Оба работают, но CLI даёт больше контроля и позволяет сделать все изменения до перезапуска сети. Рассмотрим оба варианта, чтобы Вы могли выбрать подходящий.

Через веб-интерфейс:

Перейдите в раздел System → Network, выберите сетевой мост vmbr0, нажмите Edit. Введите новый IPv4/CIDR и gateway. Нажмите OK, затем Apply Configuration. Proxmox применит изменения к файлу /etc/network/interfaces и попытается перезагрузить сетевой стек. Проблема в том, что веб-интерфейс не обновляет /etc/hosts автоматически. Если hostname резолвится в старый адрес — Вы теряете доступ к GUI ровно в момент нажатия «Apply».

Поэтому через веб-интерфейс менять IP безопасно только если Вы заранее подключились к консоли сервера (IPMI, iLO, iDRAC, KVM-переключатель) и готовы тут же доправить /etc/hosts руками. Или если сервер стоит рядом с Вами и к нему подключены монитор с клавиатурой — но в дата-центре такое бывает редко.

Через CLI (рекомендуемый способ):

Этот путь надёжнее, потому что позволяет сделать все изменения атомарно — до перезапуска сети. Вы правите оба файла, убеждаетесь, что всё корректно, и только потом даёте команду на применение. Если Вы подключены по SSH — имейте в виду, что после перезапуска сети текущая SSH-сессия может разорваться. Поэтому либо подключайтесь уже с адреса в новой подсети, либо держите параллельно открытую консоль через IPMI.

Найдите секцию vmbr0 и измените address и gateway:

Замените старый IP на новый в строке с hostname Вашего сервера:

Если после ifreload -a связь пропала — подключайтесь через IPMI и откатывайте из бэкапов:

Смена IP в кластере Proxmox

Кластерная конфигурация добавляет сложности. Corosync использует IP-адреса узлов для поддержания связи и кворума. Эти адреса жёстко прописаны в /etc/pve/corosync.conf. Если один узел вдруг появляется с новым IP, а конфиг не обновлён — кластер его не узнаёт и считает потерянным.

Изменить IP адрес сервера в кластере Proxmox — операция, которая затрагивает не только локальный узел, но и конфигурацию на всех остальных нодах. Corosync.conf — это распределённый файл, и его версия должна совпадать на всех участниках кластера.

Правило номер один: меняйте IP по одному узлу за раз. Не параллельте. Дождитесь полной стабилизации кластера — проверьте pvecm status, убедитесь, что все узлы в состоянии Online — и только потом переходите к следующему узлу.

Процедура выглядит так:

В файле corosync.conf найдите секцию nodelist и замените старый IP нужного узла на новый. Здесь есть нюанс — у каждого узла есть ring0_addr (или link0_addr в новых версиях Proxmox VE), именно здесь указывается IP для межнодовой коммуникации. Не забудьте инкрементировать значение config_version — без этого другие узлы не примут изменения. Corosync отслеживает версию конфига и игнорирует файлы со старым или одинаковым номером.

В выводе pvecm status ищите Quorate: Yes — это значит, что кворум собран и кластер работает штатно. Все узлы должны отображаться в списке членов кластера. Если статус показывает Quorate: No — не паникуйте. Проверьте, что на остальных узлах файл /etc/pve/corosync.conf содержит новый IP изменённого узла. Pmxcfs синхронизирует конфиг автоматически, но иногда (особенно при сетевых проблемах) синхронизация может запаздывать. При необходимости скопируйте обновлённый конфиг вручную и перезапустите corosync на всех узлах.

Если в кластере используется Ceph — проверьте также конфигурацию Ceph-мониторов. Их адреса могут быть привязаны к старому IP, и Ceph-кластер перестанет собираться после смены. Обновите /etc/ceph/ceph.conf и перезапустите ceph-mon при необходимости.

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

Чек-лист после смены IP

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

Стратегия отката

План Б нужен до начала работ, а не после того, как всё сломалось. Вот что должно быть готово заранее.

Бэкапы конфигов уже сделаны (мы об этом позаботились в начале). Для быстрого возврата старого IP достаточно восстановить файлы из .bak-копий и перезапустить сеть. Если Вы работаете через IPMI — у Вас есть доступ к серверу независимо от состояния сети. Вся процедура отката занимает 30 секунд:

Для кластера ситуация сложнее. Если после смены IP кворум не собирается, а откат IP не помогает — попробуйте принудительно задать ожидаемое количество голосов:

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

Ещё один нюанс — ARP-кэши. После смены IP на Вашем сервере коммутаторы и маршрутизаторы могут какое-то время помнить привязку старого IP к MAC-адресу. Обычно ARP-кэш обновляется за 1–5 минут, но на некоторых устройствах таймаут может быть длиннее. Если новый IP пингуется, но веб-интерфейс не отвечает — подождите. Или принудительно очистите ARP-таблицу на маршрутизаторе.

Заведите привычку: после каждого изменения сетевых настроек на Proxmox — ждите 15 минут и проверяйте всё повторно. Некоторые проблемы проявляются не сразу, особенно те, что связаны с DNS-кэшированием и ARP.

Настройка сети Proxmox — та область, где паранойя вознаграждается. Чем тщательнее подготовка, тем скучнее проходит миграция. А скучная миграция — это именно то, к чему стремится любой нормальный админ.