Миграция с VMware на российские решения: гид для бизнеса

Согласно аналитическим данным iKS-Consulting, в 2018 году платформа VMware занимала доминирующее положение, будучи установленной у 78,8% российских компаний, внедряющих виртуализацию. Однако, по информации аналогичного исследования, проведенного весной 2025 года, ситуация изменилась: доля отечественных программных решений для виртуализации составила 60,2%, в то время как доля VMware снизилась примерно до 39%. Эти данные основаны на анализе предложений 19 крупнейших российских облачных провайдеров. Хотя решения VMware по-прежнему присутствуют на рынке, их былое доминирование уступило место новым тенденциям.

За прошедшие годы VMware в России сместилась с позиции «платформы по умолчанию» для виртуализации до одной из многих значимых, но уже не лидирующих опций. Рынок демонстрирует стремительное перераспределение долей в пользу российских аналогов. Основными причинами этого сдвига являются возросшая доступность технической поддержки и обновлений, улучшенная управляемость процессов и соответствие требованиям, предъявляемым к российским IT-инфраструктурам.

Почему VMWare теперь нельзя использовать как раньше

Четыре ключевые проблемы для российского рынка программного обеспечения

1. Усиление регуляторных требований: С начала 2025 года российское законодательство существенно ограничивает использование иностранного ПО в критической информационной инфраструктуре (КИИ) и госсекторе. Вступление в силу новых требований ФСТЭК (Приказ №117) с марта 2026 года также накладывает дополнительные обязательства на государственные информационные системы (ГИС). Использование VMware становится прямым нарушением данных предписаний для организаций, обрабатывающих персональные данные, работающих в КИИ или относящихся к госсектору.
2. Ограничения доступа к официальным поставкам и поддержке: Легальный канал продаж и технической поддержки VMware в России фактически заморожен. Приобретение новых лицензий, продление существующих контрактов поддержки и получение гарантированных обновлений стали крайне затруднительными. После интеграции с Broadcom, политика подписки и привязки к контрактам и порталам стала более жесткой, превращая доступ к патчам и техподдержке в ограниченную опцию. Использование неофициальных каналов сопряжено с высокими юридическими рисками и вероятностью потери доступа к критически важным обновлениям или поддержке в экстренных ситуациях.
3. Рост угроз безопасности из-за уязвимостей: В 2024-2025 годах были зафиксированы критические уязвимости в таких компонентах VMware, как vCenter, VCF и ESXi, некоторые из которых уже активно использовались злоумышленниками. Компрометация vCenter или гипервизора предоставляет атакующим контроль над множеством виртуальных машин, позволяя остановить или зашифровать целую инфраструктуру. Задержки с установкой патчей, связанные с проблемами доступа к обновлениям, превращают единичные инциденты в системные риски.
4. Изоляция от облачных сервисов: Российские облачные провайдеры лишены возможности эффективно создавать и развивать свои сервисы на базе VMware. Это вынуждает их клиентов искать альтернативные платформы для миграции своих облачных инфраструктур.

Как выглядит полноценная замена VMware

Inscale разрабатывался с 2019 года как полноценная платформа виртуализации — с собственными сервисами управления, сетью и протоколом доставки рабочих столов. В основе слоя виртуализации — KVM/QEMU с доработками команды.

Что входит в платформу:

• собственный гипервизор на базе KVM с глубокой кастомизацией под реальные индустриальные нагрузки
• проприетарный протокол удалённого рабочего стола — сравним с VMware Blast по результатам тестов
• встроенный шлюз внешнего доступа с аутентификацией и политиками подключения
• распределённый центр управления с кворумом и отказоустойчивость: автоматический перезапуск виртуальных машин при отказе сервера
• готовые интеграции: LDAP, RADIUS, SSO, системы мониторинга

Установка платформы на подготовленное оборудование в типовой конфигурации — от одного рабочего дня; перенос нагрузок — отдельный этап. Автоматизированный установщик, минимум ручных конфигураций.

С чего начать миграцию: практический порядок действий

Миграция с VMware — это не разовое событие, а управляемый процесс. Он не требует полной остановки инфраструктуры и может выполняться поэтапно:

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

Ключевой принцип: новая платформа должна работать параллельно с VMware до момента полной миграции. Это обеспечивает возможность отката и снижает риски для бизнес-процессов.

