Подходит ли бесплатная виртуализация для продакшена?

Бесплатная платформа может использоваться в продакшене, но решение нельзя принимать только по стоимости гипервизора. KVM и libvirt могут поставляться с Linux-дистрибутивом, а Proxmox VE доступен без подписки, однако это не добавляет автоматически поддержку оборудования, отказоустойчивый кластер, резервные мощности, репликацию или круглосуточное сопровождение. Для Proxmox VE Enterprise Repository требует подписки и рекомендуется для производственных систем. No-Subscription Repository доступен без неё, но пакеты в нём проходят менее строгую проверку и этот канал не рекомендуется для production. В любом случае необходимо заложить расходы на инженеров, мониторинг, резервное копирование, тестирование восстановления, обновления firmware и платформы, а также на сеть и хранилище. Перед внедрением подтвердите совместимость сервера, NIC, контроллеров и накопителей с выбранным релизом, определите RPO и RTO, проверьте возможность восстановления VM и обеспечьте N+1-ёмкость, если требуется HA.

Можно ли считать Xen Project готовой платформой виртуализации?

Нет. Xen Project — это гипервизор и базовые компоненты, а не готовая универсальная платформа управления кластером. Управление хостами, пулами, обновлениями, HA и миграцией нужно оценивать в контексте конкретной Xen-платформы, например XenServer или XCP-ng, и её версии, архитектуры и модели поддержки.

Нужен ли vCenter для vMotion и HA в VMware?

Да, для этих централизованных кластерных возможностей vCenter является необходимой частью архитектуры VMware. Отдельным ESXi-хостом можно управлять локально, но vMotion, vSphere HA и другие функции также зависят от совместимости хостов, архитектуры кластера и прав, предоставленных конкретной подпиской или договором.

Защищает ли живая миграция VM от потери данных?

Нет. Live Migration предназначена прежде всего для планового обслуживания и переноса работающей VM между совместимыми хостами с короткой паузой при переключении. Она не защищает от повреждения данных, отказа общего хранилища или сети управления и не заменяет резервное копирование и проверку восстановления.

Можно ли получить HA на одном физическом сервере?

Нет. Один физический хост остаётся единой точкой отказа для всех размещённых на нём VM независимо от гипервизора. Для HA обычно требуются несколько совместимых узлов, quorum там, где он нужен, резерв ресурсов N+1, доступное при отказе хоста хранилище, а также отдельные сети управления и миграции.

Что делать, если сетевой адаптер виден, но его нет в списке совместимости?

Сначала соберите точные сведения о сервере: модель и поколение, сетевой адаптер, версию BIOS/UEFI и firmware устройства. Эти данные можно получить из BMC, инвентаризации ОС или документации производителя. Затем проверьте сочетание конкретных моделей, драйверов и firmware в документации выбранной платформы. Для VMware сверяйте сервер, NIC, контроллеры, накопители и драйверы по официальному HCL именно для нужного релиза ESXi. Для Hyper-V используйте документацию Microsoft и рекомендации производителя сервера. Для Proxmox VE, Linux и Xen проверяйте документацию конкретной платформы, ядра и драйверов, а также документацию производителя оборудования. Сам факт обнаружения устройства не подтверждает его поддержку в production. Неподтверждённый адаптер может создавать риски при обновлении драйверов, firmware или гипервизора. В кластере дополнительно проверьте совместимость NIC между узлами, виртуальные сети, MTU и требования к сети миграции.

VMware, Hyper-V, Proxmox, KVM и Xen: выбор платформы виртуализации

Сравнивать ESXi, Hyper-V, Proxmox VE, KVM/QEMU/libvirt и Xen как одинаковые продукты нельзя: это гипервизоры, готовые платформы и компоненты разных уровней. Выбор платформы виртуализации определяется требуемым управлением кластером, совместимостью оборудования, лицензиями и подписками, навыками команды, целевым RPO — допустимым периодом потери данных — и RTO — допустимым временем восстановления. Для одного хоста может быть достаточно любой подходящей по драйверам платформы, но миграция, высокая доступность и автоматическое распределение нагрузки требуют отдельной архитектуры.

Сначала сравните решения одного уровня

VMware — бренд и семейство продуктов Broadcom. VMware ESXi — гипервизор, устанавливаемый на сервер. vSphere — платформа вокруг ESXi, а vCenter Server даёт централизованное управление несколькими хостами и является зависимостью для ряда кластерных функций.

