Аналоги VMware: чем заменить при импортозамещении

Вопрос замены VMware для российских компаний перестал быть гипотетическим ещё в 2022 году, а после перехода Broadcom на подписную модель лицензирования стал вопросом бюджета и соответствия требованиям регулятора одновременно. В этом материале разбираем, почему миграция с VMware vSphere и VMware ESXi остаётся актуальной в 2026 году, на какие критерии опираться при выборе российской платформы виртуализации, какие решения закрывают задачи корпоративных ЦОД, КИИ и провайдеров, а также как спланировать переход без остановки бизнес-процессов. В наших проектах модернизации ИТ-инфраструктуры вопрос выбора платформы виртуализации в условиях ухода зарубежных вендоров возникает регулярно — дальше мы опираемся не только на нормативные документы, но и на практический опыт таких задач.

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

VMware официально отключила техподдержку для российских клиентов 5 марта 2022 года — это подтверждают и заявление самой компании о приостановке операций в России и Беларуси, и публикации «Коммерсанта». В конце марта 2022 года ФСТЭК России приостановила действие сертификатов на продукты VMware, а с 28 сентября 2022 года российское юрлицо «Виэмваре Рус» находится в стадии ликвидации.

После завершения сделки по поглощению VMware компанией Broadcom в 2023 году легальное приобретение новых лицензий или продление подписки для российских заказчиков стало невозможным даже теоретически. С 1 января 2025 года объектам критической информационной инфраструктуры — госучреждениям, банкам, телекому — прямо запрещено использовать продукты VMware.

Отдельная проблема — экономика лицензирования после Broadcom. В январе 2024 года компания полностью отменила бессрочные лицензии VMware, перевела портфель на ежегодную подписку и сократила линейку до двух бандлов: VMware Cloud Foundation и VMware vSphere Foundation. Для заказчиков, ранее использовавших только vSphere Enterprise Plus без vSAN и vRealize, стоимость выросла в 2–3 раза — теперь такие компоненты нельзя купить отдельно, только в комплексном бандле. Одновременно для клиентов, уже эксплуатировавших комплексный VMware Cloud Foundation, цена подписки снизилась вдвое — с $700 до $350 за процессорное ядро. В феврале 2024 года Broadcom прекратила распространение и бесплатных версий ESXi 7.x и 8.x. Держатели бессрочных лицензий формально сохраняют право использовать версию 8 без обновлений, но продлить контракты Support and Subscription уже не могут.

Для тех, кто продолжает эксплуатацию VMware через параллельный импорт, риски множатся: отсутствие патчей безопасности, невозможность продления лицензий и поддержки, юридические иски от правообладателей, административные штрафы до 200 000 ₽ с конфискацией оборудования при нарушениях в оформлении ввоза, а также риск блокировки счетов банками по 115-ФЗ при подозрительных трансграничных платежах. Отдельный технический дедлайн — прекращение официальной поддержки (End of General Support) VMware vSphere 7.x, назначенное на 2 октября 2025 года; после этой даты Broadcom не выпускает патчи безопасности для ESXi, vCenter и vSAN версии 7.x, а окно технических рекомендаций (End of Technical Guidance) закрывается 2 апреля 2027 года.

На этом фоне российский рынок платформ виртуализации показывает устойчивый рост — и это не разовый всплеск на волне санкций, а многолетняя динамика. По данным iKS-Consulting, объём рынка в 2024 году достиг ₽14,4 млрд при ежегодном приросте более 20%, а к 2030 году аналитики прогнозируют рост до ₽50 млрд; те же цифры приводит и обзор CNews «Российские платформы виртуализации». Другие агентства называют иные темпы (Strategy Partners фиксировала просадку рынка на 30% в 2022 году с последующим восстановлением на 20–37% в 2023-м), но направление тренда — устойчивый рост доли отечественных решений — подтверждается всеми источниками. По данным отдельного опроса ИБ-вендора «Код Безопасности» (2025), уже 78% организаций РФ выбирают отечественные средства виртуализации — эта цифра независимо подтверждает динамику ухода от VMware, зафиксированную в оценках iKS-Consulting.

