Можно ли сравнивать Xen и KVM напрямую?

Прямое сравнение Xen и KVM не показывает, как будет эксплуатироваться инфраструктура. Xen выступает нижним слоем виртуализации, а KVM обычно работает в составе Linux-стека с QEMU и средствами управления, такими как libvirt. Поэтому сравнивать следует конкретные платформы и их конфигурации. Проверьте, какие компоненты понадобятся для управления одиночным хостом и пулом, создания шаблонов VM, обновлений и разграничения доступа администраторов. Отдельно оцените совместимость оборудования: HCL, версии firmware, NIC, HBA, RAID-контроллеры и внешнее хранилище для целевого релиза. Также важны предпосылки миграции и HA, интеграции API, журналирование, резервное копирование, мониторинг, порядок получения исправлений и навыки команды. Итоговые возможности определяет не скорость или название гипервизора, а выбранный стек управления и готовность процессов эксплуатации.

Можно ли сравнивать Xen с VMware vSphere как с одним гипервизором?

Нет, такое сравнение будет неполным. Xen — базовый гипервизор, тогда как vSphere объединяет ESXi и средства централизованного управления vCenter Server. Наличие одного хоста не означает, что автоматически доступны миграция, высокая доступность или балансировка: для этих возможностей требуются соответствующие компоненты, архитектура, ресурсы и права на функции. Сопоставляйте конкретную Xen-платформу и конкретную конфигурацию vSphere. Проверьте HCL и firmware для серверов, NIC, HBA, RAID-контроллеров и хранилища. Уточните, какие типы storage, сети, совместимость CPU и запас ресурсов необходимы для миграции или HA. Оцените API, роли, журналирование, обновления, интеграции с резервным копированием и мониторингом. Также отдельно сравните модель сопровождения: кто отвечает за инциденты, как получаются исправления, какие функции доступны по подписке и готова ли команда поддерживать выбранный стек.

Можно ли ставить XenServer, если адаптера нет в HCL, но для него есть Linux-драйвер?

Нет, считать адаптер совместимым только из-за Linux-драйвера нельзя. Для XenServer нужно сверить точные модели NIC, HBA, RAID-контроллеров, CPU, сервера и внешнего хранилища с HCL выбранного релиза. Если компонента нет в матрице, его статус и риск следует отдельно согласовать, а не заменять проверку предположением.

Что делать, если установщик XenServer показывает неожиданные диски?

Сначала зафиксируйте, какой накопитель или логический том предназначен именно для XenServer, а какие устройства содержат VM, ISO и нужные системные данные. Не продолжайте, пока назначение каждого отображаемого диска не подтверждено. Если набор устройств отличается от ожидаемого, проверьте конфигурацию RAID, подключение кабелей, режим работы контроллера и его драйверную совместимость с выбранным релизом XenServer. Также убедитесь, что установщик видит накопители в соответствии с проектной схемой хранения. Перед подтверждением разметки ещё раз сравните выбранный диск с инвентарным номером или документацией. Установка может переформатировать целевой накопитель; наличие RAID не предотвращает потерю данных при выборе неправильного массива.

Нужны ли Intel VT-x или AMD-V для HVM-виртуальных машин Xen?

Да. HVM-гости Xen используют аппаратную виртуализацию процессора: Intel VT-x для Intel или AMD-V для AMD. Перед развёртыванием убедитесь по документации CPU и в BIOS/UEFI, что расширение доступно и включено. Если оно не обнаружено, проверьте модель CPU, настройки firmware и необходимость полного отключения питания.

Нужны ли PV-драйверы, если гостевая VM запускается в режиме HVM?

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

Xen и XenServer: архитектура, подготовка и выбор платформы