Уровень решений в сравнении

Решение	Что это	Управление и кластер	Эксплуатационный смысл
ESXi	Гипервизор VMware	Локальное управление одним хостом; централизованные возможности зависят от vCenter и прав на функции	Подходит как слой исполнения VM, но не равен полной корпоративной платформе
VMware vSphere	Платформа VMware: ESXi, vCenter и функции, доступные в конкретном предложении	Единая плоскость управления, миграция и кластерные функции в рамках совместимой архитектуры	Выбор для организаций, которым нужны экосистема VMware и поддерживаемые корпоративные возможности
Hyper-V	Роль Windows Server с гипервизором	Один хост — Hyper-V Manager, PowerShell или Windows Admin Center; кластер строится с Failover Clustering и выбранными средствами управления	Рационален в Windows-ориентированной среде
Proxmox VE	Готовая Linux-платформа на Debian	Веб-интерфейс, API, кластер, KVM/QEMU для VM и LXC для Linux-контейнеров	Готовая платформа для команды, способной сопровождать Linux и её хранилище, сеть и обновления
KVM / QEMU / libvirt	Собираемый стек Linux-виртуализации	KVM ускоряет выполнение VM, QEMU предоставляет процесс VM и виртуальное оборудование, libvirt даёт API и инструменты управления	Гибкая основа для автоматизации и специализированной архитектуры; кластерную плоскость выбирают и собирают отдельно
Xen Project	Гипервизор Xen	Сам по себе не равен готовой платформе управления	Оценивается как технологическая основа или часть существующей Xen-среды
XenServer и XCP-ng	Отдельные платформы экосистемы Xen	Собственные компоненты управления, обновления, пулы и модели поддержки	Не следует переносить на них лицензирование, репозитории или функции Xen Project без проверки документации конкретного продукта

Зависимость от версии и редакции

Названия предложений VMware, состав подписок и права на функции зависят от действующей продуктовой линейки, редакции и условий договора, а пункты интерфейса — от версии продукта. Совместимость оборудования дополнительно зависит от firmware и драйверов. То же требование проверки версии относится к Windows Server, Proxmox VE, дистрибутивам Linux, QEMU/libvirt и Xen-платформам. Перед закупкой или изменением кластера сверяйте документацию выбранного релиза и официальное руководство производителя оборудования.

Сравнение платформ виртуализации по эксплуатации

Практическая матрица выбора

Критерий	vSphere / ESXi	Hyper-V	Proxmox VE	KVM/QEMU/libvirt	Xen-платформы
Модель управления	vCenter централизует ESXi-хосты; отдельным ESXi можно управлять локально	Windows-инструменты, PowerShell и Windows Admin Center; кластер строится средствами Failover Clustering	Встроенные веб-интерфейс, API и кластерное управление	libvirt, `virsh`, virt-manager, API и выбранные средства автоматизации	Xen Project предоставляет гипервизор и базовые компоненты; XenServer и XCP-ng добавляют управление хостами и пулами
Живая миграция	vMotion зависит от совместимой архитектуры, vCenter и прав на функцию	Live Migration доступна при выполнении требований Windows Server, сети, CPU, аутентификации и хранилища	Поддерживается в документированных сценариях кластера; условия зависят от хранилища и конфигурации	Поддерживается QEMU/libvirt в совместимых конфигурациях, но зависит от версий, CPU, сети и хранилища	XenServer и XCP-ng поддерживают живую миграцию в совместимых пулах; требования зависят от продукта, версии, CPU, сети и хранилища
HA после отказа хоста	vSphere HA перезапускает VM на доступном узле при выполнении требований кластера	Failover Cluster пытается запустить кластерную роль на другом доступном узле	HA Manager пытается перезапустить управляемую VM или контейнер при наличии quorum, доступных дисков и ресурсов	Не появляется автоматически: требуется выбранный кластерный менеджер и проект архитектуры	XenServer и XCP-ng предоставляют HA на уровне пула в поддерживаемых конфигурациях; Xen Project сам по себе готовый HA-кластер не создаёт
Балансировка нагрузки	DRS доступен только при соответствующих правах, компонентах и архитектуре	Failover Clustering может автоматически перераспределять VM между узлами; алгоритмы и степень автоматизации зависят от версии и настроек и не равны DRS	HA-планировщик выбирает узел для запуска или восстановления; автоматическую балансировку нельзя приравнивать к DRS, а её возможности зависят от версии	Реализуется отдельными средствами оркестрации, планирования или автоматизации	Не является универсальной функцией гипервизора Xen: автоматизация размещения и миграции зависит от XenServer, XCP-ng, выбранной плоскости управления и её лицензирования
Репликация VM	VMware vSphere Replication и связанные сценарии восстановления требуют проверки состава предложения, совместимых компонентов и прав; репликация не заменяет резервное копирование	Hyper-V Replica — асинхронная репликация для поддерживаемых сценариев	Встроенная репликация зависит от типа хранилища и документированного сценария Proxmox VE; она не заменяет резервные копии	Определяется выбранным хранилищем, репликацией дисков и средствами управления	Не является общей функцией Xen Project: её реализуют средства конкретной Xen-платформы, управления или хранилища
Типичные компетенции	VMware, сети и хранилища VMware, лицензирование и жизненный цикл подписок	Windows Server, Active Directory, PowerShell и кластеризация Microsoft	Linux, Debian, сеть, хранилища и кластер Proxmox VE	Linux, QEMU, libvirt, сеть, хранилище, IaC и интеграция компонентов	Знание конкретной Xen-платформы, её управления и поддерживаемой архитектуры
Совместимость оборудования	Проверка по Hardware Compatibility List VMware и руководствам производителя	Проверка по документации Microsoft и производителя сервера; кластер — через Validate Configuration	Проверка документации Proxmox VE, ядра Linux и производителя сервера и адаптеров	Проверка поддержки в выбранном дистрибутиве, ядре, QEMU/libvirt и у производителя оборудования	Проверка совместимости конкретного XenServer или XCP-ng, а не только гипервизора Xen

