Как KVM работает изнутри
KVM превращает ядро Linux в гипервизор Type-1, предоставляя символьное устройство /dev/kvm. Пользовательский процесс (обычно QEMU) открывает это устройство, просит ядро создать виртуальный CPU и затем выполняет инструкции гостя напрямую на физическом CPU, используя расширения аппаратной виртуализации. Ядро обрабатывает привилегированные события; всё остальное выполняется на нативной скорости.
Три компонента обеспечивают работу KVM. Во-первых, модуль ядра kvm.ko управляет виртуализацией CPU и памяти и предоставляет интерфейс /dev/kvm. Во-вторых, специфичный для архитектуры модуль — kvm-intel.ko для Intel VT-x или kvm-amd.ko для AMD-V — переводит между общим API KVM и инструкциями виртуализации соответствующего CPU. В-третьих, пользовательский процесс гипервизора, такой как QEMU, cloud-hypervisor или Firecracker, обеспечивает эмуляцию устройств: виртуальные диски, сетевые карты, контроллеры USB и прошивку BIOS или UEFI. Поскольку гипервизором является само ядро Linux, каждый планировщик Linux, менеджер памяти и функция безопасности применяются к виртуальным машинам так же, как к нативным процессам. С точки зрения ядра гость KVM — это просто тяжеловесный процесс, поэтому такие инструменты, как top, perf и cgroups, работают с ним без модификаций.
KVM против OpenVZ против VMware ESXi против Hyper-V
KVM обеспечивает полную аппаратную виртуализацию с отдельным гостевым ядром для каждой VM. OpenVZ использует контейнеризацию на уровне ОС, при которой каждый контейнер делит ядро хоста. VMware ESXi — закрытый Type-1 гипервизор bare-metal с собственным ядром (VMkernel). Hyper-V — Type-1 гипервизор Microsoft на базе Windows. Только KVM, ESXi и Hyper-V дают Вам реальное изолированное гостевое ядро.
OpenVZ (и его преемник Virtuozzo) — это контейнерная технология, а не гипервизор. Каждый контейнер OpenVZ использует ядро Linux хоста, что означает невозможность запустить другую версию ядра, загрузить пользовательские модули ядра или запустить операционную систему отличную от Linux. Компромисс — плотность: поскольку нет накладных расходов на ядро каждой VM, хост OpenVZ может разместить больше контейнеров на том же оборудовании, поэтому бюджетные общие VPS-планы часто использовали его. VMware ESXi — корпоративный стандарт виртуализации Type-1, но это закрытый продукт с лицензированием по сокетам, что исторически делало его слишком дорогим для коммодити VPS-хостинга. Hyper-V доминирует в средах Windows-серверов и тесно интегрируется с Active Directory и System Center, но это менее распространённый выбор для парков с большим количеством Linux. KVM стал стандартом современного VPS-хостинга, потому что он открыт, входит в основное ядро, поддерживает любую гостевую ОС, работающую на x86_64 или aarch64, и имеет зрелую экосистему управления (libvirt, oVirt, Proxmox, OpenStack Nova).
Почему KVM — современный стандарт для VPS
KVM стал доминирующей VPS-технологией, потому что даёт каждому клиенту реальное изолированное ядро без оплаты лицензий уровня VMware. Он поддерживает гостей Linux, Windows, BSD и Solaris, работает на коммодити x86_64 и ARM-оборудовании и интегрирован в каждый крупный стек оркестрации облака — OpenStack, Proxmox VE, Kubernetes через KubeVirt и AWS Nitro построены на нём.
Три фактора сошлись, чтобы сделать KVM стандартом. Во-первых, расширения аппаратной виртуализации стали универсальными: Intel VT-x появилась в чипах Core 2 в 2006 году, AMD-V — в ранних Athlon 64, поэтому к началу 2010-х практически каждый серверный CPU мог хостить KVM на скорости, близкой к нативной. Во-вторых, сообщество Linux отказалось принимать паравиртуализацию в стиле Xen в основное ядро, но включило KVM в 2007 году, мгновенно дав каждому дистрибутиву встроенный гипервизор. В-третьих, экосистема публичных облаков значительно вложилась: Google Cloud Engine запустился на KVM, AWS перешёл с Xen на архитектуру Nitro на базе KVM, а OpenStack стандартизировал KVM как эталонный гипервизор. Меньшие VPS-провайдеры выигрывают от этого гравитационного притяжения, потому что те же инструменты, которые управляют парками гиперскейлеров — libvirt, virtio-драйверы, cloud-init, — также работают на одной стойке коммодити-серверов.
Реальные характеристики производительности: CPU steal, IO и накладные расходы
На правильно сконфигурированном KVM-хосте ожидайте однозначных процентов накладных расходов на CPU по сравнению с bare metal, субмиллисекундных задержек в локальной сети и 80-95% от нативных IOPS диска при использовании virtio-blk или virtio-scsi с паравиртуализированным драйвером. Устойчивое CPU steal time выше 5% — канонический признак переподписки хоста и сильный сигнал к апгрейду.
Три числа важны для гостя KVM в продакшене. CPU steal time, отображаемое в /proc/stat в восьмом поле, измеряет процент времени, когда виртуальный CPU был готов выполняться, но физический CPU был занят выполнением других гостей. Всё ниже 1-2% — нормальный фоновый шум; устойчивые значения выше 5% означают, что хост переподписан и Ваша нагрузка дросселируется. IO wait, отображаемое такими инструментами, как iostat и top, измеряет процент времени, в течение которого CPU блокирован на диске или сети. С паравиртуализированными драйверами virtio и современным NVMe-хранилищем устойчивое IO wait выше 20% на нагрузке, которая должна быть ограничена CPU, — сильный признак того, что дисковая подсистема насыщена. Пропускная способность сети на virtio-net должна достигать 80-95% линейной скорости физической сетевой карты; что-либо существенно ниже указывает на неправильную настройку оффлоада или старый эмулируемый драйвер e1000.
Когда НЕ использовать KVM
KVM — неправильный выбор в трёх ситуациях: ультра-плотные контейнерные нагрузки, где доминируют накладные расходы ядра на VM; развёртывания, чувствительные к лицензированию Windows, где SPLA-цены Hyper-V существенно дешевле; и определённые сценарии низкозадержечного проброса оборудования, где SR-IOV или проброс GPU плохо поддерживаются на Вашей конкретной модели сетевой карты или GPU.
Для контейнерных микросервисов, которым не нужна изоляция ядра, контейнеры Linux (Docker, Podman, Kubernetes), запущенные напрямую на bare metal, упакуют в 3-5 раз плотнее любой VPS на базе KVM, потому что каждый контейнер — это просто группа процессов с пространствами имён и cgroups. Чувствительные к плотности недорогие VPS-провайдеры исторически выбирали OpenVZ по той же причине. Развёртывания с большим количеством Windows — особенно те, что используют лицензии Windows Server, приобретённые через SPLA, — иногда платят значительно меньше на Hyper-V, чем на KVM, из-за того, как Microsoft оценивает гостевые лицензии на конкурирующих гипервизорах. Наконец, некоторые сценарии проброса оборудования всё ещё проблематичны на KVM: проброс GPU требует чисто изолированных групп IOMMU, у некоторых потребительских сетевых карт нет поддержки SR-IOV, а PCIe-проброс NVMe-дисков иногда требует обходных решений ошибки сброса. Для 95% общих Linux VPS-нагрузок ничто из этого не применяется, и KVM — правильный выбор по умолчанию.
Как проверить, что VPS действительно на KVM
Внутри Linux-гостя выполните `systemd-detect-virt` — он должен напечатать `kvm`. Перепроверьте с помощью `lscpu` (строка 'Hypervisor vendor' должна гласить 'KVM') и `dmesg | grep -i kvm`. Если Вы видите 'OpenVZ', 'lxc' или 'VMware', Ваш провайдер использует другую технологию, даже если маркетинг утверждает иное.
Перед подписанием контракта запустите небольшой набор диагностических проверок на тестовом VPS. Запустите `systemd-detect-virt` для канонического вывода обнаружения. Запустите `cat /proc/cpuinfo | grep -E 'vmx|svm'`, чтобы убедиться, что расширения аппаратной виртуализации проброшены (некоторые провайдеры их обрезают, ломая вложенную виртуализацию). Запустите `uname -r`, чтобы убедиться, что Вы видите гостевое ядро, а не общее ядро хоста — на настоящем KVM VPS Вы можете установить другое ядро через `apt install linux-image-...` или `dnf install kernel-...` и загрузиться в него. На OpenVZ это невозможно. Наконец, проверьте `/proc/user_beancounters` — если этот файл существует, хост работает на OpenVZ, что бы маркетинг ни говорил.