Введение

Многие системные администраторы перед решением задачи при аренде VPS выбирают оптимальный набор инструментов и, хотя на первый взгляд выбор очевиден не всё так просто.  KVM предлагает полную виртуализацию, OpenVZ — контейнерную. Уже из этого следует, что основные различия в архитектуре будут на прямую влиять на изоляцию затраченных ресурсов, производительность и круг решаемых задач.

Большинство хостинг провайдеров используют обе технологии. Кстати в российском наборе терминов за ними закреплены даже разные названия. К примеру, VPS ассоциируется с OpenVZ, а VDS — с KVM. Если вдуматься и понять, то архитектурные различия позволят выбрать не только подходящий тариф, но и предвидеть как будет вести себя система под нагрузкой, а также оценить риски от нахождения рядом с другими пользователями и точно знать, когда от экономии на OpenVZ возникнут проблемы. Теперь понятно, что такое разделение неслучайно.

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

Основная часть

Значительное расхождение в архитектуре: что лучше общее или собственное ядро?

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

KVM использует аппаратную поддержку виртуализации через расширения процессора (Intel VT-x или AMD-V). У каждой виртуальной машины своё ядро, загружаемое независимо, и гипервизор лишь предоставляет аппаратные ресурсы. Гостевая ОС думает, что работает на реальном железе.

Это различие запускает цепочку последствий. В OpenVZ гостевая среда прочно связана с ядром хоста. Установить дистрибутив с другой версией ядра или собрать модуль под заказ, прямо скажем задача от непростой до невыполнимой. В KVM этого ограничения нет, так как внутри виртуальной машины можно загрузить любое ядро, включая модифицированное для специфических задач.

Именно поэтому OpenVZ работает только с Linux-дистрибутивами, тогда как KVM позволяет запустить Windows Server, FreeBSD, или другую нетрадиционную среду. Организация системы определяет какие функции возможны.

Разграничение ресурсов: меж сетевой рубеж

Организация системы задаёт и уровень изоляции. В KVM каждая виртуальная машина получает автономный набор средств: собственное адресное пространство памяти, виртуальные диски, сетевые интерфейсы. Гипервизор контролирует доступ к аппаратному обеспечению, и гостевая система не может выйти за отведённые рамки без прямого разрешения.

OpenVZ обеспечивает изоляцию на уровне пространств имён и контрольных групп. Каждый контейнер работает в своём пространстве, поэтому чужие процессы он не видит. Файловая система автономна, сетевой стек имеет собственные интерфейсы и правила фильтрации сетевого трафика (iptables). Тут проходит очень тонкая грань. Поскольку ядро общее, любые уязвимости в нём вполне возможно затронут все контейнеры. Администратор сервера имеет полный доступ к содержимому контейнеров, что для пользователя означает отсутствие полной приватности.

Проще говоря, на практике разница видна, когда сервисы тесно связаны с ядром. NFS-сервер внутри OpenVZ контейнера - это задача с трудностями, так как требует загрузки модулей ядра. KVM позволяет запустить NFS без ограничений, поскольку модули загружаются в собственное ядро виртуальной системы.

Избыточное выделение ресурсов и источники помех в системе

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

В KVM виртуальная машина получает гарантированный базовый объём ресурсов. Если провайдер к примеру, выделил 4 ГБ памяти, то вся она зарезервирована. В OpenVZ ситуация складывается по-иному: провайдер хостинга может продать контейнеров больше, чем позволяет физическая память, рассчитывая на то, что не все клиенты одновременно используют пиковую нагрузку. Добросовестные провайдеры контролируют этот процесс, но технически злоупотребление возможно.

Для приложений, чувствительных к задержкам (базы данных, игровые серверы, системы реального времени), непредсказуемость OpenVZ может стать ключевым моментом. KVM обеспечивает более прогнозируемую эффективность, хотя и с меньшей плотностью размещения.

Управление ресурсами и динамика изменений

Исходя из прошлого OpenVZ предлагает менять настройки параметров контейнера более гибче в зависимости от ситуации. Можно увеличить лимиты памяти, дискового пространства, или CPU не прибегая к перезагрузке. Для задач, где нагрузка меняется непредсказуемо, это весомое преимущество.