Для VMware актуальные коммерческие предложения обычно рассматривают в контексте VMware vSphere Foundation и VMware Cloud Foundation, однако состав компонентов и прав на использование определяется конкретной подпиской и договором. Не исходите из старых бессрочных лицензий, пробных периодов или прежнего бесплатного ESXi при новой закупке: доступность ESXi без оплаты, обновлений и поддержки менялась. Права на vCenter Server, vMotion, Storage vMotion, HA и DRS нужно сверять по официальному руководству Broadcom для выбранного предложения.

Миграция, HA, репликация и балансировка — не функции одного хоста

Live Migration нужна прежде всего для планового обслуживания: работающая VM перемещается между совместимыми хостами, обычно с короткой паузой на финальном переключении. Она не защищает от повреждения данных, отказа общего хранилища или сбоя сети управления. Storage migration переносит данные VM, а не обязательно её вычислительное состояние; в VMware это отдельная функция Storage vMotion.

Один сервер не становится отказоустойчивым

Одиночный хост остаётся единой точкой отказа для всех его VM независимо от выбранного гипервизора. Для HA обычно нужны несколько совместимых узлов, quorum там, где он требуется, запас вычислительных ресурсов N+1, сети управления и миграции, а также доступное при отказе хоста хранилище. Детали проектирования — в статье «Как спроектировать виртуальную инфраструктуру».

В Windows Server роль Hyper-V поддерживается в актуальных серверных выпусках, включая Windows Server 2019, 2022 и 2025, но перед внедрением нужно сверить жизненный цикл и требования именно выбранного выпуска. Для Hyper-V требуются 64-битный CPU с аппаратной виртуализацией, SLAT и аппаратным DEP/NX; для Failover Clustering требуется валидированная конфигурация и успешная проверка Validate Configuration. Условия Live Migration, Storage Migration и Hyper-V Replica дополнительно зависят от версии Windows Server, аутентификации, сети, типа хранилища и конфигурации хостов. Практические различия этих механизмов разобраны в статье о Live Migration, Replica и HA Hyper-V.

Proxmox VE использует KVM/QEMU для VM и LXC для Linux-контейнеров. Enterprise Repository требует действующей подписки и рекомендуется Proxmox для производственной эксплуатации. No-Subscription Repository доступен без подписки, но его пакеты проходят менее строгую проверку, поэтому этот канал не рекомендуется для производственных систем; отсутствие подписки также не означает отсутствия эксплуатационных расходов. Кластер и HA требуют корректного quorum, сети Corosync, совместимых узлов, доступных дисков VM и резерва ресурсов. Встроенная репликация применима только к документированным сценариям хранения и не равна резервному копированию.

