Привет!
KVM (Kernel-based Virtual Machine) — это компонент ядра Linux, который обеспечивает аппаратную виртуализацию процессора и памяти. Это не готовая платформа управления уровня Proxmox VE или VMware vSphere: для запуска и администрирования виртуальных машин KVM обычно используют вместе с QEMU, libvirt и дополнительными интерфейсами управления.
И не путайте KVM с другой одноимённой аббревиатурой — Keyboard, Video, Mouse. Ею описывают консоли и переключатели для удалённого управления серверным оборудованием.
Эта статья входит в цикл подробных обзоров популярных технологий виртуализации:
-
Обзор гипервизора Proxmox — чек ☑.
-
Обзор гипервизора VMware ESXi/ESX — чек ☑.
-
Обзор гипервизора Microsoft Hyper-V — чек ☑.
-
Обзор гипервизора KVM — вы находитесь здесь.
Предупреждаю, что перед вами лонгрид: большой, длинный и необрезанный :) Если не осилите за раз, добавляйте статью в закладки — Ctrl+D.
Что такое KVM: про гипервизор
Гипервизор 1-го типа.
Гипервизор 2-го типа.
KVM — это подсистема ядра Linux, которая использует аппаратные расширения процессоров Intel VT-x, AMD-V и аналогичные механизмы на других архитектурах. После загрузки модулей KVM ядро Linux получает функции гипервизора: оно выполняет гостевой код на физических процессорных ядрах, управляет виртуальными процессорами и памятью, а также изолирует виртуальные машины друг от друга.
KVM часто относят к гипервизорам первого типа. Такая классификация допустима, потому что виртуализация выполняется непосредственно в ядре Linux, работающем на физическом оборудовании. Однако KVM нельзя рассматривать отдельно от хостовой ОС: Linux одновременно остаётся операционной системой общего назначения, отвечает за планировщик, память, драйверы, сеть, хранилище и безопасность.
Типичная структура выглядит так:
Физический сервер → Linux с KVM → QEMU → виртуальные машины → гостевые операционные системы.
Сам KVM не предоставляет полноценный web-интерфейс, централизованное управление кластером, резервное копирование или автоматический перезапуск ВМ после отказа узла. Эти функции добавляют libvirt и платформы управления: Proxmox VE, OpenStack, OpenShift Virtualization, OpenNebula и другие.
Ремарка! Код KVM входит в ядро Linux и распространяется по открытой лицензии GPLv2. Но «открытый» не всегда означает «инфраструктура ничего не стоит»: отдельно оплачиваются оборудование, работа администраторов, поддержка дистрибутива, резервное копирование и лицензии гостевых систем, например Windows Server.
Теперь кратко про концепцию гипервизора. Гипервизор позволяет запускать несколько программных серверов на одном физическом. На виртуальные машины можно устанавливать разные операционные системы и приложения — например, Linux и Windows одновременно. Каждая ВМ получает собственные виртуальные процессоры, память, накопители и сетевые интерфейсы.
Важно! Виртуальные машины изолированы друг от друга, но эта изоляция не абсолютна. Ошибка внутри одной гостевой ОС обычно не останавливает соседние ВМ, однако сбой хоста, уязвимость гипервизора, переполнение общего хранилища или перегрузка физических ресурсов способны затронуть сразу несколько систем. Поэтому виртуализация не заменяет резервирование, мониторинг и резервное копирование.
Простая аналогия из жизни. Представьте отель: физический сервер — здание, виртуальные машины — номера, а гипервизор распределяет ресурсы между постояльцами. При этом в случае KVM работу менеджера выполняет не один продукт. Ядро Linux распределяет процессорное время и память, QEMU создаёт виртуальное оборудование, а libvirt или другая платформа помогает администратору управлять всей конструкцией.
Если всё сделать по уму, виртуализация упрощает администрирование, ускоряет развёртывание новых систем и помогает эффективнее использовать сервер. Но надёжность, RTO и RPO зависят не от одного KVM, а от архитектуры кластера, хранилища, сети и резервного копирования.
Как использовать KVM: инструменты для управления
«Чистый» KVM без QEMU и инструментов управления почти не используют. Он является фундаментом, поверх которого можно построить как небольшой одиночный хост, так и крупное облако.
Инструменты и платформы отличаются уровнем абстракции:
-
libvirt и virsh. Libvirt предоставляет API и службы для управления ВМ, виртуальными сетями и хранилищами. Virsh — его основной консольный клиент. Такой вариант подходит администраторам, которым нужен прямой контроль и автоматизация с помощью скриптов или систем управления конфигурациями.
-
virt-manager. Графический интерфейс для управления локальными и удалёнными хостами через libvirt. Удобен для рабочих станций, лабораторий и небольших инсталляций.
-
Cockpit Machines. Web-интерфейс для базового управления виртуальными машинами на Linux-сервере. Он проще полноценной кластерной платформы и подходит для одиночных узлов или небольших сред.
-
Proxmox Virtual Environment. Готовая платформа на базе Debian, объединяющая KVM для виртуальных машин и LXC для контейнеров. В неё входят web-интерфейс, кластерное управление, резервное копирование, программно-определяемые сеть и хранилище, а также механизмы высокой доступности. Подробности есть в нашем обзоре Proxmox VE.
-
OpenStack. Облачная платформа для управления вычислительными, сетевыми и дисковыми ресурсами. Служба Nova часто запускает ВМ через libvirt и KVM, но сам OpenStack намного шире гипервизора и требует отдельного проектирования всей облачной инфраструктуры.
-
OpenShift Virtualization. Позволяет запускать виртуальные машины рядом с контейнерными нагрузками в кластере OpenShift. Решение основано на KubeVirt и использует аппаратную виртуализацию KVM на рабочих узлах.
-
OpenNebula. Платформа для частных, гибридных и периферийных облаков. Она управляет вычислительными узлами, сетями и хранилищами, в том числе в инфраструктурах на базе KVM.
-
oVirt. Открытая платформа централизованного управления KVM-инфраструктурой. Коммерческий продукт Red Hat Enterprise Virtualization (RHEV), связанный с oVirt, снят с развития, но сообщество oVirt продолжает работу: в январе 2026 года вышла версия 4.5.7. При новом внедрении всё же стоит отдельно оценить темп разработки, доступность специалистов и долгосрочную поддержку.
-
Linux-сервер с собственным стеком. KVM можно развернуть на Ubuntu Server, Debian, Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, AlmaLinux, SUSE Linux Enterprise Server и других дистрибутивах. В этом случае состав и правила поддержки стека определяются выбранным дистрибутивом.
Nutanix AHV также использует технологии KVM, но является частью коммерческой платформы Nutanix. Это не внешний интерфейс управления обычным KVM-хостом, а самостоятельный интегрированный продукт.
Получается, что вопрос «как управлять KVM» правильнее формулировать так: какой стек управления выбрать поверх KVM. Для одного хоста может хватить libvirt и Cockpit, для небольшого кластера часто рассматривают Proxmox VE, а для облачной или контейнерной инфраструктуры — OpenStack либо OpenShift Virtualization.
Что входит в KVM
KVM часто называют самостоятельным гипервизором, но рабочая система виртуализации состоит из нескольких компонентов.
-
Модули ядра KVM. Общий модуль kvm и архитектурные модули, например kvm_intel или kvm_amd, предоставляют интерфейс /dev/kvm. Через него пользовательский процесс создаёт виртуальные процессоры, адресное пространство ВМ и выполняет гостевой код с использованием аппаратной виртуализации.
-
QEMU. Обычно каждая виртуальная машина представлена отдельным процессом QEMU. KVM ускоряет выполнение гостевого кода и виртуализацию памяти, а QEMU создаёт модель машины: чипсет, контроллеры, диски, сетевые карты, графику, USB-устройства и другие компоненты. Без KVM QEMU способен полностью эмулировать процессор, включая другую архитектуру, но такая эмуляция обычно заметно медленнее аппаратной виртуализации.
-
Libvirt. Набор API, служб и инструментов управления. Libvirt хранит конфигурации ВМ, запускает QEMU, управляет сетями и пулами хранения, назначает права доступа, собирает статистику и координирует миграцию. Virsh — командный клиент libvirt.
-
Гостевая операционная система. Linux, Windows, BSD или другая ОС, работающая внутри виртуальной машины. Гость видит набор виртуальных либо проброшенных физических устройств.
-
VirtIO. Стандарт паравиртуализированных устройств ввода-вывода. Вместо точной эмуляции старого физического контроллера гостевая ОС использует оптимизированный интерфейс, например virtio-net, virtio-blk, virtio-scsi, virtio-gpu или virtio-balloon.
-
Инструменты управления. Virt-manager, Cockpit Machines, Proxmox VE, OpenStack и другие платформы не входят в KVM, а используют его возможности через QEMU, libvirt или собственные компоненты.
По состоянию на август 2026 года основной веткой Linux является ядро 7.2, актуальным выпуском QEMU — 11.1.0, а libvirt — 12.6.0. Но ставить самые свежие версии вручную на производственный сервер не всегда разумно. Корпоративные дистрибутивы могут использовать более старое ядро и делать обратный перенос исправлений безопасности. Для production важнее поддерживаемая и протестированная связка ядра, QEMU, libvirt, прошивки UEFI и инструментов управления.
Паравиртуализация. Современная паравиртуализация KVM связана прежде всего с VirtIO. Большинство актуальных Linux-гостей уже содержат VirtIO-драйверы в ядре, поэтому вручную модифицировать гостевую ОС обычно не требуется. Для Windows устанавливают подписанный пакет VirtIO-драйверов: он добавляет поддержку сетевых, дисковых, balloon- и других паравиртуализированных устройств.
Эмулируемые устройства могут быть полезны для совместимости при установке старой ОС, но для постоянной работы обычно выбирают VirtIO. Например, виртуальный адаптер virtio-net создаёт меньше накладных расходов, чем эмуляция устаревшей сетевой карты, а virtio-scsi удобен для дисков, TRIM/UNMAP и подключения нескольких устройств.
Архитектура драйвера KVM PV.
Live Migration. KVM/QEMU поддерживает перенос работающей виртуальной машины, а libvirt предоставляет интерфейсы для управления процессом. Однако мигрировать «любую ВМ» на «любой хост» нельзя.
Для переноса нужны совместимые модели CPU и наборы процессорных инструкций, доступ к тем же виртуальным сетям, совместимые версии QEMU и типы виртуальной машины. Диски должны находиться в общем хранилище либо копироваться во время миграции. Проброшенные через VFIO или SR-IOV устройства, локальные ресурсы и отдельные функции confidential computing могут ограничить или полностью исключить live migration. В документации libvirt миграция неслучайно описывается как отдельная сложная задача, а не как безусловная функция одной кнопки.
от 333 500 ₽
11 589 ₽/мес в лизинг
от 273 361 ₽
+ 60 139 НДС
от 128 268 ₽
4 457 ₽/мес в лизинг
от 105 138 ₽
+ 23 130 НДС
Серверы KVM
Специальных «серверов KVM» как отдельного класса оборудования не существует. KVM можно запустить на большинстве современных серверов с поддерживаемым Linux-дистрибутивом и аппаратной виртуализацией. А вот конфигурация зависит от того, какие ВМ и приложения будут работать внутри.
Для универсального хоста виртуализации важны:
-
достаточное количество процессорных ядер и подходящая производительность одного ядра;
-
объём памяти с учётом всех ВМ, хоста и резерва под отказ узла;
-
равномерное заполнение каналов памяти;
-
накопители с достаточными IOPS, задержкой и ресурсом перезаписи;
-
резервирование загрузочных дисков, блоков питания и сетевых подключений;
-
контроллеры и сетевые адаптеры с поддерживаемыми Linux-драйверами;
-
Intel VT-d или AMD-Vi/IOMMU, если нужен проброс устройств;
-
аппаратный TPM 2.0 и совместимая UEFI-прошивка, если планируются защищённая загрузка и доверенная инфраструктура.
Для небольшого офиса может быть достаточно одного сервера с локальными SSD и резервным копированием на отдельное устройство. Для production-кластера потребуются как минимум несколько узлов, отдельная сеть управления и миграции, общее или распределённое хранилище и расчёт поведения инфраструктуры при отказе одного сервера.
При выборе оборудования отталкивайтесь не от самого KVM, а от профиля нагрузки: баз данных, VDI, web-сервисов, систем разработки, сетевых функций или высокопроизводительных вычислений.
Минимальные системные требования KVM
У KVM нет универсальных минимальных требований вроде «2 ГБ памяти и 6 ГБ на диске». Такие цифры относятся к конкретному дистрибутиву, установщику или платформе управления, но ничего не говорят о реальной нагрузке.
Для x86-сервера процессор должен поддерживать аппаратную виртуализацию Intel VT-x или AMD-V, а соответствующая функция должна быть включена в BIOS/UEFI. Для проброса PCIe-устройств понадобятся IOMMU и поддержка Intel VT-d либо AMD-Vi. Кроме x86-64, KVM работает на Arm, IBM POWER, IBM Z и других архитектурах, но доступные функции и список поддерживаемых гостевых систем различаются.
Процессорные ресурсы рассчитывают через соотношение виртуальных и физических ядер — vCPU:pCPU. Единого правильного коэффициента нет. Допустимый overcommit зависит от характера нагрузки, пиков потребления, требований к задержкам и запаса на отказ одного узла. Сервер с десятками редко активных тестовых ВМ можно загрузить плотнее, чем хост с базами данных, системами реального времени или VDI.
Контролировать нужно не только среднюю загрузку CPU, но и очереди планировщика, CPU steal time, задержки и одновременные пики. Для чувствительных к задержкам систем применяют CPU pinning, изоляцию ядер и отказ от агрессивного overcommit.
Память рассчитывается как сумма активной памяти всех гостевых систем, расходов QEMU и хоста, кешей и эксплуатационного резерва. Ballooning и KSM помогают повысить плотность размещения, но не создают физическую память из воздуха. Постоянный swap на хосте виртуализации способен резко увеличить задержки, поэтому его нельзя считать штатным способом компенсации нехватки ОЗУ.
Для NUMA-серверов важно размещать виртуальные процессоры, память и устройства ВМ в пределах подходящих NUMA-узлов. Если крупная ВМ постоянно обращается к памяти соседнего сокета, задержки увеличиваются, даже если общий объём ресурсов выглядит достаточным.
Hugepages могут уменьшить нагрузку на TLB и повысить предсказуемость производительности крупных ВМ. Обратная сторона — память нужно резервировать и аккуратно распределять, а операции ballooning и миграции могут стать сложнее.
Требования к хранилищу определяются не только объёмом виртуальных дисков. Нужно учитывать IOPS, задержку, соотношение чтения и записи, thin provisioning, снапшоты, резервное копирование и восстановление после отказа. Для баз данных и VDI быстрый SSD или NVMe-массив часто важнее дополнительного количества процессорных ядер.
Сеть рассчитывают по клиентскому трафику, хранилищу, резервному копированию и миграции ВМ. Универсальная рекомендация «достаточно 1 Гбит/с» устарела: для небольшого одиночного хоста этого может хватить, но в кластерах обычно разделяют управляющий, пользовательский, дисковый и миграционный трафик и используют более быстрые интерфейсы.
Запас ресурсов также нельзя всегда выражать фиксированными 15–20%. Для одиночного сервера резерв выбирают по пиковым нагрузкам. В HA-кластере дополнительно проверяют, смогут ли оставшиеся узлы принять ВМ после отказа одного сервера — модель N+1 или более строгую, если этого требует бизнес.
Важно! Из общих рекомендаций остаются актуальными серверные накопители, RAID или программно-определяемая защита данных, резервные блоки питания и сетевые подключения, мониторинг и схема резервного копирования 3-2-1. Важно помнить: RAID и кластер высокой доступности не заменяют резервные копии.
Ключевые возможности и конкурентные преимущества KVM
-
KVM — открытый код и отсутствие отдельной лицензии на сам гипервизор. Пользователь может изучать код, собирать собственное ядро, автоматизировать управление и выбирать поставщика поддержки. Но стоимость инфраструктуры всё равно включает Linux-дистрибутив, платформу управления, работу специалистов и лицензии гостевых приложений.
-
Развитая экосистема. KVM применяется на одиночных серверах, в корпоративных кластерах, публичных облаках и контейнерных платформах. Он не привязывает администратора к одному интерфейсу или одной системе хранения.
-
Тесная интеграция с Linux. KVM использует планировщик, подсистему памяти, cgroups, сетевой стек, драйверы, SELinux или AppArmor и другие механизмы ядра. Поддержка нового оборудования обычно появляется вместе с развитием Linux, QEMU и прошивок.
Дальше кратко по ключевым возможностям.
Хранилище. QEMU и libvirt могут работать с локальными файлами и блочными устройствами, LVM, NFS, iSCSI, Fibre Channel, Ceph RBD и другими технологиями, поддерживаемыми выбранным стеком. Виртуальные диски используют форматы raw, qcow2 и другие. Доступны thin provisioning, снапшоты и копирование дисков, но конкретные возможности зависят от формата и системы хранения.
Общее хранилище упрощает миграцию между узлами, однако само по себе не гарантирует высокую доступность. Нужно резервировать контроллеры, сеть, диски и метаданные, а также отдельно проверять восстановление ВМ.
Аппаратное обеспечение. KVM работает на большом количестве серверных платформ. В production лучше использовать оборудование, для которого выбранный дистрибутив подтверждает поддержку процессоров, сетевых карт, RAID/HBA, NVMe и средств удалённого управления.
Процессор и NUMA. Администратор может задавать топологию виртуального CPU, модель процессора, лимиты и приоритеты, привязывать vCPU к физическим ядрам и размещать память по NUMA-узлам. Эти настройки полезны для баз данных, телеком-нагрузок и систем с предсказуемой задержкой, но требуют измерений: неверный pinning способен снизить производительность.
Память. KVM поддерживает NUMA, hugepages, memory ballooning, KSM и hot plug памяти. KSM объединяет одинаковые страницы, но расходует процессорное время и подходит не для каждой модели безопасности. Hugepages уменьшают накладные расходы на трансляцию адресов, зато требуют планирования и резервирования памяти.
VirtIO. Паравиртуализированные устройства уменьшают расходы на эмуляцию и обычно используются для дисков, сети, графики, ballooning и каналов связи с гостевой ОС. Для Windows драйверы устанавливаются отдельно; в современных Linux-дистрибутивах они, как правило, уже присутствуют.
SR-IOV и VFIO. VFIO позволяет передать ВМ физическое PCIe-устройство или его виртуальную функцию SR-IOV. Это полезно для высокопроизводительных сетевых карт, GPU, NVMe и ускорителей. Производительность и задержки приближаются к работе на физическом сервере, но гибкость снижается: снапшоты, миграция и HA могут оказаться недоступны или потребовать специального оборудования.
Миграция. Возможны перенос выключенной ВМ, live migration с общим хранилищем и миграция с копированием дисков. Успех зависит от совместимости процессоров, моделей виртуальной машины, сети, накопителей и подключённых устройств. Для кластера желательно заранее определить общий baseline CPU, а не назначать всем гостям host-passthrough без проверки маршрутов миграции.
Безопасность. KVM использует механизмы Linux: права доступа, namespaces, cgroups, seccomp, SELinux или AppArmor. В связке libvirt и SELinux применяется sVirt, который назначает процессам QEMU и файлам ВМ отдельные метки безопасности.
Дополнительно можно использовать UEFI Secure Boot и виртуальный TPM. Secure Boot проверяет подписи компонентов загрузки гостевой ОС, а vTPM нужен, например, для BitLocker и современных версий Windows. Сам vTPM не защищает инфраструктуру автоматически: его состояние и ключи тоже нужно безопасно хранить и включать в резервное копирование.
Confidential computing. На совместимых серверах KVM может использовать AMD SEV, SEV-ES, SEV-SNP и Intel TDX для шифрования памяти и дополнительной защиты гостя от хоста. Нужна поддержка на всех уровнях: CPU, BIOS/UEFI, ядро, KVM, QEMU, libvirt и гостевая ОС. Доступность функций зависит от дистрибутива, а миграция, резервное копирование и проброс устройств могут иметь ограничения.
Гостевые системы. На KVM запускают Linux, Windows, BSD и другие операционные системы. Но корректнее проверять совместимость не «с KVM вообще», а с конкретной комбинацией дистрибутива хоста, QEMU, типа виртуальной машины, прошивки и драйверов.
Управление сторонними инструментами. KVM можно превратить в небольшую локальную среду или основу облака. Возможности HA, автоматического распределения ВМ, резервного копирования, ролей пользователей и аудита определяются уже выбранной платформой управления.
Сценарии использования KVM
Перечислю основные сценарии использования KVM в реальной инфраструктуре.
-
Виртуализация серверов. Несколько гостевых ОС запускаются на одном физическом узле или кластере. Это помогает эффективнее использовать процессор, память и хранилище.
-
Консолидация. Отдельные физические серверы с невысокой загрузкой переносятся в ВМ. Но при консолидации нужно учитывать домены отказа: если сложить все критичные системы на один хост, поломка этого сервера остановит их одновременно.
-
Тестирование и разработка. ВМ позволяют быстро создавать изолированные среды с разными версиями ОС, библиотек и приложений, делать снапшоты и возвращаться к предыдущему состоянию.
-
Частные и публичные облака. KVM используется как вычислительная основа OpenStack, OpenNebula и других облачных платформ. Пользователь получает виртуальные серверы через портал или API, а не взаимодействует с KVM напрямую.
-
Виртуализация рабочих мест. KVM может быть вычислительным слоем VDI, но для полноценного решения дополнительно нужны брокер подключений, протокол удалённого доступа, управление образами, профилями и пользовательскими сессиями.
-
Контейнерные платформы. OpenShift Virtualization и KubeVirt позволяют запускать ВМ рядом с контейнерами, сохраняя привычные операционные системы для приложений, которые ещё не перенесены в контейнеры.
-
Сетевые функции и телеком. CPU pinning, hugepages, NUMA и SR-IOV позволяют использовать KVM для NFV и других нагрузок, чувствительных к задержкам.
-
Обучение. KVM подходит для лабораторий, курсов Linux и практики администрирования. Для первого знакомства можно использовать virt-manager или Cockpit Machines, не разворачивая облачную платформу.
Важно! Учтите, что малому бизнесу виртуализация нужна не всегда. KVM не требует отдельной лицензии, но добавляет новый программный слой и требует компетенций в Linux, сетях, хранилищах, мониторинге и резервном копировании. Иногда один физический сервер проще и надёжнее плохо спроектированного кластера.
Плюсы и минусы KVM: таблица
|
Плюсы |
Минусы |
|
Открытый код и отсутствие отдельной лицензии на KVM |
Нет единого готового продукта: нужно выбрать дистрибутив, QEMU, libvirt и средства управления |
|
Аппаратная виртуализация и сравнительно небольшие накладные расходы при правильной настройке |
Результат сильно зависит от квалификации администратора и согласованности компонентов |
|
Развитая экосистема: от virt-manager до Proxmox VE, OpenStack и OpenShift Virtualization |
Обновление самосборного стека требует проверки совместимости ядра, QEMU, libvirt и прошивок |
|
Широкая поддержка Linux, Windows и других гостевых ОС |
Коммерческая поддержка зависит от выбранного дистрибутива или платформы |
|
Поддержка VirtIO, NUMA, hugepages, CPU pinning, VFIO и SR-IOV |
Продвинутые оптимизации усложняют миграцию и эксплуатацию |
|
Возможность построить одиночный хост, кластер или облако |
HA, резервное копирование и автоматическая балансировка не являются функциями одного KVM |
|
Интеграция с механизмами безопасности Linux, Secure Boot и vTPM |
Безопасность требует настройки всего стека, а не только установки KVM |
Сравнение KVM с другими гипервизорами
Ниже я кратко сравню KVM с Hyper-V, VMware ESX и Proxmox VE. Но сначала важное уточнение: здесь сталкиваются сущности разных уровней.
Важно! KVM — компонент ядра Linux. Hyper-V и VMware ESX — гипервизоры, тесно связанные с коммерческими экосистемами управления. Proxmox VE — готовая платформа, внутри которой уже используется KVM.
И ещё одна ремарка: лицензируемые гостевые системы не становятся бесплатными из-за выбора открытого гипервизора. Если внутри KVM запускается Windows Server, права на его использование всё равно требуют корректного лицензирования.
KVM vs Microsoft Hyper-V
Подробный обзор Microsoft Hyper-V читайте в отдельной статье. Здесь кратко.
Hyper-V — гипервизор первого типа, встроенный в Windows Server. В актуальной инфраструктуре его обычно разворачивают как роль Windows Server 2025 и управляют через PowerShell, Hyper-V Manager, Windows Admin Center или System Center Virtual Machine Manager.
Отдельный бесплатный Microsoft Hyper-V Server закончился на версии 2019. Его основная поддержка завершилась в январе 2024 года, расширенная действует до января 2029 года — это подтверждает Microsoft Lifecycle. Отдельного Hyper-V Server 2022 или 2025 Microsoft не выпускала.
KVM удобен там, где основой инфраструктуры является Linux, нужны открытые API и свобода выбора платформы управления. Hyper-V логичнее вписывается в среду Microsoft с Windows Server, Active Directory, PowerShell, Failover Clustering и System Center.
Live migration и высокая доступность есть в обеих экосистемах, но реализуются по-разному. У Hyper-V это функции Windows Server и Failover Clustering. В KVM-инфраструктуре их предоставляет libvirt или выбранная платформа — например, Proxmox VE, OpenStack либо OpenNebula.
Сравнивать цену только по стоимости гипервизора неправильно. Для KVM нужно учитывать поддержку Linux и платформы управления, а для Hyper-V — лицензирование физических ядер Windows Server и права на запуск гостевых экземпляров Windows. Итог зависит от количества Windows-ВМ, редакции Windows Server и уже купленных лицензий.
KVM vs ESXi
Чтобы подробнее погрузиться в тему, читайте наш обзор VMware ESXi/ESX.
VMware ESX — коммерческий гипервизор первого типа и часть экосистемы VMware vSphere и VMware Cloud Foundation. В линейке 8.x продолжает использоваться название ESXi, а в коммерческой ветке 9.x Broadcom вернула название ESX. На август 2026 года актуальна версия ESX 9.1.
В сравнении с KVM VMware предлагает более цельный продукт: централизованное управление, миграцию, распределённые коммутаторы, интеграцию с хранилищами, автоматизацию и эксплуатационные инструменты в рамках одной экосистемы. Обратная сторона — коммерческое лицензирование, зависимость от продуктовой политики поставщика и ограничения совместимости оборудования.
KVM даёт больше свободы. Можно выбрать дистрибутив, систему управления, сеть и хранилище, а при необходимости изменить любой слой. Однако за эту свободу приходится платить временем специалистов: совместимость и поддержку компонентов нужно обеспечивать самостоятельно либо передавать поставщику Linux или платформы.
По производительности нельзя заранее объявить победителя. Результат зависит от версии стека, драйверов, модели виртуального CPU, NUMA, хранилища, сети и конкретной нагрузки. Сравнивать нужно на одинаковом сервере и с одинаковыми настройками ВМ.
VMware разумно рассматривать, когда компания уже использует vSphere/VCF, нуждается в едином коммерческом контуре поддержки и готова работать в рамках его лицензирования. KVM подходит, если важны открытая архитектура, автоматизация, Linux-экосистема и возможность выбирать платформу управления.
KVM vs Proxmox VE
Важно! Здесь сравнение условное. KVM — компонент виртуализации, а Proxmox VE — готовая платформа, которая сама использует KVM для запуска ВМ и LXC для контейнеров. Это примерно как сравнивать двигатель и автомобиль.
Proxmox VE нельзя относить к гипервизорам второго типа только потому, что он основан на Debian. Платформа устанавливается непосредственно на физический сервер или поверх поддерживаемого Debian, а виртуальные машины запускаются через KVM с аппаратной виртуализацией. Корректнее вообще не присваивать всей платформе тип гипервизора: тип относится к KVM внутри неё.
Если выбрать обычный Linux с KVM, QEMU и libvirt, администратор сам решает, как организовать сеть, хранилище, резервное копирование, кластер и интерфейсы управления. Это даёт гибкость, но увеличивает объём проектирования и сопровождения.
Proxmox VE заранее объединяет эти компоненты, предоставляет web-интерфейс, API, кластерное управление, миграцию, HA, интеграцию с ZFS и Ceph, а также собственную экосистему резервного копирования. Исходный код доступен, платформой можно пользоваться без подписки, но платные подписки предоставляют доступ к enterprise-репозиторию и коммерческой поддержке.
Чистый стек KVM/libvirt подходит для специализированных систем, собственной автоматизации и инфраструктур, где готовая платформа создаёт лишние ограничения. Proxmox VE удобнее, когда нужен быстро разворачиваемый кластер с единым интерфейсом и предсказуемым набором функций.
Общее сравнение гипервизоров KVM, Hyper-V, ESXi и Proxmox VE
|
Характеристика |
KVM |
VMware ESX |
Microsoft Hyper-V |
Proxmox VE |
|
Что это |
Компонент ядра Linux |
Коммерческий гипервизор первого типа |
Гипервизор первого типа и роль Windows Server |
Платформа управления с KVM и LXC |
|
Основная среда |
Linux |
vSphere и VMware Cloud Foundation |
Windows Server и экосистема Microsoft |
Debian-based платформа Proxmox |
|
Управление |
libvirt, virsh, virt-manager, Cockpit или внешняя платформа |
vSphere Client, vCenter и компоненты VCF |
PowerShell, Hyper-V Manager, Windows Admin Center, SCVMM |
Web-интерфейс, CLI и API Proxmox |
|
Лицензирование |
KVM входит в Linux; поддержка зависит от дистрибутива |
Коммерческие подписки и права на продукты VMware |
Hyper-V входит в Windows Server; лицензируются ядра и гостевые права |
Открытый код; подписка на поддержку и enterprise-репозиторий оплачивается отдельно |
|
Live migration |
Через QEMU/libvirt или платформу, при соблюдении условий совместимости |
vMotion в составе соответствующей лицензии и инфраструктуры |
Live Migration средствами Windows Server |
Встроенное управление миграцией KVM-ВМ |
|
Высокая доступность |
Требует внешнего кластерного стека |
Функции vSphere/VCF |
Failover Clustering |
Встроенный HA-менеджер кластера |
|
Автоматическое размещение ВМ |
Зависит от платформы управления |
DRS и другие средства экосистемы |
Failover Clustering и System Center |
Базовые механизмы HA; не полный аналог VMware DRS |
|
Хранилище |
Любые поддерживаемые Linux и выбранным стеком технологии |
VMFS, NFS, vSAN и интеграции производителей |
NTFS, ReFS, SMB, CSV, Storage Spaces Direct |
LVM, ZFS, Ceph, NFS, iSCSI и другие |
|
Контейнеры |
Не относятся к самому KVM |
Отдельные компоненты экосистемы |
Windows Containers и Hyper-V isolation |
LXC встроен в платформу |
|
Проброс устройств |
VFIO, SR-IOV, mediated devices — в зависимости от оборудования |
DirectPath I/O, SR-IOV и поддерживаемые технологии VMware |
DDA, SR-IOV, GPU-P и другие механизмы |
Управление KVM/VFIO через интерфейс и конфигурацию Proxmox |
|
Кому подходит |
Linux-инфраструктурам, облакам и специализированным решениям |
Организациям, которым нужна единая коммерческая экосистема VMware |
Средам, построенным вокруг Windows Server и Microsoft |
Тем, кому нужна готовая открытая платформа для ВМ и контейнеров |
Конечный выбор зависит от бизнес-задач, навыков команды, требований к поддержке, лицензирования гостевых ОС и уже используемой инфраструктуры.
KVM — хороший фундамент для Linux-инфраструктуры, но поверх него всё равно нужна система управления. VMware ESX предлагает цельную коммерческую экосистему. Hyper-V естественно интегрируется с Windows Server. Proxmox VE превращает KVM и LXC в готовую платформу с единым web-интерфейсом.
Более подробный разбор критериев есть в статье «Какой гипервизор выбрать».
Вместо выводов
KVM — открытый компонент ядра Linux для аппаратной виртуализации, а не готовый аналог Proxmox VE или VMware vSphere. Обычно он работает вместе с QEMU, который создаёт процесс и виртуальное оборудование ВМ, и libvirt, отвечающим за управление.
Для небольшого хоста достаточно Linux, QEMU, libvirt и Cockpit либо virt-manager. Если нужны кластер, HA, резервное копирование и единый интерфейс, проще использовать готовую платформу — например, Proxmox VE. Для облачной инфраструктуры подходят OpenStack и OpenNebula, а для совместного управления контейнерами и ВМ — OpenShift Virtualization.
Главное преимущество KVM — возможность выбрать и заменить практически любой слой. Главный недостаток ровно тот же: совместимость, безопасность и надёжность всей сборки должен обеспечить администратор или поставщик поддержки.
Важно! И не забывайте, что производительность и количество ВМ определяет не название гипервизора. Важны характеристики приложений, соотношение vCPU:pCPU, объём памяти, NUMA-топология, задержки хранилища, сеть и резерв на отказ узла. Поэтому конфигурацию сервера нужно рассчитывать под конкретную нагрузку, а не по универсальной формуле.
Спасибо, что дошли до конца статьи :) Лучший подарок автору — добавить блог Сервер Молл в закладки. Обещаю и дальше выпускать полезные и подробные материалы!
Если понадобится сервер под KVM или другую платформу виртуализации, специалисты Сервер Молл помогут рассчитать процессоры, память, хранилище и сеть с учётом профиля нагрузки и планов масштабирования.
Статья обновлена 25.08.2026. Уточнена роль KVM в стеке Linux, обновлены версии ядра, QEMU и libvirt. Добавлены современные инструменты управления, VirtIO, NUMA, hugepages, CPU pinning, SR-IOV/VFIO, Secure Boot, vTPM и confidential computing. Исправлены требования к ресурсам, условия live migration и сравнение с Proxmox VE, VMware ESX и Hyper-V.
