KVM-виртуализация: что она даёт твоему VPS

Если ты арендуешь VPS сегодня, он почти наверняка работает на KVM. Три буквы стоят в названии тарифа и мелькают в панели провайдера, но что они значат для твоего сервера, объясняют редко. А значат они немало: чьё у тебя ядро, заведётся ли Docker, почему диск называется vda и почему свежая AlmaLinux может отказаться загружаться на исправной машине.

Сначала проверка в одну команду. Потом разберём, что KVM реально даёт, чего он не обещает (хотя многие уверены в обратном) и как поднять собственные виртуалки, если у тебя выделенный сервер.

Как проверить, что твой VPS работает на KVM

Подключись к серверу по SSH и набери:

systemd-detect-virt

Утилита входит в systemd, т.е. есть практически в любом современном дистрибутиве. Ответ состоит из одного слова:

Вывод	Что это значит для тебя
kvm	Полноценная виртуальная машина на KVM. Норма для большинства VPS.
qemu	Виртуалка без аппаратного ускорения: процессор эмулируется программно и работает в разы медленнее. На купленном VPS это тревожный знак.
amazon, google	Облака AWS и Google Cloud. Внутри тоже KVM, только в собственной обвязке этих компаний.
openvz, lxc	Контейнер, а не виртуальная машина: ядро у тебя общее с хостом. Подробнее в разборе OVZ-виртуализации.
microsoft, vmware, xen	Другие гипервизоры: Hyper-V, VMware, Xen.
docker	Ты сейчас внутри контейнера на своём VPS, а не на самом сервере.

Последняя строка не шутка. Утилита показывает самый внутренний слой, поэтому из контейнера она честно ответит docker. Чтобы увидеть, на чём стоит сам сервер, добавь ключ --vm: systemd-detect-virt --vm.

Если systemd нет (бывает на Alpine и минимальных образах), помогут две другие команды:

lscpu | grep -i hypervisor
cat /sys/class/dmi/id/product_name

Первая на KVM покажет Hypervisor vendor: KVM. Вторая выдаст название «материнской платы», и вот тут новички иногда пугаются: строка вида Standard PC (Q35 + ICH9, 2009) выглядит так, будто сервер собран в 2009 году. Это всего лишь имя модели чипсета, которую эмулирует виртуальная машина, к возрасту железа оно отношения не имеет.

Что такое KVM, если без учебника

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

Сам KVM делает одну вещь, но ключевую: позволяет коду гостевой системы выполняться прямо на физическом процессоре, через аппаратные расширения Intel VT-x или AMD-V. Процессор сам отлавливает моменты, когда гость пытается тронуть что-то чужое, и передаёт управление хосту. Всё остальное, что делает виртуалку похожей на компьютер (диск, сетевая карта, BIOS, экран консоли), рисует отдельная программа QEMU. А управляет этой парой libvirt или панель провайдера: SolusVM, Virtualizor, Proxmox, OpenStack и прочие.

Отсюда первая путаница. В выводе lscpu на KVM-сервере часто написано что-нибудь вроде QEMU Virtual CPU, и в поддержку периодически приходит возмущённое «мне продали QEMU вместо KVM». Нет, не продали. На обычном VPS QEMU присутствует в связке практически всегда (исключения вроде собственных гипервизоров больших облаков не в счёт), KVM его ускоряет, и вместе они работают как одно целое. Беспокоиться стоит только в одном случае: если systemd-detect-virt ответил qemu, ведь тогда ускорения действительно нет.

Второе следствие менее очевидно, хотя объясняет очень многое. На хосте каждая виртуальная машина — обычный процесс qemu-system-x86_64. Провайдер видит твой сервер в своём top примерно так же, как ты видишь у себя nginx. Ограничения ему ставят теми же механизмами ядра, что и любому процессу, и за процессорное время твоя виртуалка соревнуется с соседними так же, как процессы соревнуются между собой. К этому мы ещё вернёмся.

Спор о том, гипервизор KVM первого типа или второго, оставлю теоретикам: формально первого, ведь гипервизором становится само ядро, хотя выглядит всё как обычный Linux с программами. Арендатору VPS эта классификация ничего не даёт. Общую картину типов виртуализации я разбирал в статье про гипервизоры и виды виртуализации, а конкурентам KVM посвящены отдельные разборы: Xen, VMware ESXi и Hyper-V.

Своё ядро и что из этого следует

Главное, что отличает KVM-сервер от контейнерного: ядро у тебя собственное. В контейнере (OpenVZ, LXC) все клиенты хоста работают на одном общем ядре, а тебе выделен изолированный набор процессов и файлов. Модули ядра там не загрузить, версию ядра не поменять, многие системные параметры доступны только на чтение. Подробное сравнение есть в статье KVM против OpenVZ, здесь важнее, что это меняет в повседневной работе.