Практический вывод: если инфраструктура всё ещё работает на VMware vSphere 7.x без продлённой поддержки, риск нужно оценивать не по факту простоя (его пока может не быть), а по накопленному долгу необновлённых уязвимостей и юридическому статусу лицензий.

Выбор замены VMware нельзя свести к сравнению списков функций. Для корпоративного заказчика, а тем более для госсектора и КИИ, решение проходит через несколько фильтров одновременно: регуляторный, технический и организационный.

Ключевые критерии — это статус в реестре отечественного ПО Минцифры, уровень доверия ФСТЭК, совместимость с уже развёрнутыми российскими ОС и СХД, зрелость функций высокой доступности и живой миграции, поддержка программно-определяемых сетей (SDN) и vGPU для ИИ/ML-нагрузок, а также зрелость вендора — размер инсталляционной базы и качество технической поддержки. Пропуск любого из этих фильтров на старте проекта почти всегда означает пересмотр выбора платформы на середине миграции.

Формальный вход в закупки для госзаказчиков — включение платформы виртуализации в Единый реестр российских программ Минцифры; без этого статуса участие в закупках по 44-ФЗ, где закупка ПО не из реестра прямо запрещена при наличии реестрового аналога, невозможно. По 223-ФЗ требование мягче — реестровому ПО отдаётся приоритет при наличии аналога, но не абсолютный запрет. Согласно Постановлению Правительства РФ №1875 от 23 декабря 2024 года, запрет на закупку иностранного ПО распространяется на все классы программ, включая встроенное ПО в составе программно-аппаратных комплексов — это закрывает лазейку с закупкой зарубежного гипервизора «под видом» аппаратной части ПАК.

С 1 июня 2026 года для средств виртуализации вводится дополнительный критерий: совместимость минимум с двумя российскими операционными системами общего назначения из реестра (либо с одной ОС, если продукт поставляется в составе программно-аппаратного комплекса), отсутствие функциональных аналогов в реестре и доля дохода от несвязанных организаций выше 70%. Требование вводится поэтапно, по готовности разработчиков.

Отдельный уровень — сертификация ФСТЭК России. Действующий документ — приказ ФСТЭК России №187 от 27 октября 2022 года «Требования по безопасности информации к средствам виртуализации» (зарегистрирован в Минюсте 22 декабря 2022 года, №71774). Он устанавливает 6 классов защиты средств виртуализации, которые напрямую соответствуют 6 уровням доверия — от 6-го (базового) до 1-го (максимального); сама шкала уровней доверия закреплена более ранним приказом ФСТЭК №76 от 2 июня 2020 года, а приказ №187 применяет её к виртуализации.

Для значимых объектов КИИ (ЗОКИИ) уровень доверия платформы виртуализации жёстко привязан к категории значимости объекта: 4-й уровень (класс защиты) требуется для 1-й категории значимости, 5-й — для 2-й категории, 6-й — для 3-й категории. Важный нюанс: хостовая операционная система должна соответствовать тому же классу защиты, что и сама платформа виртуализации — нельзя поставить сертифицированный по 4-му классу гипервизор на несертифицированную ОС и рассчитывать на соответствие требованиям для ЗОКИИ 1-й категории. Сама категория значимости объекта КИИ определяется не выбором заказчика, а расчётом: согласно постановлению Правительства РФ №127, она устанавливается по масштабу возможных последствий компьютерных инцидентов и экономическим показателям объекта, поэтому категорирование логично проводить до выбора платформы виртуализации, а не после.

Типичная ошибка на этом этапе — выбор платформы по уровню доверия «с запасом», без привязки к реальной категории объектов КИИ заказчика: избыточный уровень доверия увеличивает стоимость лицензий и сроки внедрения без функциональной необходимости.

