Proxmox VE 9.0: что нового в гипервизоре

После обновления кластера до Proxmox VE 9.0 администраторы первым делом замечают изменённый интерфейс и новые пункты в разделе SDN — но под визуальными изменениями скрывается переход на свежую базу Debian 13 «Trixie» и новое ядро Linux ветки 6.14. Девятая мажорная версия гипервизора вышла вслед за веткой 8.x и принесла не только обновлённые пакеты, но и несколько долгожданных функций: снапшоты на толстых LVM-томах, правила аффинности для HA и фабрики в программно-определяемой сети.

Разберём, что именно изменилось, какие компоненты обновились и как безопасно перейти с Proxmox VE 8.x, не потеряв виртуальные машины и контейнеры. Материал ориентирован на администраторов, которые уже работают с Proxmox и планируют апгрейд.

Новая программная база: Debian 13 и свежий стек виртуализации

Фундамент Proxmox VE 9.0 — Debian 13 «Trixie» с ядром Linux 6.14. Это даёт более свежую поддержку оборудования: новые сетевые адаптеры, контроллеры хранения и улучшения в подсистеме виртуализации. Ключевые компоненты стека также обновлены.

В состав дистрибутива вошли актуальные версии основных пакетов виртуализации:

• 🖥️ QEMU 10.0 — обновлённый эмулятор с улучшениями производительности и поддержки устройств;
• 📦 LXC 6.0 — свежая ветка контейнерной подсистемы;
• 💾 ZFS 2.3 — поддержка RAIDZ-расширения и другие улучшения файловой системы;
• 🗄️ Ceph Squid 19.2 — актуальный релиз для гиперконвергентных кластеров;
• 🌐 Linux kernel 6.14 — новая ветка ядра в качестве стабильной основы.

Обновление базовой системы — главная причина, по которой миграция с 8.x требует подготовки: меняются версии системных библиотек, и сторонние репозитории, подключённые вручную, могут конфликтовать с пакетами Trixie.

SDN-фабрики: новый уровень сетевой виртуализации

Одно из самых заметных нововведений — SDN Fabrics в подсистеме программно-определяемой сети. Механизм позволяет описывать маршрутизируемые сетевые фабрики между узлами кластера на основе динамической маршрутизации, в том числе с использованием протоколов семейства OSPF и OpenFabric через стек FRRouting.

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

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

⚠️ Внимание: эксперименты с SDN-фабриками на боевом кластере без тестового стенда могут нарушить связность узлов. Сначала проверьте конфигурацию на изолированной площадке.

Правила аффинности для HA и снапшоты на LVM-thick

Подсистема высокой доступности получила HA Rules — правила аффинности и анти-аффинности для ресурсов. Теперь можно декларативно указать, что две виртуальные машины должны держаться на разных узлах (например, реплики базы данных) или, наоборот, размещаться вместе для минимизации сетевых задержек. Раньше подобное поведение приходилось обеспечивать косвенными методами через группы HA.

Вторая долгожданная функция — снапшоты для виртуальных дисков на LVM-thick. Реализовано это через цепочки томов (snapshot-as-volume-chain), что снимает одно из старых ограничений: раньше полноценные снапшоты на блочных хранилищах без ZFS или Ceph были недоступны, и пользователи LVM-thick были вынуждены обходиться без них.

Улучшения интерфейса и мобильной версии

Веб-интерфейс получил ряд точечных доработок. Обновлён мобильный интерфейс: просмотр состояния ВМ, контейнеров и хранилищ со смартфона стал удобнее, основные действия — запуск, остановка, просмотр консоли — доступны в адаптированном виде. Полноценной заменой десктопной панели мобильная версия не является, но для экстренной проверки состояния кластера её достаточно.

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

Сравнение ключевых изменений с версией 8.x

Соберём основные отличия девятой версии от ветки 8.x в одну таблицу:

Точные минорные версии пакетов зависят от момента установки и обновлений репозитория — сверяйтесь с официальным changelog и дорожной картой проекта.

Как обновиться с Proxmox VE 8.4 до 9.0

Штатный путь — обновление «по месту» (in-place upgrade) с последней версии ветки 8.x. Разработчики предоставляют скрипт-проверку pve8to9, который анализирует систему и выдаёт список потенциальных проблем до начала апгрейда. Запускается он так:

pve8to9 --full

Общий порядок действий выглядит следующим образом:

• 📋 Сделайте полные резервные копии всех ВМ и контейнеров и проверьте их восстановление;
• 🔄 Обновите текущую систему 8.x до последнего состояния командой apt update && apt dist-upgrade;
• 🔍 Запустите pve8to9 --full и устраните все критические замечания;
• ⚙️ Переключите репозитории APT с Bookworm на Trixie и выполните apt dist-upgrade;
• 🔁 Перезагрузите узел и проверьте работу ВМ, хранилищ и сети.

В кластере узлы обновляют по одному, предварительно мигрируя нагрузку. Смешанный кластер из версий 8.x и 9.0 допустим на время миграции, но затягивать с ним не стоит.

⚠️ Внимание: ifupdown2 и сетевые конфигурации — самое уязвимое место апгрейда. Узел без доступа к физической консоли после перезагрузки может остаться без сети, если конфигурация /etc/network/interfaces содержит нестандартные конструкции. Проверьте её заранее и обеспечьте запасной канал доступа.

Что делать, если pve8to9 выдаёт предупреждения

Скрипт разделяет замечания на информационные, предупреждения и критические ошибки. Критические (FAIL) блокируют безопасное обновление — типичные причины: устаревшие пакеты из сторонних репозиториев, нехватка места в корневом разделе, кастомные настройки загрузчика. Устраните каждую проблему и повторите проверку до чистого результата.

Стоит ли обновляться прямо сейчас

Для домашних лабораторий и тестовых сред переход оправдан уже сейчас: новые функции вроде снапшотов на LVM и правил HA ощутимо упрощают жизнь. Для продуктивных кластеров разумнее выждать несколько минорных выпусков 9.0.x и понаблюдать за отзывами сообщества — это стандартная практика для мажорных релизов.

Помните и о жизненном цикле ветки 8.x: она ещё получает обновления безопасности, поэтому форсированной необходимости в миграции нет. Планируйте апгрейд в окно обслуживания с полными резервными копиями.

Часто задаваемые вопросы

Можно ли обновиться сразу с Proxmox VE 7.x до 9.0?

Нет, прямой переход не поддерживается. Сначала нужно обновиться до последней версии ветки 8.x, и только затем выполнять апгрейд до 9.0 по штатной процедуре с проверкой pve8to9.

Работают ли снапшоты на LVM-thick для всех виртуальных машин?

Функция реализована через механизм цепочек томов и имеет ограничения по форматам и сценариям использования. Перед применением на важных ВМ изучите официальную документацию по хранилищам и протестируйте снапшоты на некритичной машине.

Нужна ли подписка для обновления до Proxmox VE 9.0?

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

Можно ли откатиться с 9.0 обратно на 8.x, если что-то пошло не так?

Штатного механизма отката нет. Единственный надёжный способ вернуться — восстановление из резервной копии или переустановка узла с последующим восстановлением ВМ. Именно поэтому проверенные бэкапы перед апгрейдом обязательны.

Поддерживается ли смешанный кластер из узлов 8.x и 9.0?

Да, временная работа смешанного кластера допускается на период поэтапной миграции узлов. Однако постоянно эксплуатировать кластер в таком состоянии не следует — завершите обновление всех узлов в разумные сроки.