Docker на KVM работает так же, как на физическом сервере: нужные ему cgroups, файловая система overlay и модули для сетевых правил на месте (про Docker на VPS у нас есть отдельная статья). Пару лет назад обращения в духе «Docker не стартует, ругается на cgroups» шли валом, и почти всегда выяснялось, что VPS контейнерный. Сейчас рынок почти целиком переехал на KVM, и этот класс проблем встречается разве что на самых дешёвых тарифах.

WireGuard живёт в ядре Linux с версии 5.6, поэтому на KVM с любым свежим дистрибутивом он просто включается (настройка WireGuard с нуля). На контейнерных VPS с древним хостовым ядром его приходится запускать в пользовательском режиме или упрашивать провайдера.

С параметрами ядра то же самое. Включить BBR, поменять размеры сетевых буферов, подкрутить поведение памяти через sysctl можно только на своём ядре (подробности будут в статье про тюнинг ядра через sysctl). Проверить, какие алгоритмы управления перегрузкой тебе доступны, можно так:

sysctl net.ipv4.tcp_available_congestion_control

Swap тоже твой: создаёшь файл, включаешь swapon, и это настоящая подкачка, а не цифра, которую рисует провайдер (как работать со swap-файлом). Плюс возможность поставить систему со своего ISO-образа, зашифровать диск или вообще запустить FreeBSD либо Windows.

Есть и обратная сторона. Своё ядро означает свою ответственность за него. Обновление ядра применяется только после перезагрузки, и делать её никто за тебя не будет: на Ubuntu о такой необходимости напоминает файл /var/run/reboot-required. Если сломать загрузчик или ошибиться в /etc/fstab, сервер просто не поднимется, а SSH будет молчать.

Спасает в таких случаях VNC-консоль, которую дают практически все KVM-провайдеры. Это «экран» виртуальной машины прямо в браузере, он работает независимо от сети внутри сервера. Кстати, о ней почти всегда вспоминают в самый неудачный момент: когда файрвол уже закрыл SSH, а сессия оборвалась. Через консоль можно войти паролем, откатить правило, поправить конфиг. Если не помогает и она, остаётся режим восстановления (rescue mode).

Чего KVM не обещает

Самое живучее упрощение звучит так: «KVM — это честные выделенные ресурсы, а OpenVZ — оверселлинг». Отчасти исторически оно оправдано, ведь контейнерные тарифы перепродавали особенно бодро. Но KVM даёт изоляцию, а не гарантии. Сколько ресурсов на самом деле достаётся твоей виртуалке, решает конфигурация провайдера, гипервизору это безразлично.

Начнём с процессора. Каждое виртуальное ядро (vCPU) на хосте — это поток процесса QEMU. Сервер с 32 аппаратными потоками технически может держать виртуалки с сотней vCPU в сумме, и на недорогих тарифах так и делают: большинство VPS большую часть времени простаивают, и в среднем всем хватает. Проблемы начинаются, когда соседи просыпаются одновременно. Что такое vCPU и как его считать, разберём в отдельной статье про vCPU.

Изнутри виртуалки это видно, и метрика называется steal time: доля времени, когда твоему серверу нужен был процессор, а хост отдал его кому-то другому. Смотреть так:

vmstat 1 5

Нужная колонка st стоит последней. В top то же значение показано в строке %Cpu(s) как st. Как читать цифры: доли процента и единицы процентов вполне нормальны. Если под твоей нагрузкой steal стабильно держится на 5–10%, хост заметно загружен. Двадцать процентов и выше означают, что купленного процессора в полном объёме просто нет.

Картина, которую провайдеры видят постоянно: клиент жалуется, что сайт тормозит, load average растёт, а сам сайт процессор почти не ест. Сначала ищут тяжёлый плагин или медленный запрос, проверяют базу, и только потом кто-то догадывается посмотреть на st, а там треть процессорного времени уходит соседям. Load average при этом растёт как раз потому, что процессы стоят в очереди за ядром, которого им не дают.

Это ещё не повод бежать с дешёвого тарифа. Это повод один раз посмотреть на steal под реальной нагрузкой и понимать, за что платишь.

С памятью оверселлинг встречается реже, но технически KVM его тоже позволяет. Механизм KSM склеивает одинаковые страницы памяти разных виртуалок (например, двадцать одинаковых Ubuntu на одном хосте), а драйвер virtio-balloon даёт хосту возможность забрать у гостя часть памяти обратно. Загружен ли он у тебя, покажет lsmod | grep balloon. Сам по себе модуль ни о чём плохом не говорит, многие провайдеры подключают его только ради статистики. Но если сервер ловит нехватку памяти там, где по твоим расчётам её должно хватать, проверить стоит.