Совместимость с гостевой и хостовой операционной системой — не декларация вендора, а предмет отдельной сертификации. Официально подтверждена совместимость Astra Linux Special Edition 1.7 с платформами zVirt 3.0 (сертификат программы Ready for Astra Linux), HOSTVM 4.4 (сертификаты №5434/2021 и №5435/2021 — как с Special Edition, так и с Common Edition), ПК СВ «Брест» (работает исключительно на базе Astra Linux Special Edition релиз «Смоленск») и РЕД Виртуализация 7.3. Для РЕД ОС и Альт Линукс прямых сертификатов совместимости с ведущими платформами виртуализации в открытых источниках не обнаружено — из семейства Альт есть только собственный «Альт сервер виртуализации» на базе OpenNebula и Proxmox, разработанный на основе того же дистрибутива. Перед проектированием кластера этот момент стоит уточнять у вендора отдельно, а не считать совместимость с семейством ОС само собой разумеющейся.

Второй практический фильтр — совместимость с СХД, особенно если компания планирует сохранить существующий парк систем хранения. Подтверждённые вендором интеграции включают РЕД Виртуализацию с линейкой АЭРОДИСК ENGINE AQ, платформу «Горизонт-ВС» (ИЦ «Баррикады») с АЭРОДИСК ENGINE и ВОСТОК по iSCSI и Fibre Channel, zVirt (Orion Soft) с моделями АЭРОДИСК ENGINE AQ 440, AQ 450, AQ Лайт и ВОСТОК (18 тест-кейсов сертификации), а также ROSA Virtualization 3.0 с теми же аппаратными платформами AQ440, AQ450 и «Восток».

Практический вывод: если серверный парк и СХД уже частично заменены на отечественное оборудование, начинать выбор платформы виртуализации стоит именно со списка подтверждённых интеграций с конкретной моделью СХД — это сокращает риск незапланированных работ по донастройке хранилища при пилотном развёртывании.

Функциональные аналоги VMware High Availability и vMotion заявлены у РОСПЛАТФОРМЫ, zVirt, SpaceVM, vStack, Astra Linux Virtualization (продукт линейки ПК СВ «Брест»), РЕД Виртуализации и ROSA Virtualization — все они поддерживают автоматический перезапуск ВМ при отказе хоста и живую миграцию работающих машин между узлами без остановки. А вот полноценный аналог Storage vMotion (миграция хранилища работающей ВМ) в открытых технических материалах явно заявлен только у РОСПЛАТФОРМЫ, у vStack реализована базовая версия этой функции. Некоторые рейтинговые обзоры отмечают эту функцию у большинства платформ единой галочкой «Да», но без ссылки на конкретную документацию — поэтому для проектов, где Storage vMotion критичен, стоит проверять её работу на демостенде, а не полагаться на маркетинговые таблицы. Функция Fault Tolerance — мгновенное переключение без потери состояния при отказе хоста — остаётся уникальной для VMware: у российских платформ этот сценарий закрывается через HA с секундами простоя на перезапуск, а не через бесшовное переключение.

Для нагрузок на GPU и ИИ/ML одновременная поддержка SDN и vGPU/GPU passthrough подтверждена у Basis Dynamix Enterprise (нативная интеграция с программно-определяемыми сетями, деление GPU на vGPU), SpaceVM (микросегментация SDN, vGPU и GPU passthrough через собственный сервер лицензирования FreeGRID), zVirt (продвинутый SDN, позиционируется как альтернатива VMware по инструментам миграции) и vStack HCP (объединяет SDN и SDS-хранилище, поддерживает vGPU). ROSA Virtualization поддерживает vGPU и применяется в кластерах VDI с картами NVIDIA A40 для учебных и исследовательских ИИ-задач.

Поддержку Kubernetes и контейнеризации закрывают Deckhouse Virtualization Platform от «Флант» (управление ВМ как объектами Kubernetes через KubeVirt), ROSA Virtualization, Numa vServer, VMmanager 6 и «Брест» — в отраслевом цифровом маркетплейсе 19 решений в категории «гипервизоры» заявляют опцию оркестрации контейнеров. Отдельно стоит учитывать требования к средствам контейнеризации по приказу ФСТЭК №118 от 4 июля 2022 года — если платформа совмещает виртуализацию и контейнеризацию в защищённом контуре, сертификация нужна по обоим направлениям. Ниже, в разделе про обзор российских платформ по сегментам применения, каждая из этих функций разобрана по конкретному вендору отдельно — с версиями и датами релизов, а не только фактом наличия.