На что обратить внимание при выборе платформы для миграции

• Собственный гипервизор или надстройка над чужим — это определяет долгосрочную независимость
• Наличие в реестре российского ПО и статус сертификации ФСТЭК
• Скорость развёртывания — от этого зависит время простоя при миграции
• Поддержка существующих интеграций: Active Directory, системы мониторинга, резервного копирования
• Поддержка вендора: как быстро реагируют на инциденты и выпускают обновления

Архитектурная специфика Inscale

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

Стандартный путь — взять связку KVM + Libvirt и собирать поверх неё VDI-функционал. Это быстрее в разработке, но накладывает ограничения: control level, проброс устройств, работа с памятью, High Availability — всё это унаследовано из Libvirt и не контролируется командой полностью.

Inscale пошёл другим путём: в основе слоя виртуализации — KVM/QEMU с доработками команды, а сервисы управления, сеть, балансировку и протокол доставки рабочих столов команда развивает сама. Это даёт контроль над поведением системы и возможность оптимизации под задачи заказчиков.

Как устроена миграция с VMware на Inscale

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

Типовой сценарий перехода:

1. Аудит текущей инфраструктуры — сколько виртуальных машин, какие профили нагрузки, какие требования по безопасности.
2. Развёртывание тестового контура от одной ноды — для пилота не нужна СХД, достаточно сервера с локальными дисками.
3. Перенос 10–15% нагрузки в тестовый контур, проверка совместимости и производительности.
4. Поэтапная миграция остальных виртуальных машин — с согласованными окнами переключения.
5. Вывод VMware из эксплуатации, переподписание лицензионных обязательств.

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

Пример из проекта: платформа на 1500 пользователей

В одном проекте по замещению VMware VDI развёртывание и настройка платформы на 1500 пользователей заняли полтора дня — большую часть времени занял монтаж Debian-based дистрибутива на серверы. Перевод пользователей — отдельный этап со своим графиком. Кластер вырос от одной ноды до 11 серверов с подключением к нескольким Gateway, Radius-серверу, LDAP-директории и SSO.

Такой срок — следствие архитектурных решений: горизонтальное масштабирование, хранение истории событий в управляющем слое (Event Sourcing), готовая интеграция с типовыми системами авторизации.

7 вопросов, которые нужно задать до миграции

1. Сколько у нас виртуальных машин и на каких гипервизорах они сейчас работают?
2. Какое ПО критично для бизнеса и как оно поведёт себя на новой платформе?
3. Какие у нас требования по безопасности — ФСТЭК, КИИ, сертификаты, изолированные сегменты?
4. Какой бюджет на проект — включая лицензии, работы, обучение и возможные простои?
5. Кто в команде отвечает за миграцию и хватает ли компетенций или нужна помощь интегратора?
6. Какой срок допустим для всего проекта и какие окна простоя мы можем позволить?
7. Что мы делаем с текущими контрактами VMware — продление, заморозка, выход?

Как устроен импорт виртуальных машин в Inscale

Перенос виртуальной машины с VMware — это не только конвертация диска: гостевую ОС нужно подготовить к новому виртуальному оборудованию — контроллеру диска, сетевой карте, прошивке. В Inscale эта часть собрана в одном мастере.

• Форматы. Платформа принимает образы RAW, VMDK, QCOW2, VDI, VHD, VHDX и Parallels. В мастере выбирается файл и хранилище, образ преобразуется в диск виртуальной машины. Загруженный исходный файл после конвертации удаляется, поэтому резервную копию держат отдельно.
• Драйверы. Опция «Подключить драйверы к гостевой ОС» подключает к машине носители с драйверами VirtIO и Win32 — установка идёт из гостевой системы, без поиска и загрузки пакетов вручную.
• Виртуальное оборудование. Шина диска и модель сетевой карты выбираются в мастере. Если Windows ещё не знает драйвер VirtIO, машину можно запустить на совместимом эмулируемом контроллере, установить драйвер и переключиться на VirtIO.
• Проверка после импорта: диски и их актуальность, загрузка ОС, драйверы, сеть и адреса, активация Windows, время, работа приложений.

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

Заключение

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

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

Хотите получить оценку миграции под вашу инфраструктуру — напишите нам. Посчитаем объём работ, сроки и стоимость проекта на основе количества ваших виртуальных машин и требований по безопасности.