В стеке KVM/QEMU/libvirt возможность миграции не следует выводить из одного наличия KVM. Нужны совместимые версии QEMU и libvirt, сопоставимые CPU-модели и виртуальные устройства, подготовленная сеть миграции и доступ к дискам VM: часто это общее хранилище либо отдельно организованный перенос дисков. Кластерный HA, автоматическое размещение и резервное копирование выбираются как дополнительные компоненты архитектуры. Базовое разделение ролей компонентов и управление одной VM приведены в материале о KVM, QEMU и libvirt.

Стоимость владения: что считать кроме гипервизора

Лицензии и подписки: права на гипервизор, централизованное управление, кластерные функции, поддержку и обновления. Актуальные подписочные предложения VMware рассчитываются по физическим ядрам процессоров; минимумы, состав пакета и права на функции проверяйте по действующему руководству Broadcom и материалу о лицензировании VMware.
Гостевые ОС и приложения: лицензии Windows Server, СУБД, прикладного ПО, VDI или иные условия, зависящие от числа ядер, пользователей, VM либо прав мобильности.
Оборудование: дополнительные хосты для N+1, память и CPU для резерва, совместимые NIC, HBA/RAID-контроллеры, диски, GPU, коммутаторы и каналы.
Хранилище и сеть: общая или распределённая система хранения, производительность, резервирование путей, сегменты управления, миграции и трафика хранилища.
Сопровождение: мониторинг, резервное копирование, тесты восстановления, обновления firmware и платформы, документация, обучение, дежурства и время инженеров.
Миграция: инвентаризация VM, тестовые конверсии, окна простоя, корректировка драйверов и загрузки, проверка лицензий, план отката.

Открытый исходный код или отсутствие стоимости загрузки не означают нулевую стоимость владения. Например, KVM и libvirt могут поставляться дистрибутивом Linux, а Proxmox VE доступен без подписки, но это не создаёт автоматически совместимые драйверы, резервные хосты, корпоративную поддержку, репликацию или круглосуточное сопровождение. Аналогично, коммерческая подписка не заменяет проектирование сети, хранилища и восстановления.

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

Проверка платформы на существующем сервере

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

1
Соберите инвентаризацию
Зафиксируйте модель и поколение сервера, CPU, объём памяти, BIOS/UEFI, BMC, сетевые адаптеры, HBA/RAID-контроллеры, NVMe/SAS/SATA-накопители и GPU. Ожидаемый результат — таблица компонентов с моделями и версиями firmware. Если часть данных неизвестна, получите её из BMC, инвентаризации ОС или документации производителя до выбора релиза.
2
Проверьте CPU и firmware
Убедитесь, что CPU поддерживает аппаратную виртуализацию, а она включена в BIOS/UEFI. Для PCIe passthrough, SR-IOV и GPU дополнительно проверяйте IOMMU. Ожидаемый результат — гипервизор или Linux видит требуемые расширения. Если нет, сверяйте CPU и настройки firmware по инструкции производителя; универсального пути в BIOS/UEFI не существует.
3
Сверьте адаптеры с матрицами
Для VMware проверьте сервер, NIC, контроллеры, накопители и драйверы в официальном HCL для конкретного релиза ESXi. Для Hyper-V используйте документацию Microsoft и рекомендации производителя сервера; для Linux, Proxmox VE и Xen — документацию выбранной платформы, ядра/драйверов и производителя оборудования. Ожидаемый результат — подтверждённые сочетания модели, драйвера и firmware. Если устройство отсутствует в перечне, не считайте его поддерживаемым только потому, что оно обнаружилось при загрузке.
4
Проверьте гостевые нагрузки
Сопоставьте гостевые ОС, загрузочный режим BIOS/UEFI, виртуальные контроллеры, драйверы, требования приложений и лицензии с целевой платформой. Ожидаемый результат — список VM, которые можно перенести стандартным способом, и VM с отдельными рисками. При неизвестной совместимости проведите тест на изолированной копии, а не на единственном рабочем экземпляре.
5
Проверьте условия кластера
Для нескольких хостов сверяйте совместимость CPU, сетевых адаптеров, виртуальных сетей, хранилища, MTU и версий платформы. В Hyper-V выполните Validate Configuration до запуска рабочих VM в кластере. Ожидаемый результат — отсутствуют критические ошибки проверки. При ошибках исправьте архитектуру или исключите неподходящий узел, а не обходите предупреждение.