Прямое табличное сопоставление удобно смотреть по параметрам, которые чаще всего становятся решающими при выборе: уровень доверия ФСТЭК, зрелость HA/DR, поддержка SDN и vGPU, тип гипервизора и модель лицензирования.

«Нет данных в открытых источниках» в таблице означает не отсутствие функции, а то, что вендор не публикует эту характеристику для самостоятельной проверки. Для платформ из сегмента КИИ (РЕД Виртуализация, Numa vServer, ПК СВ «Брест») это особенно важно уточнять напрямую у вендора или интегратора перед пилотным развёртыванием, а не делать вывод из пустой ячейки.

По моделям лицензирования картина проще. По данным аналитического обзора vm-guru (2025), у Broadcom/VMware после перехода на новую метрику лицензия считается по ядрам процессора с минимальным порогом 16 ядер на CPU и минимальным заказом 72 ядра — для плотных многоядерных серверов это резко увеличивает стоимость. У российских вендоров в открытых прайс-листах доминирует другая логика: например, Р-Виртуализация (Росплатформа) лицензируется по числу физических процессоров (сокетов) без привязки к числу ядер или объёму ОЗУ, с неограниченным числом ВМ на сервер. Модель «за ядро» или «за виртуальную машину» — привычные для VMware — в открытой документации российских вендоров не встречаются; для большинства платформ (РЕД Виртуализация, zVirt, Альт Виртуализация, ROSA Virtualization) точную схему лицензирования нужно уточнять напрямую у вендора или интегратора.

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

Один из немногих открытых материалов, приближенных к reference architecture, — статья «Архитектура гиперконвергентной платформы vStack» (издатель — vStack, корпорация ITGLOBAL.COM LABS), где описана типовая схема развёртывания: универсальные серверы x86 без выделенных ролей узлов, где программно-определяемые слои вычислений, хранения (SDS) и сети (SDN) объединены в единой панели управления.

Для масштабируемых корпоративных инфраструктур основные претенденты — zVirt, Basis Dynamix Enterprise, vStack и «Кибер Инфраструктура».

zVirt (Orion Soft) поддерживает метро-кластеры на классических СХД с автоматическим перезапуском ВМ на резервной площадке при отказе узла или всей площадки. Живая миграция между узлами кластера доступна всегда; в версии 4.2 добавилась миграция между кластерами, а в версии 5.0 — между центрами обработки данных без остановки и без обязательного общего хранилища, при условии совпадения сетевых технологий. Редакция zVirt Max 1.2 имеет сертификат ФСТЭК; статус включения базовой версии в реестр Минцифры в открытых источниках не подтверждён.

Basis Dynamix Enterprise (разработчик — Группа «Базис») управляет виртуальными машинами, bare metal-серверами и контейнерами, поддерживает автоматизацию Kubernetes-развёртываний и подход Infrastructure-as-Code. Платформа интегрирована с отечественной СХД Tatlin.Unified через API 3.1 (снимки, клонирование, репликация томов), поддерживает чипсет Q35 (до 9 дисков и 30 сетевых интерфейсов на ВМ), UEFI-загрузку и DPDK. В релизе 4.5 (март 2026) расширена поддержка отечественных СХД и функций SDN, в релизе 4.6 (июнь 2026) добавлены автобалансировка нагрузки и связанные клоны. Сертификация ФСТЭК самой платформы в открытых источниках не подтверждена — упоминается только сертификация отдельного модуля защиты Virtual Protect.

vStack (разработчик — ITGLOBAL.COM LABS) — гиперконвергентная платформа на собственной ОС vStack OS (FreeBSD, тонкий гипервизор bhyve) с программно-определяемым хранилищем на базе ZFS вместо традиционного SAN, собственной реализацией SDN и алгоритма RAFT, без использования OpenStack или oVirt. По данным вендора, накладные расходы CPU на виртуализацию составляют 2–5% против 10–15% у классических решений, а overcommit процессора в продуктивной эксплуатации допускается до 900%. Метро-кластер работает в режиме active-active между ЦОД с резервированием уровней N+1/N+2/N+3. Платформа включена в реестр российского ПО под номером 11995 от 18 ноября 2021 года; сертификация ФСТЭК на момент публикации вендором заявлена как плановая.

