XCP-ng: альтернатива Proxmox, о которой мало пишут

MAATRIX

Если вы искали self-hosted платформу виртуализации, скорее всего первым в поиске попался Proxmox VE — и не зря, у него огромное сообщество и всё нужное сразу в комплекте. Но есть ещё один открытый гипервизор с корнями в enterprise-мире, который почти не обсуждают в русскоязычных статьях — XCP-ng. Разберём честно, чем он отличается от Proxmox, где у него реальные преимущества, а где — дополнительная головная боль.

Что такое XCP-ng и зачем он появился

XCP-ng — это бесплатный форк Citrix Hypervisor (в прошлом известного как XenServer), развиваемый компанией Vates. История простая: Citrix долгое время держал XenServer как открытый проект, но в какой-то момент начал урезать бесплатную версию и переводить функциональность в платные лицензии. Сообщество не согласилось с таким поворотом и форкнуло последнюю полностью открытую кодовую базу — так родился XCP-ng. Сейчас это полноценный проект с собственным циклом релизов, репозиториями пакетов и коммерческой поддержкой от Vates для тех, кому она нужна.

Позиционируется XCP-ng примерно там же, где Proxmox — как бесплатная альтернатива дорогим лицензиям VMware vSphere и Citrix Hypervisor. Но в основе у него не KVM, а гипервизор Xen — и это первое, что стоит понять, прежде чем сравнивать возможности.

Архитектура: Xen с Dom0 против KVM в ядре Linux

Proxmox построен на KVM (Kernel-based Virtual Machine) — модуле, который встроен прямо в ядро Linux. Ядро само становится гипервизором: виртуальные машины запускаются как процессы, которыми управляет тот же Linux-хост, на котором вы работаете через SSH или веб-интерфейс.

Xen устроен иначе. Это отдельный гипервизор (тип 1, bare-metal), который загружается до операционной системы и сам управляет железом. Для взаимодействия с миром у Xen есть управляющий домен — Dom0 (в случае XCP-ng это специально собранный CentOS/Linux-дистрибутив), который не является гипервизором сам по себе, а работает как привилегированная виртуальная машина поверх Xen. Через Dom0 идёт доступ к диску, сети, консоли управления — а виртуальные машины (DomU) исполняются гипервизором отдельно от Dom0.

Исторически Xen славился паравиртуализацией (PV) — режимом, где гостевая ОС знала, что работает под гипервизором, и не эмулировала железо, а напрямую обращалась к нему через специальные драйверы. Это давало выигрыш в производительности на старом железе без аппаратной поддержки виртуализации. Сегодня практический смысл этого различия почти исчез: современные процессоры Intel VT-x и AMD-V одинаково поддерживают аппаратную виртуализацию что для Xen (в режиме HVM), что для KVM, и оба гипервизора используют паравиртуализованные драйверы для диска и сети поверх аппаратной виртуализации — PV-drivers у Xen и virtio у KVM решают одну и ту же задачу похожими средствами.

Для практикующего администратора эта разница в архитектуре в 2026 году в основном прозрачна — вы не почувствуете принципиальной разницы в поведении виртуалки на Xen с HVM и виртуалки на KVM с virtio-дисками. Куда важнее то, что вырастает вокруг ядра гипервизора — инструменты управления, экосистема, community.

Управление: связка XCP-ng + Xen Orchestra против встроенного веб-интерфейса

Вот здесь начинается первое по-настоящему практическое отличие. Proxmox VE поставляется с полноценным веб-интерфейсом из коробки — вы устанавливаете один пакет, заходите на https://ваш-ip:8006 и получаете управление кластером, дисками, сетями, снапшотами, бэкапами — всё в одном месте, без дополнительных компонентов.

Сам XCP-ng такого встроенного веб-интерфейса не даёт. Базовое управление хостом идёт через утилиту командной строки xe:

# список виртуальных машин на хосте
xe vm-list

# создание VM из шаблона
xe vm-install template="CentOS 7" new-name-label="my-vm"

# запуск виртуальной машины
xe vm-start vm="my-vm"

# просмотр параметров сети
xe network-list
xe vif-list

Это рабочий инструмент, у XCP-ng также есть XenAPI (XAPI) — тот же REST/XML-RPC-подобный API, на котором построены сторонние интеграции. Но для повседневной работы через браузер этого недостаточно — почти все, кто ставит XCP-ng, ставят рядом отдельный компонент экосистемы: Xen Orchestra (XO). Это веб-приложение (обычно разворачивается как отдельная VM или контейнер), которое подключается к одному или нескольким хостам XCP-ng через XAPI и даёт привычную картину: дашборд, управление VM, снапшоты, бэкапы, метрики, консоль через VNC/noVNC.