Xen — bare-metal гипервизор, работающий непосредственно на сервере. Он запускает привилегированный управляющий домен Dom0, а гостевые виртуальные машины работают как непривилегированные домены DomU. XenServer и XCP-ng — не синонимы Xen, а отдельные платформы со своими средствами установки, управления, обновления и поддержки. Их развёртывание начинается с выбора релиза и проверки совместимости сервера, адаптеров, сетей и хранилища. Выбирать конкретную платформу стоит по этим проверкам, возможностям управления, модели сопровождения и навыкам команды, а не только по открытости гипервизора или наличию бесплатного варианта.

Xen Project, XenServer и XCP-ng: разные уровни экосистемы

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

XenServer — платформа серверной виртуализации на базе Xen, развиваемая в экосистеме Cloud Software Group. Она объединяет гипервизор с XAPI — API и управляющим стеком, установкой, средствами администрирования и правилами жизненного цикла продукта. Условия получения обновлений, доступные функции и коммерческая поддержка определяются конкретным релизом и предложением поставщика, а не названием гипервизора Xen.

XCP-ng — самостоятельный дистрибутив серверной виртуализации на базе Xen Project и XAPI. Он исторически возник из форка XenServer, однако его нельзя описывать как «тот же XenServer»: у XCP-ng собственные сборки, репозитории, цикл релизов, политика поддержки и сообщество. Проект развивается при участии Vates; для централизованного управления в его экосистеме часто используют Xen Orchestra, но Xen Orchestra — управляющая платформа, а не гипервизор.

Сравнивать нужно продукты одного уровня: готовую платформу с готовой платформой, а не Xen как компонент с полной платформой виртуализации.

Сущность	Что это	Что не следует предполагать
Xen Project / Xen	Проект и гипервизор Type 1.	Что Xen Project сам предоставляет единую готовую платформу с установщиком и интерфейсом управления либо гарантирует SLA и совместимость конкретного сервера.
XenServer	Готовая платформа на базе Xen с собственными релизами и стеком управления.	Что любой образ Xen или XCP-ng можно обновить до XenServer либо подключить к нему без проверки совместимости.
XCP-ng	Самостоятельная платформа на базе Xen и XAPI.	Что её репозитории, поддержка, выпуски и ограничения идентичны XenServer.

Релизы и поддержка

Поддерживаемость Xen Project, XenServer и XCP-ng меняется независимо. Перед проектом изучите сведения о жизненном цикле и примечания к выпуску именно выбранного продукта: Xen Project публикует их в документации проекта, XenServer — в документации и материалах Cloud Software Group, XCP-ng — в документации и примечаниях к выпускам проекта XCP-ng. Не переносите срок поддержки, исправления безопасности или возможности одного выпуска на другой.

Как устроена архитектура Xen: гипервизор, Dom0 и DomU

В Xen нижний слой — компактный гипервизор над физическим оборудованием. Он запускает домены, изолирует их и предоставляет механизмы управления ресурсами. Над ним запускается Dom0 — первый привилегированный управляющий домен. В типичной схеме Dom0 содержит драйверы устройств, управляющие службы и инструменты, через которые создают, запускают и обслуживают гостевые системы.

Обычная виртуальная машина в Xen — это DomU, непривилегированный гостевой домен. Он выполняет гостевую ОС и приложения, но не получает неограниченный прямой доступ к физическому оборудованию. Домены взаимодействуют с гипервизором через гипервызовы, причём допустимый набор операций определяется привилегиями домена. В типичной конфигурации доступ к виртуальным дискам и сетевым устройствам обслуживают серверные компоненты в Dom0.

Слой	Роль	Практическое следствие
Оборудование	CPU, память, сетевые и storage-адаптеры, загрузочные носители.	Их драйверная и платформенная совместимость влияет на запуск и эксплуатацию хоста.
Xen	Исполняет домены и контролирует низкоуровневую виртуализацию.	Не является полноценной административной ОС для повседневной работы.
Dom0	Управляет VM и обычно обслуживает ввод-вывод.	Его работоспособность критична для управления хостом и пути к устройствам.
DomU	Запускает гостевую ОС и прикладную нагрузку.	Изоляция VM не отменяет настройки сети, резервного копирования и защиты гостевой ОС.