«Кибер Инфраструктура» (Киберпротект) — HCI-решение на базе QEMU/KVM, объединяющее виртуализацию, программно-определяемое хранилище (NFS, iSCSI, S3 с тегированием и lifecycle-политиками) и программно-определяемую сеть с распределённой маршрутизацией и встроенным брандмауэром. Поддерживает метро-кластеры в двух ЦОД, горизонтальное масштабирование до десятков петабайтов и работу на разнородном оборудовании x86-64. Данные о конкретных сертификатах ФСТЭК или ГОСТ для этого решения в открытых источниках отсутствуют.

Для защищённых контуров и значимых объектов КИИ основной пул решений формируют РЕД Виртуализация, ПК СВ «Брест», Numa vServer и ROSA Virtualization.

РЕД Виртуализация 7.3 (сертифицированная редакция, РЕД СОФТ) имеет сертификат ФСТЭК №4060 (4 класс защиты, действует до 12 января 2029 года, поддержка — до 31 декабря 2030 года). Платформа базируется на гипервизоре KVM и сертифицированных компонентах QEMU/libvirt из состава РЕД ОС, поддерживает архитектуры x86_64 и ARMv8 (Huawei Taishan), а также миграцию виртуальных машин с Microsoft Hyper-V и VMware vSphere. Лицензируется по числу физических серверов, не более 2 сокетов на лицензию, без ограничения количества ВМ на сервере.

ПК СВ «Брест» разрабатывается Группой «Астра» (лицензионный производитель — ООО «КИС») и работает на базе Astra Linux Special Edition 1.7 с KVM/QEMU/libvirt. По сертификату №4864 источники расходятся в деталях: часть материалов называет 1-й уровень доверия и профиль защиты типа «А» с датой 21 июня 2024 года, другие (включая пресс-релиз группы «Астра» и независимые рейтинги рынка) — 2-й уровень доверия, профиль защиты типа «Б» и дату 8 октября 2024 года. Однозначно называть конкретный уровень без риска ошибки нельзя — перед включением платформы в техническое задание для ЗОКИИ или ГИС актуальный статус сертификата стоит запрашивать напрямую у ГК «Астра» или дистрибьютора. Продукт дополнительно сертифицирован Министерством обороны России и применяется в защищённых контурах для информации до грифа «особой важности», включая КИИ и ИСПДн. Важная деталь для закупщика: по данным профильных обзоров рынка (осень 2025), ПК СВ «Брест» больше не поставляется как самостоятельный продукт — только в составе комплексного решения Astra Infrastructure Cloud (AIC), что стоит уточнять у дистрибьютора при формировании технического задания.

Numa vServer («НумаТех») — сертификат ФСТЭК №4580 от 23 сентября 2022 года (4 уровень доверия), реестровая запись Минцифры №13854 от 7 июня 2022 года. Единственное в России корпоративное решение на гипервизоре Xen (тип 1, bare-metal) с более чем 300 доработками безопасности и надёжности, способное работать на серверах старше 10 лет без хостовой операционной системы.

ROSA Virtualization 3.0 (НТЦ ИТ РОСА) имеет действующий сертификат ФСТЭК №4861 от 4 октября 2024 года (4 класс защиты, до 4 октября 2029 года; предыдущая версия 2.1 сертифицирована по документу №4610 до 31 октября 2027 года). Встроенные средства защиты закрывают 7 из 9 обязательных требований, кроме межсетевого экранирования и антивирусной защиты — эти функции нужно закрывать отдельными сертифицированными продуктами. Платформа поддерживает до десятков тысяч ВМ и предназначена для ГИС до 1-го класса защищённости включительно.

Для хостинг-провайдеров, приватных облаков и сценариев VDI типичный выбор — VMmanager, HOSTVM и SpaceVM.

