Чек-лист безопасного обновления Proxmox VE

Что именно считать обновлением

Плановая установка пакетов внутри одной поддерживаемой версии Proxmox VE и переход на следующий major-релиз — разные работы. В первом случае обычно достаточно проверить состояние узла, выполнить apt update и apt full-upgrade, затем перезагрузить хост, если обновились ядро, systemd или компоненты виртуализации. Major-upgrade требует отдельной инструкции производителя, проверки совместимости Ceph, резервной копии конфигурации и последовательного обновления всех узлов.

Нельзя начинать с команды обновления только потому, что веб-интерфейс показывает доступные пакеты. Сначала фиксируют исходное состояние: версии pve-manager и ядра, состав кластера, состояние хранилищ, свободное место и список активных гостевых систем. Эта запись нужна не для отчётности, а чтобы после перезагрузки отличить новое отклонение от существовавшего ранее.

Окно работ должно учитывать миграцию виртуальных машин, перезагрузку каждого узла и время на проверку. Для одиночного хоста обновление без остановки ВМ возможно не всегда: запущенные процессы продолжат работать со старым ядром, но для активации нового ядра потребуется перезагрузка самого узла.

• Minor-обновление: пакеты в рамках текущего поддерживаемого релиза.
• Major-обновление: переход, например, между поколениями PVE; выполнять только по официальной upgrade-инструкции.
• Обновление Ceph: самостоятельный этап со своей матрицей совместимости и порядком.
• Обновление гостевых ОС не входит в обновление гипервизора.

Зафиксировать версии и здоровье платформы

До любых изменений узел должен быть предсказуемо здоров. Ошибка quorum, недоступное хранилище, деградированный ZFS-пул или заполненный корневой раздел — причина перенести работы. Обновление не исправляет такие состояния автоматически и часто усложняет диагностику: после перезапуска сервисов одновременно меняются пакеты и проявляется исходная неисправность.

Команды выполняют на каждом узле. Вывод сохраняют в журнал работ. Для кластера дополнительно сверяют время, DNS-разрешение имён узлов и доступность corosync-сети. Если используется HA, все ресурсы должны иметь понятное текущее размещение, а миграция между узлами — быть заранее проверена на некритичной ВМ.

pveversion -v
uname -a
pvecm status
pvesm status
df -h && df -i
zpool status
systemctl --failed

Для одиночного узла команды pvecm и проверки quorum неприменимы; это не ошибка, если хост изначально не включён в кластер.

Проверить репозитории и доступный путь обновления

Смешивание репозиториев разных выпусков Debian или Proxmox — одна из наиболее опасных причин частично обновлённой системы. Проверяют файлы в /etc/apt/sources.list и /etc/apt/sources.list.d, наличие корректного enterprise либо no-subscription репозитория и отсутствие старых записей. Enterprise-репозиторий требует действующей подписки; переключать его на no-subscription только для устранения ошибки доступа без согласования не следует.

После apt update необходимо прочитать предупреждения, а не переходить сразу к установке. Ошибки подписи, Release file, DNS или TLS означают, что индекс пакетов недостоверен либо неполон. Команда apt list --upgradable полезна для оценки состава, но окончательный план зависимостей показывает симуляция full-upgrade.

Если симуляция предлагает удалить pve-manager, proxmox-ve, qemu-server или большой набор базовых пакетов, обновление останавливают. Обычно это признак неверных репозиториев, удержанных пакетов или незавершённого предыдущего перехода.

• Сверить кодовое имя Debian и выпуск PVE с официальной документацией.
• Убедиться, что сторонние репозитории поддерживают текущий выпуск.
• Разобраться с hold-пакетами до окна работ.
• Не использовать apt upgrade вместо рекомендованного full-upgrade без понимания различий зависимостей.

grep -R --line-number --no-messages '^deb' /etc/apt/sources.list /etc/apt/sources.list.d/
apt update
apt list --upgradable
apt-mark showhold
apt-get -s full-upgrade

Подготовить резервные копии и план возврата

Снимок виртуальной машины на том же хранилище не является резервной копией узла. Перед обновлением проверяют последнюю успешную задачу vzdump или Proxmox Backup Server, срок хранения и возможность прочитать резервную копию с другого узла. Для критичных систем разумна тестовая выборочная реставрация: зелёный статус задания подтверждает передачу данных, но не гарантирует загрузку гостевой ОС.

Конфигурацию гипервизора также нужно сохранить. В кластере /etc/pve обслуживается pmxcfs и не копируется как обычная директория всеми инструментами. Фиксируют конфигурации ВМ и контейнеров, сетевые настройки, параметры хранилищ, сведения о passthrough и содержимое локальных файлов, не входящих в кластерную конфигурацию.

Откат пакетов Proxmox не равен восстановлению снапшота. После миграции формата данных или конфигурации downgrade может быть не поддержан. Практический план возврата — остановить последовательность на первом проблемном узле, сохранить диагностику, вернуть нагрузки на не обновлённые узлы, а при повреждении хоста переустановить совместимый выпуск и восстановить конфигурацию и ВМ из проверенных копий.