KVM требует перезагрузки виртуальной машины для применения изменений в конфигурации оборудования. Увеличение объёма диска обычно делают вручную, да и подключить его во время работы системы получается не всегда. С другой стороны, фиксированная настройка будет более предсказуема.  А это означает, что выделенные ресурсы останутся закреплёнными.

Выбор будет зависеть от модели нагрузки. Динамика OpenVZ будет удобнее для веб-приложений с сезонными пиками. Для надёжной рабочей среды с предсказуемым постоянным потреблением лучше подойдёт KVM.

Практические сценарии: что выбрать

OpenVZ остаётся предпочтительным выбором для лёгких веб-приложений, тестовых окружений, небольших проектов с ограниченным бюджетом. Если приложение не требует специфических модулей ядра, не запускает Windows и готово терпеть возможные проблемы близости элементов, тогда экономия может быть оправдана.

KVM необходим, если требуются нестандартные ядра, или модули, где приложение критично к задержкам и необходима надёжное отделение для соответствия законам и правилам (compliance-требования). Виртуализация Windows, FreeBSD, запуск Docker с полным контролем над ядром — с такими задачами лучше справится KVM.

Отдельный сценарий — миграция. OpenVZ долгое время предлагал динамическую миграцию контейнеров через CRIU, что было преимуществом для решений на основе объединения ресурсов. KVM также поддерживает непрерывность сервисов (live migration), но требует общей системы хранения. Для малых установок разница незначительна.

Заключение

KVM и OpenVZ не являются взаимозаменяемыми технологиями. Различие в организации системы, а именно общее ядро против собственного — определяет всё остальное: уровень изоляции, перечень совместимых ОС, гибкость управления ресурсами и экономику хостинга.

OpenVZ выигрывает в плотности размещения и стоимости, но уступает за это более тонкой границей приватности и ограничениями на запуск нестандартных конфигураций. KVM предлагает полноценную изоляцию и свободу выбора операционной системы, но требует больше ресурсов и менее гибок в динамическом изменении параметров.

Опираясь на выше сказанное можно сделать вывод что для лёгких Linux-приложений с ограниченным бюджетом OpenVZ остаётся предпочтительным выбором. Для всего, что требует предсказуемости, изоляции или нестандартной конфигурации, KVM — безальтернативный выбор. Разбираясь в архитектуре системы можно не только сделать правильный выбор, но и понять, как она будет себя вести в критический момент.

VPS-сервер даёт отдельную ОС и административный доступ без аренды целого физического узла. Такой формат подходит сервисам с постоянным адресом и предсказуемой нагрузкой. При выборе такого сервера важны технология виртуализации, ограничения CPU, памяти, диска и сети, а также то, где проходит граница ответственности. У двух тарифов с одинаковым описанием эти условия могут конкретно отличаться.

Что такое VPS простыми словами?

VPS это виртуальная машина с гостевой ОС, которую физический хост запускает через гипервизор. Пользователь получает административный доступ, IP-адрес, виртуальные диски и заданные лимиты ресурсов, а провайдер обслуживает физический хост и слой виртуализации. Реальная изоляция и гарантии зависят от технологии виртуализации, модели распределения и условий тарифа.

Что входит в услугу и что остаётся вашей задачей

Физический сервер делят на несколько виртуальных машин, каждая из которых запускает собственное ядро ОС, хранит отдельную файловую систему и работает со своими пользователями, процессами и сетевыми настройками. Процессы одной машины не видят файлы и память другой, хотя оборудование у всех гостей общее.

Тариф VPS обычно включает vCPU, RAM, диск, IP-адрес, лимит трафика либо скорость порта. Панель провайдера управляет питанием виртуальной машины, переустановкой образа и консолью. Она не заменит вашу работу внутри ОС: веб-сервер, база данных, обновления, учётные записи и резервные копии остаются задачей администратора, если договор не обещает иное.

Административный доступ даёт свободу выбора ПО, но вместе с ней и всю ответственность за то, что внутри: ошибка в условном sshd_config, открытая база данных или удалённый файл находятся внутри гостевой системы, поэтому просто наличие гипервизора их не исправит. Перед заказом нужно проверить, кто устанавливает обновления, реагирует на инциденты и восстанавливает данные.