GPU passthrough, SR-IOV и вложенная виртуализация не являются универсальными свойствами платформы. Передача GPU и SR-IOV зависят от IOMMU, топологии PCIe, конкретного устройства, firmware, драйверов хоста и гостевой ОС, релиза гипервизора и иногда от лицензии. Для вложенной виртуализации важны возможности CPU, передача аппаратных расширений виртуализации гостю и поддержка сочетания внешнего и вложенного гипервизоров. Полная передача GPU обычно исключает его одновременное использование хостом или другой VM; подробная проверка описана в материале о GPU passthrough и nested virtualization.

Выбор платформы по исходной среде

Не «лучшая платформа», а подходящая исходным условиям

Сценарий	Рациональный выбор	Что проверить до решения
Один хост для разработки, теста или некритичной нагрузки	Любая платформа с подтверждённой поддержкой оборудования и достаточными навыками команды: Hyper-V, Proxmox VE, ESXi, KVM/libvirt или Xen-платформа	План резервного копирования и восстановления, поддержка NIC и storage, гостевые лицензии; HA здесь не появится сама
Небольшой кластер с централизованным управлением	vSphere при наличии подходящей подписки и экосистемы VMware; Proxmox VE для Linux-команды; Hyper-V с Failover Clustering для Windows-среды	N+1-ёмкость, quorum, совместимость хостов, хранилище, сеть миграции и стоимость сопровождения
Инфраструктура Windows Server и команда Microsoft	Hyper-V вместе с Windows Server, Failover Clustering и выбранными средствами управления	Права Windows Server для VM, SLAT, валидированный кластер, Active Directory и требования Replica
Linux-команда с потребностью в готовой панели	Proxmox VE	Компетенции Debian/Linux, репозитории и обновления, Corosync, сеть и модель хранения; LXC применять только для подходящих Linux-нагрузок
Linux-команда, которой нужны API, автоматизация и собственная архитектура	KVM/QEMU/libvirt	Кто отвечает за кластер, HA, сеть, хранение, образы, мониторинг и резервное копирование; для частного облака отдельно оценить OpenStack
Требования к экосистеме VMware или действующая VMware-инфраструктура	vSphere с ESXi и vCenter в составе, который подтверждён подпиской	Поддерживаемость серверов, стоимость подписки, права на нужные функции и план совместимости при обновлении
Уже работающая Xen/XenServer/XCP-ng-среда	Сначала оценить продолжение на текущей Xen-платформе	Конкретный продукт, состояние поддержки, пулы, хранилище, инструменты управления и риски V2V

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

Когда миграцию нельзя начинать без отдельного проекта

Не начинайте V2V «по месту»

Отдельный проект совместимости и переноса нужен, если меняются одновременно гипервизор, формат виртуальных дисков, BIOS/UEFI, виртуальные контроллеры, сеть, хранилище или версия гостевой ОС; если VM использует GPU passthrough, SR-IOV, USB/PCIe-устройства, шифрование либо специализированные драйверы; если есть кластерные приложения, СУБД, лицензии с привязкой к оборудованию или жёсткие RPO/RTO. Конвертация диска не гарантирует загрузку ОС, работу драйверов и приложения, сохранение сетевой идентичности или целостность данных.

Инвентаризируйте хосты, VM, гостевые ОС, драйверы, виртуальные устройства, лицензии, зависимости приложений и точки восстановления.
Определите допустимые простой, RPO и RTO, критерии успешности, окно работ и условия отката.
Проверьте перенос на изолированной копии VM: загрузку, сеть, диски, гостевые инструменты, службу приложения и резервное копирование.
Подготовьте целевую платформу, сеть, хранилище, доступы и мониторинг до остановки рабочей VM.
Выполняйте переключение по согласованному плану; исходную и перенесённую системы не подключайте одновременно к рабочей сети без контроля идентичности и актуальности данных.

Порядок и риски P2V/V2V, холодного переноса и живой миграции разобраны в статье «Миграция виртуальных машин: live migration, V2V и P2V». Установка отдельных платформ вынесена в материалы по ESXi, Hyper-V, Proxmox VE и KVM/QEMU/libvirt.

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