Диск в виртуалке — это файл или том на общем хранилище хоста. Его скорость делят все соседи, а на большинстве тарифов стоит ещё и лимит на число операций в секунду. Ночью, когда у половины клиентов запускаются бэкапы, отклик диска может просесть в разы, хотя днём тесты были отличными. Поэтому замерять диск лучше в разное время суток, и как это делать, описано в статье о том, как протестировать VPS перед покупкой; более глубокие методики будут в разборе бенчмарков и стресс-тестов.

Почему всё устроено именно так? Со стороны провайдера ответ простой: тариф за несколько долларов в месяц без перепродажи процессора не существует, железо и электричество стоят дороже. Честные провайдеры так и пишут, что vCPU «shared», а выделенные ядра продают отдельно и заметно дороже (подробнее в статье shared и dedicated CPU). Нечестные пишут «KVM» крупным шрифтом и рассчитывают, что этого хватит. Слово KVM в названии тарифа сообщает о технологии, а не о том, сколько ресурсов тебе реально достанется.

Модель процессора: сюрприз, который вылезает после установки

Этот момент вызывает больше всего недоумения, потому что выглядит как поломка там, где всё исправно. Провайдер решает не только сколько ядер дать виртуалке, но и каким процессором ей представиться. Вариантов, грубо говоря, два.

Первый вариант: виртуалка видит настоящий процессор хоста со всеми его наборами инструкций (в терминах libvirt это host-passthrough или host-model). Второй: ей показывают усреднённую модель вроде qemu64, kvm64 или какой-нибудь старой серверной линейки, где часть современных инструкций отключена.

Зачем второе? Ради живой миграции. Перенести работающую виртуалку с одного хоста на другой без остановки можно, только если на новом хосте есть все инструкции, которые она видела на старом. Если в парке провайдера стоят процессоры разных поколений, проще всего показывать всем клиентам общий минимум. Логика здравая. Последствия бывают неприятными.

RHEL 9 и его клоны, AlmaLinux 9 и Rocky Linux 9, собраны под уровень x86-64-v2, которому нужны, например, инструкции SSE4.2. На модели kvm64 их нет, и система падает на старте с сообщением Fatal glibc error: CPU does not support x86-64-v2. RHEL 10 и Rocky 10 подняли планку до x86-64-v3 (там уже нужны AVX2), а AlmaLinux 10 ради старых процессоров выпускает отдельную сборку под v2. MongoDB начиная с версии 5.0 требует AVX. Без флага aes шифрование в TLS и VPN выполняется программно, и на слабом тарифе это заметно.

История, которая повторяется из года в год: человек берёт недорогой VPS, ставит Rocky со своего ISO, а установщик сразу валится в kernel panic. Качает образ заново, пробует другую версию, пишет в поддержку про битый шаблон… Пока кто-нибудь не посмотрит, какой процессор видит виртуалка. С контейнерами то же самое: переносишь проект на новый сервер, и контейнер с базой уходит в бесконечный рестарт, а в docker logs висит предупреждение про AVX.

Проверить, что умеет твой виртуальный процессор, можно двумя командами:

/lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v
grep -o -w -E 'sse4_2|avx|avx2|aes' /proc/cpuinfo | sort -u

Первая работает на системах с glibc 2.33 и новее (Ubuntu 22.04+, Debian 12+). Уровни, рядом с которыми написано supported, searched, процессор поддерживает. Вторая просто показывает, какие из важных флагов есть в наличии.

Если чего-то не хватает, смена дистрибутива помогает лишь отчасти. Правильнее спросить у поддержки, можно ли переключить модель процессора, и многие провайдеры это делают по запросу. А если такой вопрос возникает ещё до покупки, его стоит задать заранее, особенно если планируешь серверную ОС семейства RHEL (о выборе системы будет отдельная статья: какую ОС выбрать для VPS).

virtio, или почему диск называется vda

Эмулировать настоящий сетевой адаптер или SATA-контроллер можно, но медленно: гость общается с «железом», которого нет, и каждое обращение приходится переводить. Поэтому для KVM придуманы виртуальные устройства virtio, у которых гость и хост договариваются напрямую. Диск на драйвере virtio-blk называется /dev/vda, отсюда и необычное имя. Если видишь /dev/sda, это либо virtio-scsi (тоже быстрый вариант), либо эмуляция обычного контроллера. Проверить, что virtio на месте, можно командой lsmod | grep virtio.

Linux драйверы virtio знает из коробки. Windows нет, и при установке с чистого образа инсталлятор просто не видит диск. Нужен отдельный ISO с драйверами virtio-win, который подключают вторым приводом. На готовых шаблонах провайдеры решают это сами, так что сталкиваются с проблемой в основном те, кто ставит систему вручную. Если Windows нужна без возни с драйверами, проще сразу смотреть VPS с Windows.