Состав Dom0 зависит от платформы

Нельзя считать, что Dom0 на всех установках Xen содержит одинаковые драйверы, службы или инструменты. Их состав определяется дистрибутивом, выбранным стеком управления и релизом платформы. Для XenServer и XCP-ng ориентируйтесь на руководство именно своей версии.

HVM, аппаратная виртуализация и паравиртуальные драйверы

Аппаратная виртуализация использует расширения процессора: Intel VT-x у Intel или AMD-V у AMD. Благодаря им Xen может запускать HVM-гости — виртуальные машины с аппаратно виртуализированной платформой, в том числе немодифицированные гостевые ОС. Это соответствует идее полной виртуализации, но состав эмулируемого и виртуального оборудования зависит от выбранной платформы и конфигурации VM.

Паравиртуализация — другой механизм: гостевая ОС или её драйверы знают, что работают в виртуальной среде, и используют интерфейсы Xen вместо имитации части оборудования. В Xen возможны PV-гости, однако типичный современный сценарий — HVM-гость с паравиртуальными сетевыми и дисковыми драйверами. То есть режим запуска CPU и способ работы виртуального устройства не обязаны совпадать: HVM не означает обязательную эмуляцию каждого устройства.

Понятие	За что отвечает	Типичный вывод
HVM	Аппаратно виртуализированный запуск гостевой ОС.	Позволяет запускать немодифицированные ОС при наличии требуемых возможностей CPU.
PV	Паравиртуализированный режим гостя Xen.	Требует поддержки со стороны гостевой ОС или её окружения.
PV-драйверы	Эффективный обмен гостя с виртуальными устройствами.	Могут применяться внутри HVM-VM и требуют проверки поддержки драйверов в конкретной гостевой ОС.
PVH	Один из режимов Xen, сочетающий аппаратную виртуализацию с паравиртуальными интерфейсами.	Его доступность и применимость зависят от платформы, гостевой ОС и релиза.

Перед развёртыванием полезно отдельно проверить две вещи: хост видит включённые расширения виртуализации CPU, а выбранная гостевая ОС поддерживает нужные виртуальные устройства и драйверы. Инструкции по включению VT-x, AMD-V и IOMMU приведены в статье «Как включить Intel VT-x, AMD-V и IOMMU в BIOS/UEFI сервера».

Что проверить до установки XenServer на физический сервер

Установка XenServer начинается не с загрузки ISO, а с выбора поддерживаемой связки «релиз платформы — модель сервера — CPU — контроллеры — адаптеры». Официальные требования к процессору, памяти, загрузочному носителю и хранилищу VM, а также список совместимого оборудования (Hardware Compatibility List, HCL) следует брать из документации именно выбранного релиза XenServer. Совместимость сервера в целом не доказывает, что поддерживаются его конкретные сетевые адаптеры (NIC), адаптеры подключения хранилища (HBA), RAID-контроллер или версия микропрограммы.

Предустановочный маршрут для XenServer

Это не инструкция по установке, а минимальная последовательность, которая позволяет не обнаружить критичную несовместимость после записи установочного носителя.

