За последние два месяца в Deckhouse Virtualization Platform (DVP) — виртуализации, использующей современный подход к управлению виртуальными машинами (ВМ) и контейнерами в одной среде — вышло пять новых релизов (0.19–0.23). За это время в платформе появились 41 изменение и фикс, об основных расскажем в этом обзоре. Среди них — улучшенная безопасность, автоматическая перебалансировка ВМ по узлам, оптимизация миграции и вложенная виртуализация.

Самое главное — модуль виртуализации вышел из статуса Preview и получил статус General Availability. Это означает, что модуль стабилен, протестирован и готов к работе в production-средах. Можно смело использовать его для реальных проектов.
С точки зрения безопасности тоже есть хорошие новости:
Мы удалили неиспользуемые бинарные файлы из контейнеров для улучшения безопасности и снижения накладных расходов при запуске контейнеров.
Обновили зависимости в модуле, закрыли несколько серьёзных уязвимостей, включая CVE-2024-45337, CVE-2025-22869, CVE-2025-22870 и другие.
Исправили проблемы с уязвимостями в Python-хуках (CVE-2024-12797, CVE-2025-47273).
Далее рассмотрим самые важные из изменений. Кстати, все они доступны и в Open Source-версии платформы Deckhouse Virtualization Platform Community Edition (DVP CE).
Операции с виртуальными машинами и их конфигурация
Оптимизация отображения conditions ВМ
Ранее статусы состояния (conditions) ВМ отображались всегда, вне зависимости от того, запущена ВМ, остановлена или в процессе запуска. В результате многие conditions показывались постоянно, даже если не несли важной информации, что затрудняло быстрое восприятие и выделение критичных статусов.
Для решения этой проблемы улучшили управление отображением conditions. Теперь статус ВМ отображается более точно и релевантно:
Убрали неиспользуемые условия, такие как PodStarted.
Упростили общий набор conditions.
Реализовали динамическое отображение conditions в зависимости от текущего состояния ВМ. Теперь отображаются только те условия, которые актуальны и важны для понимания текущего состояния ВМ. Второстепенные и незначимые условия скрываются. Это позволило упростить восприятие статуса ВМ и значительно улучшить пользовательский опыт.
Такой подход позволяет быстрее и удобнее получать важную информацию о состоянии ВМ.
Исправление зависания VirtualMachineClass в статусе Pending
Исправили ошибку, из-за которой ресурс VirtualMachineClass
мог оставаться в состоянии Pending при создании кластера или добавлении узлов. Проблема возникала, если на узле ещё не были проставлены нужные метки (например, при указании CPU-фич). Теперь VirtualMachineClass
автоматически проверяет метки узлов и обновляет статус, вместо того чтобы зависать в ожидании ручного обновления.
Автоматическое определение вложенной виртуализации
Добавлен параметр, позволяющий вложенному кластеру DKP автоматически определять, работает ли узел на физическом сервере или внутри ВМ. Это необходимо для корректного детектирования вложенной виртуализации (например, при запуске DKP на ВМ внутри DVP) и обеспечения правильной работы сетевых компонентов CNI Cilium.
Оптимизация параметров живой миграции по умолчанию
Обновили стандартные настройки живой миграции для повышения стабильности:
Пропускная способность увеличена до 5 Гбит/с (~640 МБ/с) на одну миграцию (было 0,5 Гбит/с).
Лимит исходящих миграций — теперь 1 миграция одновременно с узла (было 2).
Общий лимит в кластере теперь равен количеству узлов с ВМ (было жёсткое ограничение в 5 одновременных миграций).
В результате миграции стали выполняться быстрее благодаря увеличенной пропускной способности, нагрузка на узлы снизилась за счёт разумного ограничения исходящих миграций, а система стала лучше масштабироваться в зависимости от размера кластера.
Автоматический выбор узлов с поддержкой виртуализации
Улучшили систему выбора серверов для запуска ВМ. Теперь платформа автоматически проверяет все узлы кластера и определяет, какие из них действительно подходят для виртуализации. Для этого проверяются два ключевых требования: наличие устройства /dev/kvm
и поддержка процессорных инструкций виртуализации (VMX для процессоров Intel или SVM для AMD).
Раньше в кластерах с разными типами серверов могли возникать проблемы — компоненты виртуализации иногда пытались запуститься на узлах без необходимой поддержки, что приводило к ошибкам. Теперь это исправлено: платформа сама находит подходящие узлы и использует только их для размещения как самих ВМ, так и служебных компонентов вроде virt-handler
.
Управление восстановлением ВМ из снимка
Добавили возможность управления процессом восстановления ВМ из снимка с помощью параметра restoreMode
. Этот параметр поддерживает два значения:
Safe — безопасное восстановление при отсутствии конфликтов ресурсов ВМ. Это поведение было по умолчанию в предыдущих версиях.
При этом для восстановления ВМ надо удалить оригинал или использовать ресурсVirtualMachineRestore
и задать параметры переименования в блоке.spec.nameReplacements
, чтобы избежать конфликтов имён ресурсов. Подробности в документации Снимки | Deckhouse.Forced — восстановление, которое может быть выполнено для существующей ВМ. В этом режиме конфигурация ВМ будет возвращена на момент снятия снимка, а связанные ресурсы будут восстановлены.
При этом если восстанавливаемые виртуальные диски уже используются другой ВМ или восстанавливаемый IP-адрес зарезервирован за другой ВМ, то восстановление завершится с ошибкой. Информация об этом отразится в статусе ресурсаVirtualMachineRestore
. Конфликты необходимо будет разрешить вручную, используяnameReplacements
для виртуальных дисков или освободив IP-адрес.
Платформа и хранилище
Исправление работы модуля на CentOS/Rocky Linux/AlmaLinux с SELinux
Исправили проблемы при развёртывании модуля виртуализации на дистрибутивах семейства CentOS (включая Rocky Linux и AlmaLinux) с включённым режимом SELinux (Enforced). Для этого обновили настройки для корректной работы с SELinux. Теперь установка модуля проходит без ошибок на указанных дистрибутивах даже при активном SELinux.
Оптимизация размера модуля виртуализации
Раньше модуль содержал множество отдельных исполняемых файлов общим объёмом 445 МБ, что было избыточным. После оптимизации весь функционал упакован в единый бинарный файл размером всего 50 МБ. Это изменение позволяет экономить дисковое пространство, ускоряет процесс загрузки и обновлений модуля, а также упрощает его распространение.
Важно отметить, что вся функциональность модуля полностью сохранилась — изменения затронули только внутреннюю организацию и упаковку компонентов. Модуль продолжает работать в прежнем режиме, но теперь занимает примерно в 10 раз меньше места.
Прекращение поддержки классов хранения, управляемых модулем local-path-provisioner
Данный класс хранения является устаревшим и не рекомендуется для использования в сценариях виртуализации. В версии 0.22 и выше создание новых ресурсов с использованием local-path-provisioner
будет недоступно. При этом ранее созданные ВМ и ресурсы с этим классом хранения продолжат работать без изменений.
Рекомендуем обновлять конфигурации и использовать другие, поддерживаемые типы хранилища для новых ВМ.
Образы, распределение ресурсов и высокая доступность
Автоматическая перебалансировка ВМ
Реализовали автоматическое перераспределение ВМ между узлами кластера, что позволит поддерживать работоспособность ВМ при изменениях условий окружения.
Перебалансировка предполагает выявление избыточно нагруженных узлов и запуск миграции ВМ с размещением на других, недостаточно нагруженных узлах (планирование нового размещения в соответствии с обычным поведением планировщика).
Без автоматической перебалансировки неравномерное распределение виртуальных машин может привести к чрезмерной загрузке узлов (например, CPU > 80 %), что может привести к снижению производительности ВМ, увеличению задержек и потенциальным сбоям узлов.
Чтобы включить функцию, нужно активировать модуль descheduler
. Каждые 15 минут он анализирует состояние кластера и при необходимости выполняет вытеснение ВМ с узлов в соответствии с условиями.
Поддержка динамического подключения дисков в режиме Filesystem
Добавили возможность динамического подключения (hotplug) дисков в режиме Filesystem
к работающей ВМ. Это изменение устраняет распространённые ошибки при динамическом расширении хранилища работающих ВМ, упрощает администрирование и автоматизирует процесс добавления новых файловых томов.
Увеличение отказоустойчивости компонентов виртуализации в HA-кластерах
Изменили количество реплик ключевых компонентов виртуализации для кластеров с режимом High Availability. Теперь на master-узлах развёртывается по 3 реплики следующих компонентов: cdi-apiserver, virt-api, virtualization-api и virtualization-controller. Остальные компоненты используют 2 реплики.
В HA-режиме кластер становится более устойчивым к сбоям: при выходе из строя лидера один из резервных master-узлов автоматически берёт на себя его функции. Это особенно важно для критически важных компонентов виртуализации. Такое изменение повышает доступность системы при временной недоступности master-узлов, так как всегда есть достаточное количество работающих реплик.
Резюме
За два месяца и пять релизов Deckhouse Virtualization Platform серьёзно прокачалась:
✅ Модуль виртуализации можно смело использовать в продакшене.
✅ Автоматизация базовых операций — платформа сама выбирает узлы, балансирует ВМ и мигрирует их с разной степенью участия пользователя. Вы сами решаете, насколько хотите автоматизировать эти процессы — от полного контроля вручную до полностью автоматического управления.
✅ Безопасность и стабильность — почистили контейнеры, закрыли уязвимости, оптимизировали работу с SELinux.
✅ Удобство администрирования — упростили отображение статусов ВМ, починили hotplug для дисков, созданных на Filesystem, повысили уровень безопасности и стабильности.
DVP теперь не просто инструмент для экспериментов, а полноценная платформа для production-виртуализации — быстрая, безопасная и отказоустойчивая.
Полный список изменений всех версий можно посмотреть по ссылке.
Для знакомства с платформой рекомендуем изучить раздел «Быстрый старт». Также у нас есть бесплатный курс по установке Deckhouse Virtualization Platform.
Чтобы подробнее узнать о том, зачем в экосистеме Deckhouse существует собственная виртуализация, как она интегрирована в архитектуру Deckhouse Kubernetes Platform (DKP), что она умеет и какие сценарии виртуализации применяются нашими клиентами, смотрите запись нашего вебинара.
P. S.
Читайте также в нашем блоге:
inkvizitor68sl
А вы частоту виртуального CPU троттлите, если не память по NBD синкается медленнее, чем виртуалка в память пишет?
fl64
Да, такая возможность есть. Можно выполнить операцию Evict с force, либо в ВМ задать политику liveMigrationPolicy. Подробнее можно посмотреть в доке https://deckhouse.ru/products/virtualization-platform/documentation/user/resource-management/virtual-machines.html#механизм-autoconverge