• Проверить дату, размер и статус последней копии каждой критичной ВМ.
• Убедиться, что учётные данные и ключи доступа к backup-хранилищу доступны вне обновляемого узла.
• Экспортировать сетевую схему, storage.cfg и список PCI/USB passthrough.
• Записать критерий остановки: потеря storage, quorum, миграции или управления узлом.

Выбрать порядок для одиночного хоста и кластера

На одиночном сервере сначала корректно останавливают или переносят зависящие от него сервисы, затем выключают гостевые системы в согласованной последовательности. Автоматическое завершение из Proxmox работает только при наличии и исправности QEMU Guest Agent либо корректной обработке ACPI внутри гостя. Принудительное выключение используют как исключение, поскольку оно эквивалентно потере питания.

В кластере обновляют по одному узлу. На выбранном узле запрещают или контролируют автоматический возврат HA-нагрузки, мигрируют ВМ и контейнеры, убеждаются в отсутствии локальных дисков, недоступных на целевом узле, и только потом ставят пакеты. Следующий узел начинают после полноценной проверки предыдущего.

Кластер допускает временно разные patch-версии в процессе последовательного обновления, но долго оставлять смешанные версии нежелательно. Возможность live migration зависит от CPU-флагов, типа хранилища, версии QEMU и конфигурации устройства. PCI passthrough, локальный ISO, локальные диски и некоторые сетевые настройки делают live migration невозможной.

1. Выбрать наименее загруженный узел и проверить целевые хранилища.
2. Мигрировать нагрузки и убедиться, что они работают на новых узлах.
3. Обновить пакеты, изучить сообщения dpkg и перезагрузить узел.
4. Проверить узел, вернуть одну некритичную нагрузку и наблюдать.
5. Только после успешной проверки перейти к следующему узлу.

Установить пакеты без слепого подтверждения

Непосредственно перед установкой повторяют apt update и симуляцию, затем запускают full-upgrade в интерактивном терминале, который не пропадёт вместе с веб-сессией. Подойдут локальная консоль, IPMI/iKVM или заранее настроенный tmux. Доступ к out-of-band консоли особенно важен при обновлении ядра, сетевых пакетов или загрузчика.

На вопросах dpkg о конфигурационных файлах нельзя автоматически выбирать замену или сохранение для всех файлов. Сначала смотрят diff. Локально изменённые network interfaces, параметры systemd и конфигурация загрузчика могут быть необходимы этому хосту; одновременно старый конфиг может не содержать обязательных параметров новой версии. Решение фиксируют по каждому конфликту.

После установки просматривают итоговый вывод, список failed units и наличие нового ядра. Перезагрузку не откладывают на неопределённый срок: пока узел работает на старом ядре, фактическое состояние не соответствует набору установленных пакетов.

apt update && apt full-upgrade
pveversion -v
proxmox-boot-tool status
systemctl --failed
journalctl -p err..alert --since '30 minutes ago'
reboot

proxmox-boot-tool применяется не на каждой схеме загрузки. Не выполняйте команды refresh или init без проверки официальной документации и текущего boot setup.

Проверить узел после перезагрузки

Успешный вход в веб-интерфейс — лишь одна проверка. Сначала подтверждают загрузку ожидаемого ядра, версии пакетов, отсутствие failed units и членство узла в кластере. Затем проверяют каждое хранилище чтением и, где допустимо, тестовой записью. Для ZFS смотрят не только ONLINE, но и ошибки read/write/checksum; для Ceph ждут стабилизации health после возвращения OSD.

Далее запускают или мигрируют одну некритичную ВМ и проверяют сеть, DNS, дисковый ввод-вывод, guest agent и резервное копирование. Отдельно тестируют VLAN, bonding, firewall и SDN-зоны, если они используются: простой ping интерфейса управления не подтверждает прохождение трафика гостевых сетей.

Наблюдение продолжают после возврата рабочей нагрузки. Смотрят journalctl, графики CPU, memory pressure, latency хранилищ и ошибки сетевых интерфейсов. Только после стабильного периода узел считается завершённым этапом обновления.

• uname -r показывает ожидаемое новое ядро.
• pvecm status и pvesm status не содержат новых отклонений.
• Веб-интерфейс, API и консоль ВМ доступны.
• Миграция в обе стороны проходит для поддерживаемой тестовой ВМ.
• Backup-задача может прочитать гостевые диски и завершиться.
• Аппаратный мониторинг не показывает новых ошибок дисков, памяти или питания.

Когда остановиться и не продолжать кластер

Последовательное обновление ценно тем, что проблему можно локализовать. Если первый узел теряет кластерную связь, не видит storage, не загружает новое ядро или показывает устойчивые ошибки сервисов, обновлять остальные узлы нельзя. Смешанная среда на короткое время безопаснее, чем одинаково повреждённые узлы без рабочей площадки.

Соберите pveversion, journalctl текущей и предыдущей загрузки, вывод pvecm, pvesm и состояние сети. Не очищайте журналы и не запускайте массовую переустановку пакетов до фиксации причины. При обращении в поддержку точные версии, время ошибки и полный вывод полезнее пересказа сообщения из интерфейса.

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