Как гипервизор создаёт несколько серверов на одном хосте

На Linux-хосте модуль KVM использует аппаратные расширения CPU и открывает пользовательскому пространству API для работы с виртуальными машинами. Каждая VM обычно работает как отдельный процесс QEMU. Он выполняет код гостя через KVM и предоставляет модель устройств. Слой управления, обычно libvirt, задаёт vCPU, память, диски, сетевые интерфейсы и правила запуска. Созданный таким способом VPS сервер видит виртуальное оборудование и загружает собственную ОС как отдельную машину.

Схема этих слоёв такая:

CPU, RAM, NVMe и NIC физического хоста → ядро Linux с KVM → процесс QEMU и virtio-устройства → гостевая ОС → приложение

Планировщик хоста выделяет каждой vCPU процессорное время наравне с потоками других виртуальных машин, а закрепление за физическим ядром, квоты и оверкоммит зависят от конфигурации площадки. С памятью и устройствами так же, то есть гость работает не с железом напрямую, а с тем, что даёт ему процесс QEMU. Память живёт в его адресном пространстве, дисковые и сетевые операции идут через паравиртуальные очереди virtio.

Изоляция действует на уровне виртуальной машины, а физические CPU, накопители и сеть остаются общими. Поэтому для сравнения вариантов обычно нужны правила распределения ресурсов и тест на своей нагрузке, потому что просто факта наличия гипервизора недостаточно.

Что означают vCPU, RAM, NVMe, IOPS и полоса сети

Число vCPU показывает, сколько виртуальных процессоров видит гостевая ОС. Частоту, поколение CPU, квоту процессорного времени и степень конкуренции на хосте нужно выяснять отдельно. Для постоянной вычислительной нагрузки важны длительная производительность и задержка планирования. В Linux показатель %steal показывает время, когда гостевая vCPU была готова к работе, но гипервизор не дал ей процессор. Причину замедления одна эта метрика не покажет.

Объём RAM задаёт доступную гостю память. Поведение при её нехватке зависит от гарантий тарифа, ballooning, политики оверкоммита и swap на хосте. Частая выгрузка страниц увеличивает задержки, поэтому базе данных полезнее гарантированный объём с запасом под рабочий набор, чем большое номинальное число без условий.

NVMe обозначает протокол доступа к накопителю. Производительность определяют лимиты IOPS и throughput, размер блока, глубина очереди, доля чтения и записи. На результат также влияют кэширование и конкуренция. Лимит в 3000 IOPS при блоке 4 КиБ даёт примерно 11,7 МиБ/с случайного потока. Реальная цифра будет ниже из-за файловой системы и очередей, а последовательное чтение ограничит уже лимит throughput.

У сети есть несколько границ: скорость порта, трафик, пакеты в секунду, исходящий лимит и маршрут до пользователей. В тарифах Cloud VPS обычно есть API, почасовое создание ресурсов и сетевые сервисы. Но сможете ли вы быстро добавить ресурсы в пик и есть ли под это физический резерв – зависит от договора, а не от названия тарифа.

Чем VPS отличается от виртуального хостинга и выделенного сервера?

VPS даёт собственную ОС, административный доступ и лимиты ресурсов, тогда как виртуальный хостинг делит готовое окружение без полного контроля. Выделенный сервер предоставляет весь физический узел одному клиенту. Managed-тарифы и гарантии CPU, памяти или диска у разных поставщиков могут заметно различаться.

Unmanaged, managed и панели: кто за что отвечает

В unmanaged-тарифе провайдер обычно обслуживает физический хост, гипервизор, питание и внешнюю сеть, а пользователь управляет гостевой ОС: создаёт учётные записи, устанавливает пакеты, закрывает порты, следит за журналами и обновляет приложения. Точные границы ответственности задаёт договор, особенно для DDoS-защиты, резервных копий и аварийного доступа.

В managed-тарифе часть операций берёт на себя поставщик, но точный состав услуги всё ещё определяет договор. Базовый вариант может включать только первичную установку, а расширенный добавляет мониторинг, обновления, реакцию на алерты и восстановление. До заказа стоит проверить часы работы поддержки, допустимый стек, число обращений, способ эскалации и перечень действий при сбое.

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