1
Зафиксируйте целевой релиз и способ управления
Определите, какой выпуск XenServer будет использоваться, как хост будет администрироваться и нужен ли пул из нескольких узлов. Сверьте release notes, lifecycle, поддерживаемые способы управления, создания VM, подключения хранилищ, миграции и высокой доступности для этого выпуска. Результат — перечень требуемых функций и ограничений. Если функция описана только для другого релиза, подписки или архитектуры, не включайте её в проект без отдельного подтверждения.
2
Проверьте сервер и адаптеры по матрице совместимости
Сопоставьте точные модели сервера, CPU, сетевых адаптеров, HBA, RAID-контроллеров и внешнего хранилища с HCL выбранного XenServer. Зафиксируйте установленные версии BIOS/UEFI, BMC и firmware адаптеров. Ожидаемый результат — каждый критичный компонент либо присутствует в матрице, либо его статус и риск согласованы. При отсутствии компонента в HCL не заменяйте проверку предположением о совместимости Linux-драйвера.
3
Проверьте виртуализацию CPU и доступ к консоли
Убедитесь по документации CPU и в BIOS/UEFI, что доступны и включены Intel VT-x либо AMD-V. Подготовьте локальную или out-of-band-консоль, чтобы увидеть ход установки и восстановить настройки после перезагрузки. Ожидаемый результат — установщик распознаёт процессор и не сообщает об отсутствии аппаратной виртуализации. Если расширение не обнаружено, проверьте модель CPU, настройки firmware и необходимость полного выключения питания по документации сервера.
4
Разделите сети до установки
Назначьте сеть управления: VLAN, IP-адресацию, шлюз, DNS, MTU, физические порты и резервирование каналов, если оно нужно. Отдельно спланируйте потоки VM, миграции и доступа к хранилищу. Результат — схема, по которой понятно, к какому коммутатору и VLAN подключается каждый интерфейс. Если один порт предполагается для нескольких потоков, заранее проверьте VLAN-транк и допустимый MTU на всём пути.
5
Выберите и защитите целевой диск установки
Определите отдельный накопитель или логический том для самого XenServer и отдельно места для VM, ISO и системных данных в соответствии с проектом. Сверьте видимость дисков контроллером и установщиком. Результат — однозначно подписанный целевой диск, не содержащий нужные данные. Если установщик показывает неожиданный набор устройств, остановите установку и проверьте RAID-конфигурацию, кабели, режим контроллера и драйверную совместимость.
6
Проверьте путь к хранилищу VM
Для локального, NFS, iSCSI, Fibre Channel или другого планируемого варианта подтвердите доступность сети либо SAN-фабрики, параметры аутентификации и поддержку выбранного типа storage в целевом релизе. Ожидаемый результат — документированный путь от каждого хоста к хранилищу. Если общее хранилище требуется для конкретной миграции или кластерной функции, не заменяйте его локальными дисками без проверки ограничений этой функции.
7
Получите образ и сверяйтесь с руководством релиза
Загружайте установочный образ через официальный канал XenServer, проверяйте опубликованные контрольные суммы и используйте руководство по установке того же выпуска. Ожидаемый результат — проверенный образ и понятный план отката. Перед подтверждением разметки ещё раз сопоставьте выбранный установочный диск с инвентарным номером или схемой хранения.

Установщик может очистить выбранный накопитель

Установочный процесс XenServer обычно требует выбрать целевой диск и может переформатировать его. Не начинайте установку, пока не подтверждено назначение каждого видимого массива и накопителя. Наличие RAID не означает, что данные на нём защищены от ошибочного выбора диска.

Меню и статусы зависят от версии

Названия экранов установщика, пунктов BIOS/UEFI, кнопок средств управления и статусов меняются между моделями серверов, поколениями, версиями firmware и выпусками платформы. Для точной последовательности установки, поддерживаемых типов storage и параметров управления используйте официальное руководство XenServer для выбранного релиза и руководство производителя сервера.

Когда XenServer или XCP-ng обоснованно рассматривать

Платформа на Xen — разумный кандидат, если уже есть XenServer- или XCP-ng-совместимая инфраструктура, шаблоны VM, процессы резервного копирования, мониторинг, обученная команда и подтверждённая совместимость нового оборудования. Смена гипервизора в такой ситуации создаёт не только техническую задачу переноса VM, но и риск для процессов эксплуатации. Ограничения и порядок V2V разобраны в статье «Миграция виртуальных машин: live migration, V2V и P2V».

