Эксперты в подборе IT-оборудования
KVM (Kernel-based Virtual Machine) - гипервизор, встроенный в ядро Linux. Он превращает обычный Linux-сервер в хост для виртуальных машин: ничего не нужно докупать, достаточно процессора с аппаратной виртуализацией и пары пакетов. KVM в ядре с 2007 года, на нём работают Proxmox VE, OpenStack, большинство облаков и российские платформы виртуализации.
Чтобы не путать: KVM-переключатель (Keyboard-Video-Mouse) - совсем другая вещь, это устройство для управления несколькими серверами с одной клавиатуры и монитора. Про него у нас есть отдельная статья о KVM over IP. Здесь речь о гипервизоре.
Ниже разберём, как устроена связка KVM, QEMU и libvirt, как поставить её на Ubuntu и RHEL, создать и настроить виртуальные машины, выбрать формат дисков, сделать бэкап и что проверять, если что-то не работает.
Когда говорят «KVM виртуализация», обычно имеют в виду связку из нескольких компонентов. Модуль ядра kvm.ko (вместе с kvm-intel.ko или kvm-amd.ko) отвечает за низкоуровневое управление процессором и памятью: запускает код гостевой системы прямо на физических ядрах через расширения Intel VT-x или AMD-V и изолирует его от хоста.
Одного модуля мало: нужен ещё компонент, который эмулирует устройства - диски, сетевые карты, видео. Эту работу делает QEMU. Он работает как обычный процесс в пространстве пользователя, но благодаря интеграции с KVM получает аппаратное ускорение. Получается гибрид: QEMU отвечает за периферию, а KVM гоняет виртуальные процессоры на физических ядрах.
Поверх этой связки обычно работает libvirt - библиотека и служба управления виртуализацией. Она даёт единый API для KVM, Xen, LXC и других технологий. Через libvirt работают графический virt-manager, консольный virsh, веб-консоль Cockpit и многие системы управления.
Как запускается виртуальная машина:
Такие переключения происходят тысячи раз в секунду. Аппаратная поддержка виртуализации и паравиртуальные драйверы virtio держат накладные расходы на уровне нескольких процентов.
KVM относят к гипервизорам первого типа: сам Linux с модулем KVM становится гипервизором и работает с железом напрямую. Строго формально тут есть спор, потому что на хосте работает полноценная ОС, подробнее про классификацию - в статье что такое гипервизор и какие бывают типы.
Первый шаг - проверить, поддерживает ли процессор аппаратную виртуализацию:
grep -E -c '(vmx|svm)' /proc/cpuinfo
Если вывод больше нуля - всё в порядке. Флаг vmx указывает на Intel VT-x, svm - на AMD-V. Если получили ноль, виртуализация выключена в BIOS: опция обычно называется Intel Virtualization Technology, SVM Mode или AMD-V. Как её найти и включить, разобрано в статье про Virtualization Technology в биосе.
Установка на Ubuntu Server по официальной документации:
sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system virtinst
Графический virt-manager ставится отдельно (sudo apt install virt-manager), на сервере без графики он не нужен. Проверить, что KVM доступен, удобно утилитой kvm-ok из пакета cpu-checker:
sudo apt install cpu-checker
kvm-ok
CentOS Linux снят с поддержки, его место заняли RHEL и совместимые дистрибутивы. Пакеты ставятся через dnf:
sudo dnf install qemu-kvm libvirt virt-install virt-viewer
В RHEL 9 libvirt разделён на отдельные службы (virtqemud, virtnetworkd, virtstoraged и другие). Red Hat запускает их так:
for drv in qemu network nodedev nwfilter secret storage interface; do sudo systemctl start virt${drv}d{,-ro,-admin}.socket; done
Для управления ВМ в RHEL 9 Red Hat предлагает веб-консоль Cockpit. В отечественных Astra Linux и ALT виртуализация тоже построена на QEMU/KVM и libvirt, но названия пакетов и порядок установки смотрите в документации конкретной версии.
После установки проверяем, что модуль KVM загрузился, и прогоняем встроенную проверку хоста:
lsmod | grep kvm
sudo virt-host-validate qemu
В выводе lsmod должны быть kvm_intel или kvm_amd. virt-host-validate покажет PASS, WARN или FAIL по каждому пункту: аппаратная виртуализация, доступ к /dev/kvm, IOMMU и так далее.
Чтобы управлять виртуальными машинами без sudo, добавьте пользователя в группу libvirt и перелогиньтесь:
sudo usermod -aG libvirt $USER
Virt-manager хорош для знакомства: открываете, нажимаете «Create a new virtual machine», выбираете ISO-образ, назначаете ресурсы - и через несколько минут ВМ работает. Для повседневной работы на сервере удобнее консоль virsh, у неё доступ ко всем функциям libvirt:
virsh list --all # все ВМ, включая выключенные
virsh start vm-name # запуск
virsh shutdown vm-name # корректное выключение
virsh destroy vm-name # принудительное выключение
virsh console vm-name # подключиться к консоли
virsh autostart vm-name # запускать вместе с хостом
Без графики виртуальную машину создают утилитой virt-install. Пример для Ubuntu-гостя с диском 40 ГБ и подключением к сетевому мосту br0:
virt-install \
--name vm1 \
--memory 4096 --vcpus 2 \
--disk size=40,format=qcow2,bus=virtio \
--cdrom /var/lib/libvirt/images/ubuntu-24.04-live-server-amd64.iso \
--os-variant ubuntu24.04 \
--network bridge=br0,model=virtio \
--graphics vnc
Список доступных значений --os-variant выводит osinfo-query os. Правильный вариант ОС важен: по нему libvirt выбирает драйверы и настройки по умолчанию.
Клонирование виртуальной машины - частая задача при создании тестовых сред:
virt-clone --original vm-template --name vm-clone-1 --auto-clone
Для массового развёртывания пишут скрипты или используют Ansible с модулями для libvirt, а начальную настройку гостей делают через cloud-init. Так можно поднять десятки одинаковых машин за несколько минут.
Если у хостов общее хранилище (NFS, iSCSI, Ceph), работающую машину можно перенести без остановки:
virsh migrate --live vm-name qemu+ssh://target-host/system
Без общего хранилища тоже можно, с ключом --copy-storage-all, но тогда по сети переезжает и весь диск, и миграция идёт заметно дольше. Подробнее о механике - в статье про живую миграцию виртуальных машин.
По умолчанию libvirt создаёт сеть default с NAT через мост virbr0: машины выходят в интернет, но снаружи их не видно. Для рабочих серверов обычно нужен сетевой мост (bridge): виртуальные машины получают адреса из той же сети, что и хост, и доступны другим компьютерам.
На Ubuntu мост описывают в netplan, например в файле /etc/netplan/01-bridge.yaml:
network:
version: 2
ethernets:
eno1:
dhcp4: false
bridges:
br0:
interfaces: [eno1]
addresses: [192.168.1.10/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [192.168.1.1]
Имя интерфейса и адреса подставьте свои. Применять настройки на удалённом сервере лучше командой sudo netplan try: если связь пропадёт, через 120 секунд конфигурация откатится сама. В RHEL и совместимых мост создают через nmcli или Cockpit.
Диск виртуальной машины - это файл на хосте или блочное устройство. От выбора формата зависят скорость, удобство снапшотов и расход места:
| Формат | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| qcow2 | Тонкое выделение места, встроенные снапшоты, сжатие | Чуть медленнее raw на интенсивной записи | Универсальный вариант по умолчанию, тестовые и большинство рабочих ВМ |
| raw | Максимальная скорость, проще формат | Нет встроенных снапшотов, на части ФС занимает весь объём сразу | Нагруженные базы данных, когда снапшоты делаются средствами хранилища |
| Логический том LVM | Скорость блочного устройства, снапшоты LVM | Сложнее переносить и менять размер | Хосты, где диски ВМ живут на отдельной группе томов |
| Сетевое хранилище (iSCSI, Ceph RBD, NFS) | Общий доступ для нескольких хостов, живая миграция | Зависимость от сети и её скорости | Кластер из нескольких хостов |
Тонкое выделение (thin provisioning) экономит место: диск растёт по мере записи данных. Создаётся так:
qemu-img create -f qcow2 -o preallocation=metadata disk.qcow2 100G
Файл весит несколько мегабайт, а гостевая система видит диск на 100 ГБ. Следите за свободным местом на хосте: если тонкие диски вырастут больше, чем есть на томе, остановятся все ВМ на нём.
libvirt хранит диски в пулах. Пул default - каталог /var/lib/libvirt/images. Отдельный пул удобно завести под быстрый массив:
virsh pool-define-as fast dir --target /srv/vm-fast
virsh pool-build fast
virsh pool-start fast
virsh pool-autostart fast
KVM даёт производительность, близкую к физическому серверу, но только при правильной настройке. Вот что отличает просто работающую систему от эффективной.
CPU pinning - закрепление виртуальных процессоров за конкретными физическими ядрами. Снижает задержки и улучшает работу кэша. В конфиге ВМ (virsh edit vm-name) указываете:
Теперь четыре виртуальных процессора этой машины работают только на ядрах 2-5. Для жёсткой привязки каждого vCPU к своему ядру используют блок cputune с элементами vcpupin.
NUMA важна для серверов с двумя процессорами. Если виртуальная машина обращается к памяти, подключённой к другому процессору, скорость падает. Привязка памяти ВМ к одному NUMA-узлу:
virsh numatune vm-name --mode strict --nodeset 0 --config
Hugepages - большие страницы памяти (2 МБ или 1 ГБ вместо стандартных 4 КБ). Снижают нагрузку на TLB процессора и ускоряют доступ к памяти. На хосте резервируем страницы, в конфиге ВМ включаем их использование:
sudo sysctl vm.nr_hugepages=1024
Драйверы virtio обязательны для нормальной скорости дисков и сети. Это паравиртуальные драйверы: гостевая система знает, что работает в виртуальной машине, и обменивается данными с гипервизором без эмуляции старого железа. В Linux они уже в ядре, для Windows их ставят из образа virtio-win.
| Тип виртуального диска | Как работает | Когда брать |
|---|---|---|
| IDE | Эмуляция старого контроллера | Только для древних ОС без драйверов virtio |
| SATA | Эмуляция контроллера AHCI | Установка Windows без драйверов virtio, совместимость |
| virtio-blk | Паравиртуальный диск, минимум накладных расходов | Большинство Linux-машин и Windows с драйверами virtio |
| virtio-scsi | Паравиртуальный SCSI-контроллер | Много дисков в одной ВМ, нужны TRIM/discard и SCSI-команды |
Разница между эмуляцией IDE/SATA и virtio на дисковых операциях - многократная, поэтому на рабочих машинах virtio ставят всегда.
Over-committing - выдача виртуальным машинам в сумме больше процессоров и памяти, чем физически есть, в расчёте на то, что не все будут использовать ресурсы одновременно. Для процессоров это нормальная практика, с памятью - осторожнее. Работает в тестовых средах и VDI, в рабочих системах требует мониторинга: как только хост начнёт активно использовать своп или перегружать процессор, проседают все ВМ разом.
Снапшот и резервная копия решают разные задачи. Снапшот qcow2 хранится в том же файле или рядом и спасает от неудачного обновления внутри ВМ:
virsh snapshot-create-as vm-name before-update
virsh snapshot-revert vm-name before-update
От смерти диска или хоста снапшот не спасёт: он лежит там же, где сама машина. Резервная копия должна уезжать на другое устройство. Варианты по нарастанию удобства:
virsh dumpxml vm-name) на другой сервер или NAS. Просто и надёжно, но с простоем.virsh backup-begin.Восстановление проверяйте хотя бы раз в квартал: бэкап, который ни разу не разворачивали, нельзя считать бэкапом.
Сравнивать гипервизоры сложно, потому что каждый решает свои задачи. Но есть сценарии, где KVM выигрывает.
KVM vs VMware ESXi. VMware даёт vMotion, HA, DRS и единую консоль из коробки, но требует лицензий, а для поддержки - оборудования из списка совместимости. KVM бесплатен и работает на любом сервере, который поддерживает Linux, а кластерные функции дают платформы поверх него: Proxmox, oVirt, OpenStack. Если у вас Linux-инфраструктура и команда знает эту экосистему, KVM логичнее.
KVM vs Xen. Xen исторически был первым массовым гипервизором для Linux, но у него сложнее архитектура: нужен отдельный управляющий домен Dom0. KVM проще в настройке и обслуживании, потому что это часть ядра. AWS долго работал на Xen, а с 2017 года переводит инстансы на свою платформу Nitro, построенную на KVM.
KVM vs Hyper-V. Если инфраструктура на Windows и Active Directory, Hyper-V встроен в Windows Server и интегрирован с ней. Если на Linux - KVM. Запускать на каждом из них гостей «чужой» ОС можно, просто родная интеграция удобнее.
Общий расклад по платформам, включая цены и лицензии, - в нашем сравнении гипервизоров 2026.
Где KVM особенно хорош:
Для малого и среднего бизнеса важная оговорка: на «голом» KVM с virsh редко строят инфраструктуру компании. Обычно ставят платформу на его основе с веб-интерфейсом, кластером и бэкапом: Proxmox VE или российские zVirt и «Брест», которые тоже работают на KVM. Знание самого KVM пригодится и там: под капотом те же QEMU, virtio и те же настройки производительности.
Безопасность. Аппаратная виртуализация изолирует машины на уровне процессора: гостевая ОС не может прочитать память хоста или других ВМ без уязвимости в процессоре или гипервизоре. SELinux (sVirt) и AppArmor добавляют ещё один уровень защиты, ограничивая процессы QEMU. На новых процессорах KVM умеет запускать конфиденциальные ВМ (AMD SEV-SNP, Intel TDX), память которых зашифрована даже от администратора хоста.
| Симптом | Вероятная причина | Что сделать |
|---|---|---|
| Нет /dev/kvm, lsmod не показывает kvm_intel / kvm_amd | Виртуализация выключена в BIOS | Включить Intel VT-x / SVM в BIOS, перезагрузить хост |
| «Permission denied» при запуске ВМ от пользователя | Пользователь не в группе libvirt / kvm | sudo usermod -aG libvirt,kvm $USER, перелогиниться |
| virsh не подключается: «Failed to connect socket» | Служба libvirt не запущена | Ubuntu: sudo systemctl enable --now libvirtd; RHEL 9: запустить сокеты virtqemud и других служб |
| ВМ на мосту не получает адрес | IP остался на физическом интерфейсе, мост не поднят | Перенести адрес на br0, проверить ip a и bridge link |
| Установщик Windows не видит диск | Диск virtio, драйвера в установщике нет | Подключить второй CD с virtio-win и загрузить драйвер на шаге выбора диска |
| Диски ВМ работают медленно | Эмуляция IDE/SATA, кэш хоста, тонкий диск на медленном массиве | Перевести на virtio, cache=none для баз данных, перенести диск на быстрый пул |
KVM активно развивается. Появляются оптимизации под новые процессоры, улучшается живая миграция, снижаются накладные расходы. Интересное направление - контейнеры в лёгких виртуальных машинах: Kata Containers запускают каждый контейнер в микро-ВМ на KVM и добавляют изоляцию без заметной потери скорости.
Автоматизация тоже идёт вперёд. Terraform, Ansible и Kubernetes (через KubeVirt) работают с KVM через API libvirt, так что инфраструктуру можно описывать кодом и разворачивать одной командой. Новые механизмы ядра вроде io_uring снижают задержки дисковых операций, а улучшенная работа с NUMA ускоряет многопроцессорные конфигурации.
Начать можно за пять минут, установив пару пакетов. А довести хост до состояния эффективной системы - задача, где пригодится понимание процессоров, памяти, сети и дисков. KVM ничего из этого не прячет за мастерами настройки.
Гипервизор, встроенный в ядро Linux. С ним на одном сервере работает много виртуальных машин с Linux, Windows и другими ОС, используя аппаратную виртуализацию процессора.
KVM - модуль ядра, который запускает код виртуальных машин на процессоре. QEMU - программа, которая эмулирует для них устройства: диски, сеть, видео. Работают они вместе, поэтому часто пишут «QEMU/KVM».
Обычно его относят к первому типу: Linux с модулем KVM сам становится гипервизором и работает с железом напрямую. Формально на хосте работает полноценная ОС, поэтому иногда KVM называют гибридом.
Да. Windows Server и настольные версии работают в KVM. Для нормальной скорости дисков и сети при установке подключают драйверы virtio из образа virtio-win.
По теме: Системные требования Proxmox, Docker vs LXC
Собираете хост под KVM или Proxmox?
Подберём сервер под ваши виртуальные машины: процессоры, память с запасом под рост, диски под нужный формат хранения. Соберём и протестируем перед отгрузкой. Посмотрите сервер с виртуализацией в каталоге или напишите нам: +7 (800) 551-80-12, info@ittelo.ru. Серверами мы занимаемся больше 11 лет и за это время накопили серьёзную экспертизу. Даём гарантию до 5 лет, берём сервер на постпродажное обслуживание и не пропадаем после отгрузки.