Проще всего свести всё это в одну таблицу и посмотреть, где не окажется владельца. В строках – ОС, firewall, приложения, мониторинг, копии и восстановление, в столбцах – кто отвечает, за какой срок реагирует и каким пунктом договора это закреплено. Ярлык managed становится проверяемым только после того, как такая таблица заполнена целиком.

Для чего используют VPS и где он не подходит

Небольшие сайты, API, боты, системы мониторинга, Git-раннеры и тестовые среды часто помещаются на одной виртуальной машине. Им нужен постоянный IP-адрес, контроль пакетов и возможность запускать фоновые процессы. При умеренном рабочем наборе такой VPS сервер проще в эксплуатации, чем выделенный узел, а тариф можно сменить после измерений.

У тяжёлой базы данных постоянная загрузка vCPU, большой объём RAM и интенсивная запись, поэтому конкуренция за общие ресурсы бьёт по ней сильнее всего. Обучение и инференс упираются в ускоритель, а обычный тариф VPS его не включает. Сервису с резкими пиками может больше подойти облачная группа экземпляров.

В таблице собраны типовые варианты. Числа здесь – отправная точка для теста, проверять их всё равно нужно на своей нагрузке.

Проверять всё равно придётся прогоном, так как приложение с 2 vCPU и 4 ГиБ RAM может работать устойчиво при одном профиле запросов и упираться в память при другом. Решение обычно принимают по рабочему набору, p95/p99 задержки, очередям диска и запасу до лимитов.

Как подобрать тариф без переплаты за лишние ядра

Выбор начинается с измерений текущей системы. Для CPU нужны загрузка по ядрам, длительность насыщения и задержка запросов, для памяти – рабочий набор, page faults и swap. Диск оценивают по IOPS, throughput и p95/p99 latency, сеть по средней и пиковой скорости, PPS и исходящему трафику. Если исходной системы нет, начните с минимального тарифа и прогоните воспроизводимый тест. Если упрётесь в лимит, увеличьте только тот ресурс, который его создал, и повторите замер.

Например, тариф может включать 2 vCPU, 4 ГиБ RAM, 60 ГиБ диска, 3000 IOPS и порт 100 Мбит/с. Без модели CPU, квоты, типа диска, лимита throughput и правил трафика этих цифр недостаточно для оценки. VPS или VDS сервер в названии тарифа тоже ничего не говорит о способе виртуализации, поэтому смотреть нужно договор и технические параметры.

Базовый профиль после запуска составляют по данным за обычный рабочий период. В него входят загрузка CPU, %steal, свободная память, swap, дисковая задержка, ошибки файловой системы, сетевые потери и прикладные p95/p99. Переход на более крупный тариф логичен, если ресурс регулярно приближается к лимиту, а одновременно растут задержки или число ошибок. Обычный короткий пик не требует постоянной оплаты лишних ресурсов.

Расположение площадки определяет задержку до пользователей, а иногда и то, где по закону можно хранить данные. В условиях резервного копирования должны быть названы частота, срок хранения, место размещения и время восстановления. До миграции также важно узнать, как увеличивается диск, меняется тариф, выдаются адреса и выполняется перенос между регионами.

Для каких задач подходит VPS?

1. Сайты, API и небольшие базы с измеримым и относительно стабильным профилем нагрузки.

2. Боты, мониторинг, Git-раннеры и тестовые среды, которым нужен постоянный сетевой узел.

3. Сервисы с собственной ОС и административным доступом, если их лимиты подтверждены тестом.

Что настроить сразу и чего провайдер не сделает за вас

При первом подключении SSH-отпечаток желательно сверить через доверенный канал. Затем нужно создать отдельную учётную запись, добавить публичный ключ и проверить новый вход. Парольную авторизацию и прямой вход root лучше отключить, но только при наличии рабочего ключа и резервного доступа через консоль.

Firewall открывает лишь необходимые входящие порты, пакеты ОС и приложений обновляются по выбранному графику, а сервисы работают с минимальными привилегиями. Стоит иметь в виду, что VPS изолирует машину, а не код внутри неё. Уязвимый плагин, утёкший токен или ошибочное правило доступа остаются вашей зоной ответственности.