Если у вас уже есть отдельная статья про миграцию между гипервизорами в закладках — вот прямое практическое следствие архитектуры: с Proxmox вы получаете управление сразу при установке хоста, с XCP-ng — управление хостом отдельно от полноценного веб-интерфейса, который нужно поднимать и поддерживать как второй компонент инфраструктуры. Официальная бесплатная версия Xen Orchestra ставится из исходников (сборка "XOA from sources"), готовая appliance-версия (XOA) с автообновлениями и частью функций — по подписке. Это не критично для одного хоста в лаборатории, но для эксплуатации в проде значит дополнительный сервис, который надо резервировать и обновлять отдельно от самого гипервизора.

Установка XCP-ng: первые шаги

Если решили попробовать, процесс выглядит так:

1. Скачиваете ISO с официального сайта xcp-ng.org и ставите на выделенный сервер или в тестовую VM с включённой вложенной виртуализацией.
2. Установка похожа на установку любого Linux-дистрибутива — минимум вопросов: диск, сеть, пароль root для Dom0.
3. После установки хост доступен по SSH и через xe-консоль, но веб-интерфейса пока нет.
4. Разворачиваете Xen Orchestra — либо собираете из исходников на отдельной Linux-машине (потребуется Node.js, набор зависимостей и скрипт xo-install.sh из официального репозитория), либо используете готовую community-сборку в виде OVA-образа, которую импортируете прямо в пул XCP-ng через xe vm-import.
5. Подключаете XO к хосту, указав его IP и root-пароль Dom0 — после этого управление идёт уже через браузер.

Для сравнения, с Proxmox шаги 3-5 просто не нужны — веб-интерфейс живёт на порту 8006 сразу после установки ISO.

Экосистема и сообщество: где Proxmox выигрывает объективно

Это второе честное отличие, и оно весомее архитектурного. У Proxmox огромное активное сообщество — форум на английском с десятками тысяч тем, множество русскоязычных статей, гайдов, YouTube-роликов, готовых ответов почти на любую нетиповую проблему: от странностей ZFS до тонкостей кластеризации Corosync. Документация Proxmox покрывает практически все сценарии, включая enterprise-возможности (кластеризацию, HA, живую миграцию, интеграцию с Ceph) в бесплатной версии.

XCP-ng заметно менее распространён, особенно в русскоязычном сегменте. Официальный форум XCP-ng и Xen Orchestra активен и отвечают там быстро и по делу, но объём накопленных тем и обсуждений на порядок меньше, чем у Proxmox. Практическое следствие: если вы упрётесь в нетиповую проблему — например, специфичный баг с определённой моделью сетевой карты или странное поведение при живой миграции между хостами разных поколений CPU — вероятность найти готовое решение через поиск заметно ниже. Придётся либо разбираться самостоятельно через логи Dom0 и xe-диагностику, либо писать на форум и ждать ответа от сообщества, которое просто меньше числом.

Для сравнения возможностей двух платформ по обычным сценариям виртуализации:

Корни в enterprise: когда это действительно преимущество

Xen как гипервизор — не новичок. Именно на нём десятилетиями строились облака первых крупных провайдеров (в том числе ранние версии Amazon EC2 использовали Xen), и на нём же годами держалась платформа Citrix XenServer в корпоративной виртуализации. Это не маркетинговая формулировка, а фактическая зрелость технологии в сценариях, где счёт идёт на сотни хостов, строгие SLA и сертифицированную поддержку.

XCP-ng унаследовал эту родословную буквально — как форк XenServer, он совместим с той же концептуальной моделью: пулы ресурсов, storage repositories (SR), общая архитектура управления через XAPI. Это значит, что для инженеров, которые годами работали с XenServer или Citrix Hypervisor в корпоративной среде, XCP-ng — не новая платформа для изучения с нуля, а знакомая модель без коммерческой лицензии. Миграция виртуальных машин с коммерческого Citrix Hypervisor/XenServer на XCP-ng технически ближе к обновлению версии, чем к переезду на принципиально другую платформу — экспорт VM в формате XVA и импорт через xe vm-import работает предсказуемо именно потому, что формат общий.

Это тот случай, где выбор XCP-ng — не компромисс, а осознанное продолжение уже знакомой экосистемы. Если ваша команда прежде администрировала Citrix Hypervisor и сценарий — снизить лицензионные расходы, сохранив архитектурную модель, XCP-ng предсказуемее, чем изучение Proxmox с нуля.

Частые вопросы