VMmanager (ISPsystem) — платформа управления виртуализацией на KVM и LXD, ориентированная как на хостинг- и облачных провайдеров (редакция Hosting), так и на внутреннюю ИТ-инфраструктуру компаний (редакция Infrastructure). С 14 января 2025 года модель лицензирования зависит от канала покупки: через дистрибьютора ГК «Астра» — по числу узлов кластера (не более 2 CPU на узел), напрямую в ISPsystem — по числу физических ядер CPU. VDI разворачивается через интеграцию с системой Termidesk.

HOSTVM (разработчик — «Базовый Код») ориентирован на корпоративный сегмент — Enterprise, SMB и госсектор, а не на провайдеров. Работает на гипервизоре KVM, для VDI поддерживает виртуализацию графики через NVIDIA GRID и AMD MxGPU с доставкой рабочих столов по SPICE, VNC, RDP, PCoIP, X2Go, NX и HTML5. Включена в реестр Минцифры под номером 4407, интегрируется с системой многофакторной аутентификации Indeed AM.

SpaceVM (разработчик — «ДАКОМ М», бренд Space) — платформа на KVM с проприетарным ядром и собственным SDN, включённая в реестр российского ПО. Прямая поддержка VDI реализована через отдельный продукт Space VDI с клиентом Space Client. Поддержка vGPU для карт NVIDIA реализована через технологию FreeGRID, что снимает зависимость от официальных лицензионных серверов NVIDIA под санкциями.

Миграция с VMware — это не единоразовое переключение, а проект на 10–18 месяцев для полного цикла с переносом production-систем, с чётко выделенными волнами переноса и обязательным пилотным контуром. Для компактных инфраструктур без критичных продуктивных нагрузок (только dev/test и внутренние сервисы, без волны 3) процесс может уложиться в 6–9 месяцев. По опыту наших инженеров при проектировании кластеров виртуализации и резервного копирования в условиях ухода зарубежных вендоров — а такие задачи стали типовой частью нашей практики модернизации ИТ-инфраструктуры — ключевая ошибка на старте проекта заключается в попытке перенести всю инфраструктуру одной волной, без пилота.

Типовой проект строится по этапам: аудит и инвентаризация ВМ, выбор стратегии переноса, пилот на некритичном контуре, обучение команды параллельно с пилотом, поэтапный перенос волнами и завершение с полным отказом от параллельной эксплуатации VMware. Стратегия переноса чаще всего строится по принципу lift-and-shift — перенос «как есть» без изменения архитектуры приложения (около 65% случаев), реже применяется replatforming с минимальными изменениями (около 25%), а оставшиеся примерно 10% случаев — это полный refactoring приложения под новую платформу. Волны переноса типично распределяются так: волна 1 (1–3 месяца) — dev/test-контуры; волна 2 (4–9 месяцев) — CRM, ERP, внутренние сервисы; волна 3 (10–18 месяцев) — production и критичные системы. Параллельная эксплуатация VMware и новой платформы допустима на этапе переноса критичных систем для снижения риска, но полностью исключается после 3–6 месяцев стабильной работы новой среды.

Для конвертации виртуальных машин применяются несколько инструментов: партнёрская утилита Hystax Acura обеспечивает автоматизированный перенос в VK Cloud, Astra Linux, АЛЬТ СП и РТК Базис; встроенный virt-v2v (Red Hat) конвертирует ВМ VMware vSphere ESX/ESXi версий 6.0–7.0 для запуска в средах на базе KVM; qemu-img конвертирует диски из формата VMDK в QCOW2 или RAW; универсальный формат OVF/OVA поддерживают многие российские гипервизоры. После конвертации Windows-машин обязательна установка драйверов virtio — без них диск и сеть на целевом гипервизоре могут просто не заработать.

Аудит перед миграцией должен зафиксировать пять групп метрик: загрузку CPU в часы пик, использование RAM, показатели нагрузки и объём хранилища, сетевые зависимости между сервисами (внутренние и внешние связи) и допустимое окно простоя для каждого сервиса. Инвентаризация ВМ в vCenter обычно проводится через RVTools, с группировкой машин по критичности — production, staging, dev/test — и проверкой межсервисных зависимостей для корректного распределения по волнам.