Резервная копия должна пережить потерю виртуальной машины и учётной записи управления, поэтому данные хранят отдельно, шифруют и периодически восстанавливают в чистое окружение. Успешный статус задания подтверждает создание копии, а тест восстановления показывает её пригодность.

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

VPS, VDS, облако и dedicated: как выбрать модель

VPS и VDS на рынке часто используются как близкие маркетинговые названия, поэтому сами буквы не указывают на то, выделены ли ядра, разрешён ли оверкоммит и какие лимиты действуют для диска. Если нужен виртуальный сервер VPS с предсказуемой производительностью, проверять следует модель CPU, квоты, гарантии памяти, IOPS, полосу сети и SLA, а не то, что написано в карточке тарифа.

Публичное облако полезно, когда инфраструктуру нужно создавать через API, распределять по зонам и связывать с балансировщиками или управляемыми сервисами. Расчёт стоимости у такой модели сложнее, а зависимость от платформы выше. Один экземпляр без резервирования остаётся точкой отказа.

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

Если ресурсы стабильно упираются в лимит, следующий шаг – более крупный тариф или переход на dedicated. При непредсказуемых пиках и работе в нескольких зонах выигрывает облако. Когда заниматься администрированием ОС некогда или незачем, задачу закрывает managed-платформа. Выбор определяют требования к контролю, скорости восстановления и цене простоя.

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

Под нагрузкой проблемы проявляются внезапно: API начинает отвечать с задержками, база данных упирается в I/O, сервис падает в самый неподходящий момент. Потеря данных из-за отсутствия бэкапов или срочная миграция перед дедлайном – реальные риски для проектов, которые выбирают инфраструктуру только по цене.

Как считать полную стоимость VPS?

Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.

Чек-лист: признаки надёжного VPS

• SLA не ниже 99,9%

• NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами

• Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов

• Автоматические бэкапы с проверенным восстановлением

• Поддержка 24/7 с заявленным временем ответа

• Гарантированная пропускная способность сети

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

На контейнерной схеме CPU и I/O могут делиться между всеми на хосте, а степень изоляции зависит от настроек хоста, лимитов и политики провайдера. Современные контейнерные решения могут нормально работать под нагрузкой, если ресурсы распределены корректно. Если сосед по железу активно загружает физические ядра или диск, ваш контейнер может тормозить, а без доступа к хостовой стороне причину сложнее подтвердить.

Например, два тарифа могут иметь одинаковые характеристики: 4 vCPU и 8 ГБ RAM. Один сервер будет работать стабильно под нагрузкой благодаря корректным лимитам ресурсов и контролю плотности размещения VM, а другой может показывать просадки из-за высокой конкуренции за ресурсы на хосте.

CPU steal time (%st в top и vmstat) показывает, сколько времени виртуальный процессор ждал, пока гипервизор выделит ему физическое ядро. Проще говоря, это время, когда VPS хотел получить CPU, но физический ресурс был занят другими задачами на хосте. При нормальной конфигурации хоста показатель держится близко к нулю. fio и vmstat позволяют увидеть симптомы деградации (рост latency, steal time), но не позволяют однозначно подтвердить оверселлинг.

Сценарии, где разница решает

• PostgreSQL и MySQL под нагрузкой: нужна I/O-предсказуемость и стабильный RAM.

• Low-latency API: скачки задержки в правильно написанном сервисе могут быть связаны с CPU steal, I/O или нагрузкой на сеть, а не только с кодом.

• CI/CD-раннеры и k8s-ноды: всплески нагрузки у соседей не должны валить ваши сборки и поды.

Чек-лист: как проверить изоляцию у провайдера

• Тип виртуализации: KVM/Xen или OpenVZ/LXC?

•  vCPU гарантированы или мягкий лимит с троттлингом?

• Есть ли гарантии IOPS или диск работает в shared-режиме без ограничений?

• Публикует ли провайдер политику оверселлинга?

• Можно ли измерить steal time через vmstat или встроенный мониторинг?

Перед выбором тарифа пройдитесь по этому чек-листу. Маркировка «VDS» на сайте провайдера не гарантирует аппаратной изоляции, посмотрите тип гипервизора отдельно.

По данным исследования компании «Код Безопасности», уже 78% российских организаций выбирают отечественные средства виртуализации.