XenServer либо XCP-ng также стоит оценить, когда их экосистема закрывает конкретное требование: выбранный способ централизованного управления, интеграция с действующими инструментами, поддержка со стороны поставщика или подходящая модель сопровождения. Для XCP-ng необходимо отдельно определить, достаточны ли поддержка сообщества и собственные компетенции либо требуется коммерческая поддержка и какой именно её уровень покрывает проект.

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

Xen vs KVM и VMware vSphere: сравнивайте платформы, а не скорость гипервизора

Сравнение «Xen vs KVM» некорректно без уровня сравнения. KVM — компонент ядра Linux для аппаратной виртуализации, который обычно работает вместе с QEMU и средствами управления, например libvirt. Ему следует противопоставлять не только Xen, но и целый выбранный стек управления KVM. Практическая работа с этим стеком описана в материале «KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent».

Сравнение Xen-платформ с VMware vSphere тоже требует точности: vSphere объединяет ESXi и средства централизованного управления vCenter Server, а доступность кластерных возможностей зависит от состава продукта, подписки и архитектуры. Нельзя считать, что наличие одного хоста автоматически даёт миграцию, HA или балансировку. О предпосылках VMware-функций читайте в статье «VMware vSphere и vCenter Server: установка VCSA и добавление хостов».

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

Критерий	Что проверять	Почему это важнее общего сравнения «быстрее/медленнее»
Готовность платформы	Какие компоненты нужны для управления одним хостом, пулом, шаблонами, обновлениями и доступом администраторов.	Xen, KVM и ESXi — разные базовые слои; итоговые возможности создаёт полный стек.
Совместимость оборудования	HCL, версии firmware, NIC, HBA, RAID, GPU и внешнее хранилище для конкретного релиза.	Неподдерживаемый адаптер может сделать недоступным хранилище или сеть независимо от производительности CPU.
Миграция и HA	Предпосылки, тип хранилища, совместимость CPU, сеть, запас ресурсов и права на функции.	Миграция, автоматический перезапуск и непрерывность приложения — разные результаты.
Управление и автоматизация	API, роли, журналирование, интеграции, инструменты управления образами и конфигурацией.	Набор инструментов определяет ежедневные операции и скорость восстановления.
Поддержка и обновления	Кто отвечает за инцидент, откуда берутся исправления, как устроены lifecycle и окно обновлений.	Одинаковый гипервизор не делает одинаковыми обязательства поставщиков.
Лицензирование и эксплуатация	Метрики лицензирования, подписки, права на обновления, стоимость обучения и сопровождения.	Бесплатный старт не равен низкой стоимости владения, а подписка не заменяет квалификацию.
Компетенции команды	Опыт с сетью, storage, API, мониторингом, бэкапом и аварийными процедурами выбранной платформы.	Операционная ошибка часто создаёт больший риск, чем различие гипервизорных механизмов.

Выбирайте XenServer, если его поддерживаемый релиз совместим с сервером, нужные функции подтверждены для вашей модели поставки, а команда или действующая среда уже ориентированы на этот стек.
Рассматривайте XCP-ng, если его независимый цикл релизов, стек XAPI и вариант сопровождения соответствуют требованиям, а поддержка оборудования и интеграций подтверждена для планируемого выпуска.
Рассматривайте платформу на KVM, если подходит Linux-ориентированная модель эксплуатации, выбранный стек управления закрывает требования и команда готова сопровождать его компоненты.
Рассматривайте VMware vSphere, если её поддерживаемая конфигурация, доступные по подписке функции и процессы vCenter соответствуют проекту.
Для полного сопоставления платформ и расчёта эксплуатационных факторов используйте «VMware, Hyper-V, Proxmox, KVM и Xen: выбор платформы виртуализации».

Границы возможностей одного хоста и платформы