Пилотный контур строится на 5–10 некритичных виртуальных машинах из dev/test-сегмента: на них проверяется совместимость оборудования и СХД, устанавливаются драйверы virtio, настраивается резервное копирование на новой платформе. Именно на пилоте, а не на этапе полного проекта, стоит выявлять проблемы совместимости — цена ошибки здесь минимальна.

Практический вывод: пилотный контур без реального production-подобного профиля нагрузки (условно «пустые» тестовые ВМ) не выявит проблем совместимости, которые проявятся только под реальной нагрузкой волны 2–3. Подбирайте для пилота машины, максимально близкие по профилю к тем, что пойдут в продуктив.

Наиболее частые технические причины сбоев при переносе — несовместимость виртуальных драйверов сетевых карт и дисков на целевом гипервизоре, из-за чего ВМ не запускается после конвертации; различия в классификации хранилища (например, ВМ находится на «удалённом» хранилище, а целевой узел видит только «локальное»); несовпадение имён виртуальных сетей или подсетей между исходной и целевой средой; блокировка живой миграции при подключении ВМ к внутреннему или частному виртуальному коммутатору; рассинхронизация протоколов аутентификации (CredSSP против Kerberos); а также ошибки «оборудование несовместимо» из-за различий в уровнях обновлений или отсутствия настройки Enhanced Compatibility (EVC) между узлами разных поколений процессоров.

Отдельно стоит проверять после переноса не только запуск самой ВМ, но и сетевую связность с зависимыми сервисами — недостаточное тестирование этого шага регулярно оказывается причиной инцидентов в первые дни после переключения волны на новую платформу.

Переход на российскую платформу виртуализации не снимает требований к защите виртуальной среды. Для банков, госструктур и промышленных предприятий они становятся даже строже, поскольку регулятор одновременно контролирует и уровень доверия платформы, и организацию доступа к ней. Базовые обязательные меры для значимых объектов КИИ, включая защиту среды виртуализации, устанавливает приказ ФСТЭК России №239 от 25 декабря 2017 года «Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» — приказ №187 конкретизирует эти общие требования применительно именно к средствам виртуализации.

Приказ ФСТЭК №187 обязывает реализовать в средствах виртуализации 6–4 классов защиты ролевую модель управления доступом как минимум с четырьмя ролями: администратор средства виртуализации (управление платформой и гипервизором), администратор безопасности средства виртуализации (контроль целостности, регистрация событий, доверенная загрузка — без прав на изменение конфигурации ВМ), администратор виртуальной машины (доступ только к своей ВМ через интерфейс средства виртуализации) и разработчик виртуальной машины (право на снимки и базовую конфигурацию своей ВМ, без доступа к сетевым VLAN и мониторингу других узлов). Отраслевая практика для КИИ и ГИС требует строгой грануляции этих ролей между разными инженерами, а журнал событий безопасности должен быть доступен администраторам только на чтение — это исключает модификацию записей об инцидентах задним числом. Согласно информационному сообщению ФСТЭК России от 14 апреля 2026 года, утверждён методический документ, который выделяет защиту среды виртуализации отдельной обязательной мерой, а не частью общего перечня организационно-технических мер — для проектов, стартующих в 2026 году, это стоит учитывать при формировании модели угроз с нуля.

На уровне сетевой защиты для гипервизорной среды показателен продукт vGate NGFW («Код Безопасности», версия 4.1 и выше) — межсетевой экран уровня гипервизора, работающий как сервисная ВМ, куда гипервизор перенаправляет трафик для инспекции перед доставкой адресату. Функция микросегментации позволяет объединять ВМ в логический сегмент даже на разных хостах и накладывать политики безопасности напрямую на объекты, а сама vGate сертифицирована ФСТЭК по 4-му уровню доверия, 4-му классу защиты межсетевых экранов типа «Б» и 5-му классу защищённости средств вычислительной техники — это позволяет применять её для ГИС, ИСПДн и значимых объектов КИИ. Помимо VMware vSphere подтверждена интеграция vGate с zVirt (Orion Soft, платформа на базе KVM): по данным профильных обзоров рынка, связка используется в эксплуатации уже больше года и закрывает требования ФСТЭК по микросегментации сети именно на KVM-инфраструктуре. Для других KVM-платформ (Basis Dynamix Enterprise, SpaceVM) аналогичную функциональность межсетевого экранирования и микросегментации закрывают собственные SDN-модули вендора — глубину и зрелость именно интеграции с vGate стоит уточнять отдельно под конкретную целевую платформу.

