Виртуализация в России — тема горячая. VMware ушёл, Hyper‑V под вопросом, Proxmox — открытый, но не «суверенный». Я задался вопросом: а можно ли написать платформу управления KVM с нуля, с полным контролем ресурсов через cgroups v2, без единой строки GPL‑кода?
Спойлер: да. Встречайте Eskvisor — мой проект, переросший в зарегистрированную в Роспатенте программу для ЭВМ. Под капотом — архитектура, грабли с cgroups, и почему полностью суверенный проект был мертворожденным.
Темы
Почему возникла идея, как велась разработка и что там с импортозамещением
Как я нативно внедрил cgroups v2 для полного контроля ресурсов системы с гарантией
Почему проект оказался мертворожденным
Почему возникла идея , как велась разработка и что там с импортозамещением
В надежде среди мыслительных процессов найти ту самую идею стартапа, которая «выстрелит», я пришел к мысли: в РФ сейчас тренд на отечественные разработки. Учитывая также мой опыт в работе в компании в РФ, которая специализируется на продуктах, связанных с виртуализацией, я понял — надо делать, это можно будет продать.
Но к разработке я приступил не сразу, перед разработкой тщательно изучил рынок. Полностью отечественных проектов в принципе нет, а если они есть — то имеют тяжелое легаси, которое само по себе дороже поддерживать. Большинство проектов(не будем называть имён) чаще всего основываются на OpenSource решениях, а те, в свою очередь, основываются на libvirt. И выходит так, что коммерческая компания со своим штатом программистов, вместо того, чтобы предложить действительно суверенный софт — берет OpenSource, немного его шлифует, клеит свою наклейку и продает как «отечественное решение», где из отечественного лишь верхнеуровневая доработка, но чаще всего — без своей глубокой реализации. Так и клепают год за годом «убийц VMware». Мой проект также был основан на libvirt, но я сознательно отказался от копирования чужих решений. ИИ — только для ускорения кодогенерации, не более.
Проект был полностью написан мной с нуля, на протяжении 45+ дней непрерывного кодинга (а до этого — анализа рынка и конкурентов) с выполнением своего минимального функционала, включая фишку контроля ресурсов через cgroup v2.
Возникает риторический вопрос: если я один смог накинуть ядро кода, лишь немного капнув в этом направлении, включая нативный контроль ресурсов через cgroup v2, чем занимаются целые штаты программистов у крупных вендоров?
Ведь одно дело — разработка по-настоящему сложной и зрелой системы, например, живой миграции ВМ между хостами (это нетривиальная задача, требующая огромных ресурсов; я, кстати, тоже смог её в минимальном функционале реализовать, но поддерживать такую махину в одиночку, особенно на старте и для крупных вендоров, было бы архи-сложно, поэтому я выпилил большую часть кода).
И совсем другое — взять готовое OpenSource-решение, слегка его зашлифовать и наклеить свой логотип.
Неужели продукту, который на 90% состоит из OpenSource-компонентов (и чьи критические баги за вас исправляет всё мировое сообщество), нужен целый штат программистов, чтобы делать из него «импортозамещение»?
Как я внедрял нативное использование cgroup v2 для полного контроля ресурсов системы с гарантией
Ключевая проблема большинства платформ виртуализации — номинальное ограничение ресурсов. Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время. В результате дашборд показывает честные 70% (потому что именно столько мы записали в БД), а по факту система потребляет 80%, 90% или вообще всё, что есть.
Я пробовал решить проблему хранением метрик в JSON — написал систему для трекинга и будущих интеграций. Эффективность оказалась нулевой: мы лишь фиксировали проблему, но не решали её.
Единственное работающее решение — cgroups v2. Эта технология ограничивает ресурсы на уровне ядра Linux. Бесполезно пытаться через libvirt увеличить доступные мощности — cgroup просто не отдаст лишнее, даже если создать новую ВМ с большим количеством ресурсов(например 4 vCPU) но закинуть ее в limit на 2 ядра — ВМ не сможет использовать больше 2 ядер
В моей реализации при создании ВМ мы:
Вычисляем PID процесса QEMU/KVM (по имени из конфигов libvirt)
Добавляем этот PID в заранее созданный пул ресурсов
Пул уже имеет жёсткие лимиты CPU и RAM на уровне cgroups
Теперь ВМ физически не может выйти за рамки. Дашборд показывает реальное положение, а не то, что «должно быть».
Модуль управления cgroups v2 в Eskvisor
Ядро ресурсного контроля платформы — модуль pycgroup, реализующий прямое взаимодействие с иерархией cgroups v2. Модуль построен по принципу трёхуровневой абстракции: контроллеры (CPUController, MemoryController, PidController) → фасад PYCGroup → бизнес‑логика агента.
CPUController управляет лимитами через cpu.max и cpu.weight, поддерживая установку ограничений в процентах или ядрах. Ключевая особенность — метод get_cpu_available_cores, вычисляющий остаточный ресурс пула для планирования новых ВМ.
MemoryController оперирует контроллерами memory.max, memory.high и memory.min для жёстких, мягких и гарантированных лимитов памяти.
Иерархическая модель разделяет пулы (группы ВМ) и контейнеры (отдельные ВМ). Дочерняя cgroup не может превышать лимиты родительской — это обеспечивает предсказуемое распределение ресурсов.
Для сохранения состояния разработаны bash‑скрипты save.sh/restore.sh с интеграцией в systemd (таймер на каждые 6 часов). Скрипт migrate.sh через rsync переносит конфигурации между хостами, сохраняя все настройки cgroup.
Модуль полностью автономен, не требует перезагрузки и работает поверх стандартного KVM/libvirt без модификации ядра. Более подробно изучить модель и в целом проект можно в репозитории GitHub.
Почему проект оказался мертворожденным
Все до безобразия просто, рынок поделен между крупными игроками, даже имея хорошо написанный код и полностью с нуля разработанную архитектуру — это не дает никакой гарантии на то, что проект будет интересен хоть кому‑то. Параллельно с разработкой я рассылал множество писем различным компаниям, интеграторам, включая гос заказы(более 80 писем, звонки и прочее), где я писал всем с одним предложением — все подключим и сделаем абсолютно бесплатно, нам нужна будет лишь обратная связь, а при заинтересованности в коммерческом контракте — постараемся получить и лицензию Минцифры, включение в реестр отечественного ПО и так далее. Модель была максимально простой — если понравится, возьмите, если не понравится — нам ничего не нужно.
Всем спасибо, кто дочитал до этого места. Если вы из компании, которой надоели «отечественные обёртки над OpenSource», или просто хотите посмотреть на честный код — репозиторий открыт. Мне же — собирать карму и доделывать Atomic AI Cloud. Увидимся там