Ничего российского в KVM, XEN и bhyve нет вообще.  Средства управления – на сколько-то российские, само ядро виртуализации – opensource, читай «разработано в основном в США» или, для средств управления, то есть форков Proxmox - Proxmox Server Solutions GmbH расположен по адресу: Bräuhausgasse 37, Vienna, Austria.

Open Source Contributor Index : Rank and Organization
1 – Google, 6590 Active contributors
2 – Microsoft, 5364 Active contributors (без GitHub)
3 - Red Hat, 3908 Active contributors (без IBM)
4 – Amazon, 2465 Active contributors
5 – Intel, 2364 Active contributors

Есть и решения на базе OpenStack

OpenStack – это не гипервизор, а система управления гипервизорами, то есть она может управлять хоть Broadcom vCenter, хоть чем. Можно же было, перед тем как такое писать, посмотреть картинки в документации.

Здесь можно отметить, что многие российские платформы уже внедрили современные технологии оптимизации ресурсов: поддержка NUMA для эффективной работы с многопроцессорными узлами

С этого момента уже можно сказать, что «в статье все очень плохо».

Первое.
Non-uniform memory access (NUMA) в мире x86 существует больше 20 лет. В Linux kernel поддержку NUMA начали реализовывать с 2002. Что могли внедрить российские платформы из того, что используется в kernel уже больше 20 лет?

Второе.
Если начать читать про проблемы переключения задач в среде x86 с более понятной статьи  
Virtual Machine Resource Controls,
продолжить чтение на сайте Red Hat
Red Hat 6. CPU Scheduling
Red Hat 10. Chapter 27. Tuning scheduling policy

И заполировать статьей
Linux CPU Schedulers and Why They Are Important

То окажется, что у Linux достаточно большие проблемы с планировщиком задач, которые NUMA только усугубляет. Как, впрочем, и с Intel Hyper-Threading Technology, и с Intel Turbo Boost и AMD Precision Boost и вся эта группа настроек энергосбережения.
У всех эти проблемы, особенно в связи с последними движениями AMD и их микроархитектурой.
Linux kernel из коробок (Debian, Ubuntu, Centso, etc), скомпилированный из принципа «чтобы работало почти везде», вообще не очень оптимизирован по скорости, достаточно посмотреть результаты тестирования настроек в проекте Clear Linux
Final Benchmarks Of Clear Linux On Intel: ~48% Faster Than Ubuntu Out-Of-The-Box

Есть определенная ирония в том, что над ускорением Linux работали не какие-то энтузиасты из Apache Software Foundation, а самый проприетарнейший Intel.
Который и закрыл проект в июле 2025 - Intel Announces It's Shutting Down Clear Linux.

И еще больше иронии в том, что спустя два года «оптимизаций» Linux, с декабря 2023 по 1 января 2026, он стал работать медленнее на том же процессоре Intel, достаточно почитать свежую статью Two years after launch Intel Meteor Lake offers 93% of original performance on Linux, tests show.

Так что, и поддержкой NUMA занимаются не разработчики GUI поверх KVM, и с CPU планировщиками проблемы были и есть, и за два года с производительностью все как-то не так.

Проявляется это «не то, чтобы торможение» при хоть как-то нагруженном сервере. Немалая часть обычных пользователей с этим, скорее всего, не столкнется, или спишет проблемы на что угодно, кроме кривеньких настроек kernel «из коробки», и такой же кривенькой настройки планировщика «из коробки».
В некоторых нагруженных сценариях, вне зависимости от того, используется ли KVM, или используется контейнеризация, любая, и система управления контейнерами, NUMA вообще стоит выключить.
Иногда стоит выключить и HT.
И посмотреть на результаты.
Но, повторю, тут много зависит от того, устраивает ли вас ситуация с нагрузкой, снимаете ли вы вообще метрики нагрузок по процессорным ядрам, проводите ли анализ нагрузок (что считается) и загрузки (как эффективно балансируется). Это не так просто, потому что метрики KAVG (Kernel average latency) и GAVG (Guest average latency) в Linux отсутствуют, а без них не всегда понятно, где задержка – на вводе-выводе, или все же надо смотреть в CPU Wait (CPU Ready Time).
Load Average в Linux при этом показывает совсем не то, что рассказывают школьники друг другу, но про это хотя бы пишут, например в статье Linux System Load Average Spikes IO Wait Context Switching and Process Bottlenecks.