Свой KVM: на выделенном сервере, дома или внутри VPS

Когда у тебя есть выделенный сервер или просто мощный домашний компьютер с Linux, KVM можно поднять самому. Сначала убедись, что процессор умеет аппаратную виртуализацию и она включена:

grep -E -c '(vmx|svm)' /proc/cpuinfo
ls -l /dev/kvm

Ненулевое число в первой строке и существующий /dev/kvm означают, что всё в порядке. На Ubuntu есть ещё утилита kvm-ok из пакета cpu-checker, которая отвечает человеческим языком. Если флагов нет на домашнем ПК, почти всегда виновата выключенная опция в BIOS/UEFI (Intel Virtualization Technology или SVM Mode).

Установка на Ubuntu по официальной документации выглядит так:

sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system virtinst
sudo adduser $USER libvirt

После добавления в группу нужно перелогиниться. На Debian вместо qemu-kvm ставят qemu-system-x86, остальное совпадает. Первая виртуалка из установочного образа создаётся одной командой:

virt-install --name test-vm --memory 2048 --vcpus 2 \
  --disk size=20 \
  --cdrom /var/lib/libvirt/images/ubuntu-24.04-live-server-amd64.iso \
  --os-variant ubuntu24.04 --graphics vnc

Дальше управление идёт через virsh: virsh list --all покажет виртуалки, virsh start и virsh shutdown запускают и гасят, virsh autostart включает автозапуск вместе с хостом.

Первый камень, о который спотыкаются почти все, это сеть. По умолчанию libvirt создаёт сеть default с мостом virbr0 и прячет виртуалки за NAT: наружу они ходят, а снаружи до них не достучаться. Чтобы виртуалка получила собственный публичный адрес, нужен сетевой мост на основном интерфейсе, а у многих провайдеров выделенных серверов ещё и отдельный MAC-адрес под каждый дополнительный IP, который выдаётся через их панель. Это та часть, где пошаговый мануал под конкретного провайдера полезнее любой общей инструкции.

Если виртуалок планируется больше пары, удобнее взять готовую платформу. Proxmox VE построен на том же KVM, но даёт веб-интерфейс, бэкапы, снапшоты и кластеризацию из коробки (разбор будет в статье Proxmox VE на своём сервере). В свежих версиях Proxmox, к слову, модель процессора для новых виртуалок по умолчанию уже не kvm64, а вариант уровня x86-64-v2 с AES: та самая история из предыдущего раздела дошла и до разработчиков.

А можно ли запустить KVM внутри арендованного VPS? Можно, но только если провайдер пробросил в виртуалку флаги vmx или svm, т.е. включил вложенную виртуализацию. Проверка та же: grep -E -c '(vmx|svm)' /proc/cpuinfo. Если там ноль, QEMU всё равно запустится, только без ускорения, и гость внутри будет еле шевелиться (тот самый вывод qemu из первой таблицы). Где вложенную виртуализацию дают и зачем она вообще нужна, разберём отдельно: вложенная виртуализация. Для изоляции сервисов внутри одного VPS часто хватает и контейнеров, тут поможет статья про LXC и LXD.

Как выбирать KVM-тариф, когда KVM везде

Раньше «KVM» в описании тарифа было преимуществом. Сейчас это скорее норма, как кондиционер в новой машине, и отличаются предложения уже деталями. Ядра выделенные или общие, и если общие, насколько их перепродают (это проверяется только steal-временем под нагрузкой). Какую модель процессора видит виртуалка, и можно ли её поменять. Есть ли VNC-консоль, загрузка своего ISO и rescue-режим. Дают ли вложенную виртуализацию, если она тебе нужна. Какие лимиты стоят на диск.

Большую часть этого провайдеры в описаниях тарифов не пишут, и это нормально: тестовый период или почасовая оплата на день-другой ответят на все вопросы лучше любой рекламы. Как подойти к выбору по остальным параметрам, описано в статье о том, как выбрать тариф на VPS, а сравнить конкретных провайдеров можно в нашем каталоге виртуальных серверов.

Источники

• KVM — официальный сайт проекта
• Документация KVM в ядре Linux (kernel.org)
• QEMU: модели процессоров для KVM-гостей
• libvirt: формат описания виртуальной машины, модель CPU
• Ubuntu Server: libvirt и virsh
• Debian Wiki: KVM
• systemd-detect-virt — man-страница
• AlmaLinux 10.0 Release Notes: сборки x86-64-v3 и x86-64-v2
• MongoDB Production Notes: требования к процессору x86_64
• virtio-win: драйверы virtio для Windows