Когда выбираешь VPS, провайдеры показывают цену, объём диска, количество ядер — и почти никогда не выносят на первый план тип виртуализации. А зря: именно он определяет, получите вы реальные ресурсы или разделите ядро с сотней соседей. На рынке две технологии делят большую часть предложений — KVM и OpenVZ. Разбираем, чем они отличаются, почему KVM стал стандартом индустрии и когда OpenVZ ещё имеет смысл.
Что такое виртуализация и зачем она нужна
Физический сервер — дорогая железяка. Держать его под одного клиента нерентабельно: большую часть времени он простаивает. Виртуализация позволяет нарезать один физический хост на десятки изолированных виртуальных машин — каждая со своими ресурсами, своей ОС, своим окружением.
Технически виртуализация делится на три принципиально разных подхода.
Полная виртуализация (full virtualization) — гипервизор эмулирует полноценное железо. Гостевая ОС не знает, что работает на виртуальной машине. Сюда относится KVM, VMware ESXi, Hyper-V.
Паравиртуализация (paravirtualization) — гостевая ОС знает о гипервизоре и взаимодействует с ним напрямую через специальные драйверы. Производительность выше, но гостевую систему нужно модифицировать. Xen в режиме PV — классический пример.
Виртуализация на уровне ОС (OS-level / контейнеры) — не создаёт отдельных виртуальных машин. Вместо этого ядро хоста изолирует процессы через namespace и cgroups. Все «серверы» разделяют одно ядро. OpenVZ, LXC, Docker — все здесь.
KVM занимает особое место: формально это полная виртуализация, но реализована она внутри ядра Linux — без отдельного гипервизора на выходе. Подробнее об этом — в расширенном обзоре технологий виртуализации.
Что такое KVM
KVM — Kernel-based Virtual Machine. Это модуль ядра Linux, который превращает само ядро в гипервизор. Появился в 2007 году, в 2.6.20 был включён в mainline Linux, и с тех пор это встроенная часть любого современного дистрибутива.
Работает KVM на базе аппаратных расширений процессора — Intel VT-x и AMD-V. Без них KVM не запустится вообще. Именно эти расширения позволяют гостевой ОС выполнять привилегированные инструкции напрямую на железе, без программной эмуляции — отсюда высокая производительность.
Схема работы выглядит так: ядро Linux с модулем KVM выступает как гипервизор (Type 1.5 — не классический Type 1 вроде VMware ESXi, но и не Type 2, установленный поверх ОС). Каждая виртуальная машина получает эмулированное железо через QEMU, который работает в user-space. QEMU занимается устройствами ввода-вывода — диском, сетью, видео. Ядро Linux при этом планирует задачи гостевых ВМ как обычные процессы.
Практически это означает следующее:
- Каждая ВМ на KVM — полноценная изолированная машина с собственным ядром
- Ресурсы (CPU, RAM, диск) выделены жёстко — соседи не могут их занять
- Можно установить любую ОС: Linux любого дистрибутива, FreeBSD, Windows Server
- Полный контроль над настройками ядра внутри ВМ
- Docker, WireGuard, кастомные модули ядра — всё работает без ограничений
KVM используют все серьёзные облачные провайдеры: AWS (под капотом Nitro, основанный на KVM), Google Cloud, Яндекс Облако, большинство российских VPS-хостингов. Это де-факто стандарт индустрии. Посмотреть актуальный список российских провайдеров с KVM можно в каталоге VPS/VDS.
Что такое OpenVZ
OpenVZ — технология контейнерной виртуализации на уровне ОС, разработанная Parallels (ныне Virtuozzo) в начале 2000-х. В отличие от KVM, OpenVZ не создаёт отдельных виртуальных машин с собственным ядром — все контейнеры используют одно общее ядро хостовой машины.
Изоляция достигается через механизмы Linux-ядра: namespaces (изолируют PID, сеть, файловую систему), cgroups (ограничивают потребление ресурсов), OpenVZ-специфичные патчи. Каждый контейнер видит только свои процессы, свою сетевую конфигурацию, свою файловую систему — но ядро при этом одно на всех.
Главное следствие: всё, что требует работы с ядром, — под вопросом. Менять параметры ядра (sysctl) — частично. Загружать кастомные модули ядра — нет. Запускать Docker — с оговорками, и то не всегда. WireGuard — только если хостовое ядро содержит нужный модуль.
OpenVZ долгое время существовал как форк ядра с собственными патчами, которые нужно было применять вручную и которые постоянно отставали от mainline. Начиная с версии OpenVZ 7 (Virtuozzo 7) проект перешёл на vanilla-ядро с минимальными патчами — ситуация улучшилась, но ограничения остались.
Коммерческое продолжение OpenVZ — Virtuozzo — используется рядом крупных провайдеров. Технически это то же самое с дополнительными инструментами управления.
KVM против OpenVZ: сравнительная таблица
| Параметр | KVM | OpenVZ |
|---|---|---|
| Тип виртуализации | Полная (аппаратная) | Контейнерная (ОС-уровень) |
| Изоляция ядра | Полная — у каждой ВМ своё ядро | Частичная — одно ядро на всех |
| Выделенные ресурсы CPU | Гарантированы | Зависит от провайдера, часто overcommit |
| Выделенная RAM | Гарантирована | Мягкие лимиты, возможен overcommit |
| Swap | Собственный, настраиваемый | Ограничен или отсутствует |
| Поддерживаемые ОС | Любые: Linux, Windows, FreeBSD | Только Linux (то же ядро что у хоста) |
| Windows Server | Да | Нет |
| Docker | Нативно, без ограничений | С ограничениями, не всегда работает |
| WireGuard | Да | Только если есть в ядре хоста |
| Кастомные модули ядра | Да | Нет |
| sysctl / настройки ядра | Полный доступ внутри ВМ | Частичный, зависит от провайдера |
| Накладные расходы | ~5–10% на виртуализацию | Минимальные (~1–3%) |
| Плотность на хосте | Ниже | Выше — можно уместить больше контейнеров |
| Цена для клиента | Выше (обычно на 20–40%) | Ниже |
Почему KVM выигрывает у OpenVZ
Разница не только в наборе функций — она в самой природе изоляции.
Реальные выделенные ресурсы. На KVM провайдер не может продать вам 2 ядра и тихо подселить ещё 50 таких же клиентов на те же два ядра. Ядра зарезервированы за вашей ВМ — физически. В OpenVZ overcommit — распространённая практика: ресурсы выделяются «мягко», и при нагрузке всех соседей ваш сервер просто тормозит.
Изолированное ядро. Баг или эксплойт в ядре хоста при OpenVZ потенциально затрагивает все контейнеры. В KVM гостевые ВМ изолированы друг от друга и от хоста — взломать соседа через общее ядро невозможно по архитектуре.
Любая операционная система. Для Windows Server, FreeBSD или нестандартного Linux с кастомным ядром — только KVM. OpenVZ жёстко привязан к ядру хоста.
Полноценный swap. В OpenVZ swap часто недоступен или ограничен политикой провайдера. На KVM вы сами настраиваете swap через стандартные механизмы Linux.
Docker и современные инструменты. Docker требует Linux namespaces и cgroups — и в OpenVZ это работает с оговорками. Kubernetes, WireGuard, любые инструменты, требующие ядерных модулей, — на KVM работают без проблем, в OpenVZ — как повезёт. Если вы разворачиваете современный стек, тип виртуализации — первый вопрос, который стоит задать провайдеру.
Предсказуемая производительность. Когда ресурсы гарантированы, вы можете строить нагрузочные тесты, планировать мощности, выставлять SLA. С OpenVZ это сложнее — слишком много зависит от того, что делают соседи в данный момент.
Когда OpenVZ ещё имеет смысл
OpenVZ не устарел и не бесполезен. У него есть своя ниша, и в ней он работает хорошо.
Дешёвые одноразовые задачи. Нужен сервер на неделю под парсинг или тест — OpenVZ-тариф за 100 рублей справится. Переплачивать за KVM-изоляцию смысла нет.
Простые PHP-сайты и статика. Если вы хостите WordPress без Docker, без кастомных модулей ядра, без специфичных требований — OpenVZ закроет задачу. Исторически на OpenVZ работала большая часть российских хостингов начального уровня.
Провайдер гарантирует ресурсы. Не все провайдеры злоупотребляют overcommit. Часть использует OpenVZ с жёсткими лимитами — тогда разница в практике минимальна, а цена ниже.
VPN без WireGuard. OpenVPN работает в OpenVZ-контейнере без проблем — это userspace-решение, ядро не нужно.
Смотреть на OpenVZ стоит только если провайдер честно говорит, что ресурсы гарантированы, и если задача не требует ничего кроме базового Linux. Для всего остального — KVM.
Что выбрать на практике
Если задача — продакшн, всегда KVM. Без исключений. Сайт, база данных, API, VPN для сотрудников, любой сервис с реальными пользователями — KVM. Разница в цене (обычно 20–40%) окупается предсказуемостью и отсутствием «эффекта соседа».
Если задача — разработка и тестирование без строгих требований к изоляции, одноразовые скрипты или бюджет в приоритете — OpenVZ вполне справится.
Для тех, кто выбирает между облачным VPS и классическим, тип виртуализации — не единственный параметр. Облачные платформы добавляют автомасштабирование, managed-базы данных, CDN. Но базовый уровень — KVM — там тоже.
Практический совет: при выборе провайдера сразу проверяйте тип виртуализации в технических характеристиках тарифа. Если не указано — спрашивайте в поддержке. Если провайдер уклоняется — это само по себе сигнал. Сравнение провайдеров с указанием технологий доступно в каталоге хостингов.
KVM-провайдеры в России: кто работает на правильной технологии
Большинство серьёзных российских VPS-провайдеров давно перешли на KVM. Вот проверенные варианты, которые присутствуют в нашем каталоге.
Aéza — молодой провайдер с агрессивными ценами, KVM на всех тарифах. Несколько локаций в Европе и России. Популярен у разработчиков за простой интерфейс и быстрый деплой.
AdminVPS — российский провайдер с KVM, широкий выбор тарифов от базовых до выделенных серверов. Хорошо подходит для проектов, где нужна российская юрисдикция.
Selectel — один из крупнейших российских облачных провайдеров. KVM-виртуализация, собственные дата-центры в России, широкий набор managed-сервисов. Подходит для серьёзной инфраструктуры.
Timeweb Cloud — облачная ветка Timeweb, полностью на KVM. Удобная панель управления, автоматические бэкапы, несколько локаций.
Помимо этих четырёх, KVM используют 4VPS и ishosting. Полный список с фильтрацией по типу виртуализации — в каталоге VPS/VDS. Для задач, где нужны выделенные ресурсы без соседей, стоит также смотреть в сторону выделенных серверов — там виртуализация вообще не нужна.
Ну и в заключение
KVM стал стандартом не случайно: аппаратная изоляция, гарантированные ресурсы, поддержка любых ОС и современных инструментов — это не маркетинг, а архитектурные свойства технологии. OpenVZ хорошо решает дешёвые задачи без специфичных требований, но там, где важна предсказуемость, — выбора нет.
При выборе VPS не ленитесь искать строчку «тип виртуализации» в характеристиках. Если её нет — это уже вопрос к честности провайдера. Технические детали KVM задокументированы на linux-kvm.org — там же можно найти бенчмарки и сравнения с другими гипервизорами.