Как следствие, получается, что по реальной эффективности работы гипервизора в нагруженной среде платный Microsoft Hyper-V на Intel может оказаться дешевле, чем бесплатный KVM или бесплатный k8s.
И не только потому, что не везде есть множество высококвалифицированных низкооплачиваемых кадров.

Но уж точно, никакого супер-действия нет от «NUMA».

SpaceVM изначально ориентирован на сценарии с графическими рабочими станциями: платформа поддерживает как passthrough GPU для выделения целой видеокарты ВМ, так и технологию FreeGRID – собственную разработку для виртуализации ресурсов NVIDIA-GPU без риска лицензионной блокировки.

Кажется, КОАП не отменяли ?

Резюмируя, производительность российских гипервизоров уже находится на уровне, достаточном для многих корпоративных задач

За исключением того, что KVM, bhyve, и так далее, не являются российскими гипервизорами.

внедрение RBAC/2FA, о которых сказано выше, существенно снижает риски

Role-Based Access Control (RBAC) не имеет ни малейшего отношения к 2FA. Что там оно снижает – надо спросить у Аэрофлота и прочих взломанных, начиная от МТС и СДЭК.

Также важно строить резервное копирование на уровне приложений и данных, а не полагаться только на механизмы платформы.

Авторы принципиально не понимают что пишут, или не смогли написать прямо – в Linux не было и нет механизмов резервного копирования приложений, что из физических, что из виртуальных сред, из-за отсутствия механизма, аналогичного Microsoft Volume Shadow Copy Service (VSS). Функции файловой системы и ядра (freeze_bdev и thaw_bdev) есть, функционала приложений нет. Поэтому «механизмов платформы» нет принципиально, если только вы, конечно, не останавливаете сервис приложения целиком на время снятия снапшота файловой системы.
Паузы недостаточно, да и попробуйте поставить на паузу действительно нагруженную базу данных, потом расскажете, как прошло восстановление и сколько воспроизводились транзакции.
Одно дело снять ночью снапшот postgres в 1с, в которой было 1000 проводок за 8 рабочих часов, другое дело снять снапшот базы биллинга.

Заключение

Жаль, конечно, что две такие, вроде бы большие, статьи, да еще и с картинками, сводятся к рассказу «Продукт точно хороший, берите, не пожалеете».
В рассказах про Open source Linux вот-вот победит и Microsoft и IBM и всех. Кроме Google. Потому что проприетарный Android это другое, это не проприетарный Microsoft. 
В рассказах про импортозамещение есть красивые картинки и даже таблицы.
В реальности прибыль Microsoft, в том числе за счет сдачи в аренду времени под работу Linux серверов и прочего Opensource в облаке (Azure), в том числе Azure Kubernetes Service (AKS) и Azure Container Apps растет каждый год.
В Linux других проблем нет, кроме тех, что надо убрать из ядра поддержку Bcachefs. Не потому, что Bcachefs плохая, а потому, что разработчик Kent Overstreet два года назад кого-то в частной переписке назвал дурачком, и недостаточно хорошо и долго извинялся.

Надеюсь, в следующей статье авторы расскажут, почему Usergate лучше NSX и Microsoft Network Controller вместе взятых, а drbd лучше vSAN и S2D (Storage Spaces Direct), и как хорошо drbd работает с NVMEoF.
И почему для «импортозамещения» надо удвоить, если не утроить, парк техники, и почему рост капитальных и эксплуатационных затрат в 2.5 раза – только на пользу бюджетам.

STAY TUNED

Проблема заключается в следующем - всё работает, если kvm без эмуляции EDID, но тогда переключение занимает до 10 секунд, когда целый день туда-сюда щелкаешь, очень раздражает. Нашел такой же вариант, но с симуляцией EDID для быстрого переключения, но из-за этой эмуляции не будет работать включение-отключение распберри, т.к. на HDMI-порту всё время будет сигнал.

Уже сломал голову, как это реализовать, возможно, упускаю что-то очевидное. Буду рад любым идеям, возможно есть какой-то другой вариант решения проблемы. Аппаратно, программно - не важно, всё принимается)

Заранее спасибо!