Аппаратная виртуализация: Аппаратная виртуализация — способ запуска ВМ с поддержкой процессора и платформы, где привилегированные операции гостя обрабатываются специальными механизмами CPU, а не только программной эмуляцией.
Бессрочная лицензия: Бессрочная лицензия — право использовать приобретённую версию ПО без фиксированного срока, обычно без автоматического включения обновлений и поддержки.
Виртуальная сеть: Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Дистрибутив Linux: Дистрибутив Linux — готовая операционная система на базе ядра Linux, включающая набор программ, репозитории, пакетный менеджер и правила обновления и сопровождения.
Роль Hyper-V: Роль Hyper-V — серверная роль Windows Server, устанавливающая гипервизор и компоненты для создания, запуска и управления виртуальными машинами на узле.
GPU Passthrough: Режим назначения физического GPU виртуальной машине через PCIe/IOMMU, при котором гостевая ОС обращается к устройству напрямую с минимальными накладными расходами.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hardware Compatibility List: Hardware Compatibility List — перечень проверенных сочетаний оборудования и ПО, определяющий конфигурации, поддерживаемые для заданной платформы или продукта.
HBA: HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
Hyper-V Replica: Встроенный механизм Hyper-V для асинхронного поддержания копии виртуальной машины на другом хосте или кластере с целью аварийного восстановления.
IOMMU: IOMMU — аппаратный блок, который преобразует адреса DMA-запросов устройств в адреса физической памяти и ограничивает их доступ; нужен для изоляции и прямого назначения PCIe-устройств ВМ.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
Live Migration: Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соединений зависит от сети и платформы.
LXC: LXC — набор инструментов и библиотек для создания и запуска системных Linux-контейнеров, изолирующих процессы, сеть и файловую систему при общем ядре с хостом.
NVMe: NVMe — протокол обмена командами с энергонезависимыми накопителями, оптимизированный для параллельного ввода-вывода; локальные NVMe-SSD обычно подключаются по PCIe.
P2V: P2V — перенос установленной ОС, приложений и данных с физического сервера в виртуальную машину с адаптацией системы к виртуальному оборудованию.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
SAS: SAS — последовательный интерфейс и набор протоколов SCSI для подключения накопителей, поддерживающий адресацию устройств, экспандеры и обычно двухпортовое подключение дисков.
SLAT: SLAT — аппаратная двухуровневая трансляция адресов памяти, при которой процессор преобразует адреса гостевой ВМ в физические адреса хоста без постоянного участия гипервизора.
Storage Migration: Storage Migration — механизм Hyper-V для переноса файлов работающей виртуальной машины между хранилищами без смены хоста, на котором она выполняется.
Storage vMotion: Функция VMware vSphere для переноса файлов и виртуальных дисков работающей виртуальной машины между датасторами без её выключения.
V2V: V2V — перенос существующей виртуальной машины с одной платформы виртуализации на другую с преобразованием дисков и конфигурации под целевой гипервизор.
vCenter Server: Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
VDI: VDI — архитектура, в которой пользовательские рабочие столы выполняются в виртуальных машинах на централизованной инфраструктуре, а пользователи подключаются к ним удалённо.
vMotion: Технология VMware vSphere для переноса включённой виртуальной машины между хостами ESXi без выключения гостевой ОС; при переключении возможна краткая пауза.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware Cloud Foundation: VMware Cloud Foundation — интегрированная платформа VMware для частного облака, объединяющая виртуализацию, программно-определяемые хранилище и сеть, а также централизованное управление.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
VMware vSphere Foundation: VMware vSphere Foundation (VVF) — подписочный пакет линейки VMware от Broadcom на базе vSphere, дополненный средствами мониторинга и эксплуатации инфраструктуры.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры
XCP-ng: XCP-ng — дистрибутив платформы серверной виртуализации на базе гипервизора Xen Project и стека XAPI. Серверы с XCP-ng объединяют в пулы для запуска и миграции виртуальных машин.
Xen: Xen — гипервизор первого типа, работающий непосредственно на сервере и поддерживающий режимы виртуализации HVM, PV и PVH.
XenServer: XenServer — платформа серверной виртуализации на базе гипервизора Xen типа 1 для запуска и управления виртуальными машинами на физических серверах.