Один физический хост с XenServer или XCP-ng позволяет запускать VM, но сам по себе не создаёт отказоустойчивость. Для высокой доступности нужны несколько узлов, корректная схема хранения и сети, запас ресурсов для отказа, а также функции, доступные в конкретном релизе и модели поддержки. Автоматический перезапуск VM после сбоя хоста не равен непрерывной работе приложения и не заменяет резервное копирование.

Не планируйте число серверов, сети и хранилище только исходя из возможности создать пул. Для оценки нагрузок и запаса на случай обслуживания или отказа узла используйте «Как спроектировать виртуальную инфраструктуру для продакшена и 1С». Защита гипервизора и плоскости управления рассмотрена отдельно в статье «Защита виртуальных машин: изоляция, шифрование и границы гипервизора».

Термины в статье

Аппаратная виртуализация: Аппаратная виртуализация — способ запуска ВМ с поддержкой процессора и платформы, где привилегированные операции гостя обрабатываются специальными механизмами CPU, а не только программной эмуляцией.
Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальное оборудование: Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Гипервизор Type 1: Гипервизор, работающий непосредственно на аппаратном уровне, а не как приложение хостовой ОС, и распределяющий ресурсы сервера между виртуальными машинами.
Паравиртуализация: Метод виртуализации, при котором гостевая ОС или её драйверы используют интерфейсы гипервизора и гипервызовы вместо эмуляции части виртуального оборудования.
Полная виртуализация: Тип системной виртуализации, при котором гипервизор предоставляет ВМ виртуальную аппаратную платформу для запуска немодифицированной гостевой ОС.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Шаблон виртуальной машины: Подготовленный объект платформы виртуализации с образом ОС и заданной конфигурацией для повторяемого развертывания новых виртуальных машин.
Эмуляция: Эмуляция — программное воспроизведение устройства или аппаратной платформы, при котором гостевая система использует их интерфейс без прямого доступа к реальному оборудованию.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
Dom0: Dom0 — первый привилегированный управляющий домен Xen, который запускает гостевые домены и обычно обслуживает их ввод-вывод; сам гипервизор Xen работает ниже.
DomU: DomU — непривилегированный гостевой домен Xen, выполняющий ОС и приложения с изолированными ресурсами; доступ к большинству устройств он получает через Dom0.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hardware Compatibility List: Hardware Compatibility List — перечень проверенных сочетаний оборудования и ПО, определяющий конфигурации, поддерживаемые для заданной платформы или продукта.
HBA: HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
Hypercall: Hypercall — вызов интерфейса гипервизора из гостевой ОС для выполнения привилегированной операции, недоступной гостю напрямую на физическом оборудовании.
Intel VT-x: Intel VT-x — расширение процессоров Intel для аппаратной виртуализации x86, вводящее режимы VMX для выполнения гостевых ОС под контролем гипервизора без полной программной эмуляции.
IOMMU: IOMMU — аппаратный блок, который преобразует адреса DMA-запросов устройств в адреса физической памяти и ограничивает их доступ; нужен для изоляции и прямого назначения PCIe-устройств ВМ.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
RAID-контроллер: Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
V2V: V2V — перенос существующей виртуальной машины с одной платформы виртуализации на другую с преобразованием дисков и конфигурации под целевой гипервизор.
vCenter Server: Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры
XCP-ng: XCP-ng — дистрибутив платформы серверной виртуализации на базе гипервизора Xen Project и стека XAPI. Серверы с XCP-ng объединяют в пулы для запуска и миграции виртуальных машин.
Xen: Xen — гипервизор первого типа, работающий непосредственно на сервере и поддерживающий режимы виртуализации HVM, PV и PVH.
Xen Orchestra: Xen Orchestra — платформа централизованного управления XCP-ng и XenServer через XAPI, а не гипервизор, непосредственно исполняющий виртуальные машины.
XenServer: XenServer — платформа серверной виртуализации на базе гипервизора Xen типа 1 для запуска и управления виртуальными машинами на физических серверах.