Proxmox VE 8.3: смотрим на PCIe passthrough и новый интерфейс в контексте резервной платформы

Proxmox VE 8.3 вышел в начале марта, и мы его смотрели не как основной стек - у нас это резервная платформа для клиентов, которым zVirt пока не подходит по тем или иным причинам: нет нужного сертификата по КИИ, нет нужного железа в листе совместимости, или просто клиент уже работает на Proxmox и переезд не стоит в приоритетах. Так что обзор - не «выбираем гипервизор», а «что изменилось в управлении кластером на том, что уже стоит».

PCIe passthrough: что реально добавили

Это самое обсуждаемое в release notes 8.3, и с практической точки зрения изменения там есть. Proxmox VE 8.3 переработал управление устройствами PCIe в нескольких местах.

Улучшена работа с IOMMU-группами. В предыдущих версиях при назначении PCIe-устройства виртуальной машине Proxmox требовал явно указывать, что делать с другими устройствами в той же IOMMU-группе. Если группа была «грязная» - например, несколько устройств в одной группе, а нужно только одно, - требовался либо патчированный VFIO, либо ручное разбиение. В 8.3 появился режим, в котором Proxmox сам предлагает варианты обработки группы и предупреждает если что-то пойдёт не так, прямо в интерфейсе.

Поддержка медиаторов для vGPU. Если раньше настройка vGPU поверх медиаторов (Intel GVT, NVIDIA vGPU) требовала ручной правки конфигов, теперь это частично вынесено в GUI. Нас это интересует пока косвенно - из наших клиентов на Proxmox никто GPU под ВМ не пробрасывает, но вопросы были.

Маппинг ресурсов на уровне кластера. Это то, что понадобилось нам непосредственно. Resource Mappings - возможность создать именованный маппинг PCIe-устройства на уровне кластера, который затем можно использовать в конфиге ВМ по имени, а не по PCI-адресу конкретного хоста - появились ещё в 8.0, и в 8.3 этот механизм получил доработки в интерфейсе. Звучит просто, но на практике это закрывало болезненный gap: при миграции ВМ между хостами приходилось вручную следить за тем, чтобы PCI-адреса устройств совпадали или переназначать конфиг ВМ руками после переезда.

На одном из наших стендов - небольшой кластер, где клиент использует passthrough сетевой карты для ВМ с функцией отдельного сетевого экрана - этот функционал мы проверили. Resource Mapping настраивается через datacenter -> resource mappings в новом интерфейсе. Создаёшь mapping с именем, указываешь соответствие «хост X -> PCI-адрес Y, хост Z -> PCI-адрес W», и дальше ВМ использует имя mapping. При ручной миграции на другой хост PCI-адрес подставляется автоматически. Работает, и это реально удобнее чем раньше.

Новый интерфейс управления кластером

В 8.3 существенно переработан раздел Datacenter в веб-интерфейсе. Это та часть, которую открываешь когда нужно посмотреть на кластер целиком - статус хостов, задачи, бэкапы, права доступа.

Изменения косметические по сути, но улучшают навигацию. Группировка разделов стала логичнее: раньше Resource Mappings были менее заметны в интерфейсе, HA-настройки были размазаны по нескольким вкладкам, а теперь они собраны в одном месте. Summary по кластеру показывает больше информации без необходимости идти в каждый узел отдельно.

Что отметим отдельно: в 8.3 улучшили отображение событий кластера и логов задач. В 8.2 и раньше журнал задач был достаточно скудным - видел статус «завершено» или «ошибка», но чтобы понять что именно пошло не так, надо было идти на конкретный узел. Теперь агрегированный лог на уровне кластера стал информативнее. Мелочь для тех, кто смотрит в него раз в неделю, но для нас при сопровождении это экономит время.

Что не изменилось и чего не хватает

Proxmox VE остаётся платформой, где значительная часть реальной конфигурации делается через файлы и командную строку. GUI сильно вырос за последние версии, но ряд сценариев - тонкая настройка VFIO, кастомные сетевые конфигурации, работа с несколькими OVS-бриджами - по-прежнему требует знания /etc/pve/ и понимания как работает corosync под капотом.

Для клиентов, у которых Proxmox появился как «временное решение до zVirt», это важно держать в голове: операционная сложность ниже, чем у oVirt/zVirt, но выше, чем у VMware с точки зрения наличия графических инструментов для всего подряд. Это не критика - просто уровень.

Встроенная HA по-прежнему работает только с кластером из трёх и более узлов с кворумом. Для небольших двухузловых инсталляций это означает использование внешнего qdevice или примирение с тем, что автоматического переключения не будет. Это известное ограничение Proxmox, которое в 8.3 никуда не делось.

Как это работает на наших клиентах

У нас Proxmox VE используется у части клиентов именно как переходная или вспомогательная платформа. Сценарии разные: кто-то пришёл с него и переезжает, кто-то держит отдельный кластер для задач, где zVirt создавал лишние трудности с лицензированием под конкретную инсталляцию.

Обновление с 8.2 до 8.3 прошло штатно на всех стендах, где мы его делали. Proxmox обновляется через apt upgrade с минимальными церемониями - это один из аргументов в пользу платформы для среды, где инфраструктурная команда небольшая. На одном кластере после обновления пришлось перезапустить менеджер виртуальных машин на одном узле - незначительная мелочь, ВМ не пострадали.

Resource Mappings - это то, что мы будем использовать активнее. Для клиентов с PCIe passthrough это реально упрощает управление конфигурацией. В рамках managed-сопровождения мы сейчас мигрируем конфиги тех клиентов, кто использует passthrough, на именованные mappings - это снижает риск человеческой ошибки при обслуживании.