Виртуализация в России — тема горячая. 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-компонентов (и чьи критические баги за вас исправляет всё мировое сообщество), нужен целый штат программистов, чтобы делать из него «импортозамещение»?
Абсурд ситуации усиливает один неподтверждённый, но показательный кейс (источник, увы, не могу раскрыть): некая российская компания с крупным контрактом на виртуализацию проводила миграции ВМ с помощью OpenSource‑решения без своих доработок на коммерческих платформах заказчика.
А теперь внимательно следим за контекстом:
------------------------------------------------------------------------------------------------------------------------------
Ситуация получилась такой, что заказчик заплатил за «отечественную разработку», функционала которой оказалось недостаточно, в итоге сверху этого команде пришлось использовать другое 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. Увидимся там
Комментарии (22)
ProFfeSsoRr
10.06.2026 16:01OpenSource под видом импортозамещения удобен всем сторонам, потому и существует: инженеры получают опыт, который смогут вписать в резюме, ну а "кто-то" получает деньги. Именно поэтому же и "свое, новое уникальное" решение ровно также никому и не нужно.
Eskander_007 Автор
10.06.2026 16:01Согласен. Это система где всем удобно, все походили на мероприятия, получили награды, подписали контракты и разошлись
schekinfs
10.06.2026 16:01а, не торопитесь. просто продолжайте, такое часто вот бывает, кажется, что все не так. дорогу осилит идущий. идея норм, хоть пилить еще много по обвязке чего нужно.
lamerok
10.06.2026 16:01Ни одна нормальная компания не будет связываться с непонятным челом или конторой Рога и Копыта, где работает один чел.
А как это потом им поддерживать, если вдруг вы пропадёт?
Тут вопрос в экономике. Вам надо с большой компанией договариваться, например продать или просто отдать долю им и они будут толкать ваше решение.
Когда есть альтернативы, всегда выберут большую контору.
Eskander_007 Автор
10.06.2026 16:01Да, абсолютно с вами согласен, я писал также множеству интеграторов с предложением о сотрудничестве. Но так или иначе отклика не последовало, зато опыт)
vmcore
10.06.2026 16:01когда один профессор математики американского университета решил сделать файловую систему (которая здравствует до сих пор) опытные люди дали ему в помощь одну оооочень большую корпорацию, для "партнерства". потому что было понятно, что ни один серьезный заказчик не будет работать даже с самым умным профессором, если он один. продукт - это не только хорошая идея. и даже хорошей реализации совершенно недосточно чтобы этот продукт стали покупать.
Eskander_007 Автор
10.06.2026 16:01Спасибо за отличный пример. Можно создать очень хороший продукт, но если не будет каналов доверия, даже самое передовое окажется никому не нужно
boolka989
10.06.2026 16:01Ваши наработки это максимум поделки студента для образовательных целей. Поздравляю вас, вы открыли для себя пару системных вызовов и осознали что заменить их из юзер спейса то еще велосипедостроение. Сама статья очень худая, даже то что есть можно было бы поддержать ну хоть минимум одним примером реального использования. О какой конкуренции с опен сорс решениями вообще можно говорить я даже не представляю…
Eskander_007 Автор
10.06.2026 16:01Прошу вас предоставить доказательную базу почему мои наработки это "поделки студента для образовательных целей", иначе ваш комментарий рискует превратиться в комментарии без ценности, ведь, я предполагаю, что вы подробно изучили проект перед тем как выдать свой вердикт, заранее благодарю.
P.S Проект - POC, и в статье я честно пишу, что он не взлетел по бизнес-причинам, основной функционал виртуализации на уровне агента полностью рабочий, что подтверждается автотестами: agent/client/tests/
dorne
10.06.2026 16:01У нас, видимо, открылся сезон антипиара открытых облачных платформ (особенно, суверенных), как идеи, и в принципе.
Видимо, с приходом ИИ стоимость эксплуатации и настройки всего этого добра на столько сократилась, что "проприетарные" вендоры секут это на корню, как идею, и, еще и приплачивают за это))))
Видимо, подгорает...
Stanislavvv
10.06.2026 16:01Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время.
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
Eskander_007 Автор
10.06.2026 16:01Теперь попробуйте провести эксперимент с десятками ВМ:
Укажите всем ограничения через -smp по числу ядер и оперативной памяти, запустите на всех нагрузку, посмотрите как со временем ВМ начнут вести себя, и вы явно заметите что одни ВМ начнут забирать больше ресурсов чем другие при указанных ограничениях, это и называется проблема шумного соседа, ваш флаг-smpна уровне qemu, а проблема на уровне ядра, оно указывает сколько vCPU и RAM забирать, но не указывает то, сколько процессорного времени забиратьВ моем коде по пути проекта: agent/client/pycgroup/ctl/cpu_ctl.py
Я перевожу ограничения по ядрам эквивалентно процессорному времени. Вы можете создать 2 ВМ которые берут по 6 ядер, хотя по факту у вас физически ядер 6, первая ВМ при нагрузке сможет спокойно забирать больше 90% процессорного времени, потому что вы честно указали - у тебя есть 6 ядер
P.S На крупных платформах сумма vCPU всех ВМ почти всегда в разы превышает количество физических ядер на хосте(Overcommit)
Stanislavvv
10.06.2026 16:01Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
Eskander_007 Автор
10.06.2026 16:01cgroups это официальный механизм иерархического распределения ресурсов - https://linux.googlesource.com/virt/kvm/kvm/+/9d4ac8b6302c60a1949560e501fc1d0b4654b9c6/Documentation/admin-guide/cgroup-v2.rst
Понятное дело, что cgroups можно использовать с более умными алгоритмами и более красиво, но, в рамках MVP, на мой взгляд реализация более чем допустима :)P.S Да, в статье изначально надо было отписать, что речь про оверселлинг по процессору, мой недочет
Stanislavvv
10.06.2026 16:01Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
ZabLen
Потому что Вы фокусируетесь только на распределении ресурсов, игнорируя остальные 95-99% продукта. Во всяком случае, я так вижу после прочтения статьи и README.md репозитория.
Система виртуализации - это сотни технологий и, в случае с зарубежными топовыми вендорами, десятки лет поедания колючек для получения уникального решения.
Миграции, бэкапы, отказоустойчивость, таски, внешние интеграции, не говорю уж просто про хранилки и сети - где это всё? С точки зрения заказчика, лучше open-source, чем ничего.
ZabLen
Вендоров псевдоимпортозамещения я не оправдываю. Это всё понятно, бюджеты сами себя не освоят. Я говорю именно про то, что прочитал здесь
Eskander_007 Автор
Был реализован базовый функционал который позволял использовать платформу полноценно, я не фокусировался на одном лишь распределении ресурсов, но это была фича которую я хорошо реализовал, она решала конкретную доказанную боль, решения которой я не увидел ни у одного крупного вендора. Миграции и отказоустойчивость это две стороны одной технологии, когда ВМ выходит из строя она автоматически мигрирует в соседнюю работающую ноду, поскольку конфиги и данные хранятся на удаленных хранилищах. Остальные и другие технологии добавить не является абсолютно никакой проблемой в большинстве своем, это вопрос запросов заказчика и потребностей рынка.
ZabLen
Как технарь, я Вас и Ваше начинание безусловно поддерживаю. Вы проделали отличную работу, которую даже при отсутствии заказчиков можно применить в домашней ферме и получить удовлетворение от работы.
А вот если бы я был на стороне заказчика, разговор бы закончился на этом моменте :) Любая работа занимает больше времени, чем планировалось. И когда один человек - незнакомый, пусть даже талантливый - заявляет о том что он готов заместить собой наработки целого сообщества, это звучит как огромный риск потратить деньги и энергию впустую. Потратить на, уж простите, очередного гения с самомнением. Это я не от своего лица говорю, так воспринимают на другом конце провода.
С Вашими наработками нужно идти не в бизнес, а в инвесторов и в акселераторы. И то, когда появится один-два единомышленника, потому что Ваш замах - это не мобильное приложение в одиночку делать.
Eskander_007 Автор
Да, полностью согласен. Фраза
со стороны бизнеса действительно звучит как недооценка рисков - буду аккуратнее в формулировках. И про одиночку тоже верно: сейчас я работаю над децентрализованной GPU-сетью, но уже с командой. Спасибо, что подметили - полезная обратная связь.
ZabLen
Рад, что мой взгляд оказался Вам полезен. Успехов!
Круто! Если появится работа, то я всегда всеми конечностями за хорошие инициативы ;)