Общая нормативная рамка для значимых объектов КИИ — Федеральный закон №187-ФЗ от 26 июля 2017 года «О безопасности критической информационной инфраструктуры Российской Федерации» в действующей редакции с изменениями, вступившими в силу с 1 сентября 2025 года. Согласно обзору этих изменений, субъекты КИИ теперь обязаны передавать данные о компьютерных атаках в ГосСОПКА — для средств виртуализации это означает необходимость интеграции журналов событий безопасности гипервизора с корпоративным SOC или внешним центром ГосСОПКА, а не только их локальное хранение. Требования к защите информации в конкретных информационных системах, включая меру «защита среды виртуализации», детализируются методическими документами ФСТЭК России; для средств виртуализации как таковых применяется уже упомянутый приказ №187 от 27 октября 2022 года. Дополнительным ориентиром при проектировании защищённой виртуальной среды служит ГОСТ Р 56938-2016 «Защита информации. Защита информации при использовании технологий виртуализации. Общие положения» — на него, в частности, прямо ссылается разработчик Numa vServer.

Отдельные сертифицированные средства защиты для виртуальной среды — такие как рассмотренный выше vGate NGFW — сами добавляют статью расходов в TCO, поэтому их стоимость логично закладывать в бюджет уже на этапе проектирования, а не считать «неожиданной» статьёй после пилота. Совокупная стоимость владения при переходе с VMware в целом складывается не только из цены новых лицензий — и именно на этом чаще всего ошибаются в предварительных расчётах бюджета.

Расчёт TCO логично вести по шести статьям расходов, а не только по цене лицензий:
1.Лицензии целевой платформы — как уже говорилось выше, у большинства российских вендоров доминирует лицензирование по физическому сокету или серверу без привязки к числу ядер, что делает стоимость предсказуемой при апгрейде CPU без замены лицензий (в отличие от поядерной модели Broadcom с порогом 16 ядер на CPU); точную схему всё равно нужно уточнять у каждого вендора отдельно, поскольку единого стандарта на рынке нет.
2.Проектирование перехода — аудит инфраструктуры, архитектура целевого кластера, тестовый стенд для пилота.
3.Оборудование — новые серверы и СХД либо адаптация существующего парка под требования целевого гипервизора.
4.Обучение администраторов — работа с новым интерфейсом управления (командной строкой, веб-консолью, API), часто с нуля для команды, привыкшей к vCenter.
5.Период параллельной эксплуатации — обычно от 3 до 6 месяцев на этапе стабилизации новой среды, когда фактически оплачиваются два контура одновременно.
6.Сопровождение и SLA — стоимость технической поддержки новой платформы против прежней подписки VMware, включая цену дополнительных сертифицированных средств защиты вроде vGate.

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

Отдельный рычаг оптимизации TCO — лизинг оборудования под новую платформу виртуализации: он позволяет растянуть капитальные затраты на закупку серверов и СХД под миграцию на срок эксплуатации без единовременной нагрузки на бюджет. В наших проектах выбор платформы виртуализации в условиях ухода зарубежных вендоров и ограниченного бюджета заказчика неоднократно требовал сравнительного анализа нескольких решений одновременно. Например, при построении кластера виртуализации и резервного копирования для промышленно-продовольственного кластера «Косино» инженеры Work System за две недели сравнили доступные российские и зарубежные решения и рекомендовали моновендорную архитектуру на базе Huawei, аргументировав выбор полным покрытием требуемого функционала — снимков, репликации, дедупликации, кластеризации — и оптимизацией инвестиций в оборудование и его поддержку.