Импортозамещение VMware упирается не в выбор гипервизора, а в две задачи, которым уделяют мало внимания: как именно перенести машину, чтобы она загрузилась с первого раза, и сколько часов бизнес будет простаивать. Ниже — разбор обеих задач, плюс платформы, деньги и сроки образца второй половины 2026 года.
Почему тянуть с уходом с VMware стало дороже, чем мигрировать
Продлить SnS из России невозможно, купить новые ядра — тоже. С ноября 2025 года Broadcom работает по схеме VCF 9 с моделью License Portability (BYOL): подписку клиент покупает напрямую у Broadcom и переносит её только к тем площадкам, которые Broadcom допускает, — российские провайдеры в этот периметр не входят. Регуляторный календарь давит с другой стороны:
- Реестр отечественного ПО — для 44-ФЗ и части закупок по 223-ФЗ платформа должна быть в реестре Минцифры. VMware там нет и не будет.
- 187-ФЗ и субъекты КИИ — переход значимых объектов на доверенные ПАК идёт поэтапно, крайний ориентир 1 января 2030 года (постановление Правительства РФ № 1912), а проект замены виртуализации занимает от года.
- Приказ ФСТЭК №117 с 1 марта 2026 года заменил собой приказ №17 и ужесточил требования к средствам виртуализации в аттестуемых контурах.
- 152-ФЗ и ИСПДн — в аттестованном сегменте обязательны сертифицированные СЗИ среды виртуализации, а их совместимость с неподдерживаемым ESXi — отдельная сложная задача.
Риски эксплуатации бессрочных лицензий без поддержки и патчей
Бессрочная лицензия не даёт доступа к обновлениям. За три года в vCenter и ESXi закрыто несколько уязвимостей выше 9.0 по CVSS — часть позволяет выполнить код на гипервизоре из гостевой машины. Эксплойты публичны, сканеры их находят, патчи вам недоступны. Дальше: шифровальщики целенаправленно атакуют ESXi — компрометация сети управления шифрует хранилища целиком; отказавшее железо не заменить, потому что новый сервер не проходит по списку совместимости замороженной версии; расследование инцидента упирается в аудит, где ответ «вендор ушёл» юридически не работает.
Как снизить риск, пока миграция ещё не началась
- Изолируйте плоскость управления. vCenter, интерфейсы ESXi, iLO/iDRAC — в отдельный VLAN без выхода в интернет, доступ только через защищённый узел с MFA.
- Закройте лишнее на гипервизорах. SSH выключен, режим блокировки включён, брандмауэр ESXi разрешает только серверы управления и копирования.
- Выведите копии за пределы среды виртуализации. Копии, доступные из-под учётной записи vCenter, теряются вместе с продуктивом. Минимум — отдельное хранилище, лучше неизменяемые копии.
Эти меры дают 6–12 месяцев спокойной работы, чтобы сделать переход без спешки.
Куда переходить: российские платформы виртуализации и критерии выбора
Почти все российские платформы построены на связке KVM/QEMU/libvirt и различаются управляющим слоем, зрелостью кластерных механизмов и состоянием сертификатов.
| Платформа | Основа и особенности | Где применима |
|---|---|---|
| zVirt (Orion soft) | Архитектура oVirt, ближе всех к логике vSphere: кластер, живая миграция, HA, шаблоны. Есть своё распределённое хранилище | Универсальный сценарий «вместо vSphere», средние и крупные кластеры |
| РЕД Виртуализация (РЕД СОФТ) | Та же родословная oVirt, связка с РЕД ОС, штатный импорт машин из ESXi | Госсектор, единый отечественный стек |
| Basis Dynamix | Широкая линейка: частное облако, VDI, контейнеры, оркестрация | Крупные предприятия, внутренние облака |
| SpaceVM (экосистема виртуализации Space) | Свой управляющий слой, развитая SDN, сильные позиции в защищённых контурах | КИИ, аттестованные сегменты |
| vStack HCP | Гиперконвергенция на гипервизоре vStack HV (на основе bhyve), высокая плотность машин на узел | Провайдеры, компактные отказоустойчивые кластеры |
| VMmanager (ISPsystem) | Лёгкий управляющий слой, быстрое развёртывание | Хостинг, небольшие и средние инсталляции |
| Кибер Инфраструктура | Виртуализация в связке с SDS и системой копирования одного вендора | «Виртуализация + хранение + копии» от одного поставщика |
| Альт Виртуализация (Базальт СПО) | Дистрибутив на базе Альт с несколькими редакциями, включая редакцию PVE на Proxmox VE 9.1 с SDN | Организации на Альт Линукс |
| Proxmox VE / KVM+libvirt / OpenStack | Открытый стек без лицензий, но без вендорской ответственности и реестра | Разработка, некритичный продуктив |
Разумная схема: коммерческая сертифицированная платформа под регулируемый контур и Proxmox либо чистый KVM под разработку и тесты. Выбирают так: сначала разложите нагрузки по контурам (КИИ, ГИС, ИСПДн, продуктив, разработка, VDI), под каждый определите обязательные требования — реестр, сертификат ФСТЭК, класс защиты, — и только потом сравнивайте функциональность. Обратный порядок — самая дорогая ошибка в таких проектах.
Сертифицированная и коммерческая редакции: в чём практическая разница
Сертифицированная ФСТЭК сборка — отдельная ветка, зафиксированная на версии, прошедшей испытания. Отсюда: функциональность отстаёт от коммерческой на год-полтора; каждое обновление требует инспекционного контроля, а установить свежий пакет самостоятельно нельзя — слетит соответствие; цена выше, лицензии двух веток невзаимозаменяемы. Если аттестация нужна части инфраструктуры, разведите контуры и лицензируйте по факту.
Чего российские платформы пока не умеют по сравнению с vSphere
- Автоматическая балансировка уровня DRS. Механизмы распределения есть почти везде, но политики заметно проще. Плотность размещения планируется вручную.
- Fault Tolerance. Непрерывной работы машины на двух узлах фактически нет. Отказоустойчивость строится на HA — перезапуск на живом узле, то есть минуты недоступности.
- SDS против vSAN. Распределённые хранилища моложе и требовательнее к конфигурации сети и дисков. Сценарии деградации проверяйте на стенде.
- Наследие PowerCLI. Скрипты выбрасываются, взамен — REST API, Ansible и Terraform разной зрелости. Переписывание автоматизации обычно недооценено.
Заявление «мы покрываем 95% возможностей VMware» проверяется тестами на своём контуре: живая миграция машины на 256 ГБ под нагрузкой на запись; отказ узла с 30 машинами и замер восстановления; обновление платформы под нагрузкой; диски более 4 ТБ и цепочки снимков; проброс GPU для VDI.
Замена гипервизора тянет за собой экосистему. Veeam ушёл — нужна новая система копирования (Кибербэкап, RuBackup, Basis) с проверкой работы на уровне снимков, а не только агентами в госте. Старые копии VMware-машин в новую среду напрямую обычно не восстанавливаются. Дальше: агенты мониторинга, интеграция с AD/LDAP, сертифицированные СЗИ, многопутевой доступ к хранилищу, DR-площадка.
Собственное железо, частное облако провайдера или гибрид
Собственное железо. Максимальный контроль и предсказуемая стоимость на длинном горизонте, но капзатраты сразу и сроки поставки 8–16 недель. Плюс проблема курицы и яйца: чтобы перестроить кластер, нужно освободить узлы, а работающие машины куда-то перенести.
Частное облако провайдера. Капзатрат нет, площадка готова за дни. Провайдер отвечает за ЦОД, серверы, гипервизор и сеть до вашей границы, вы — за гостевые ОС, приложения, доступы, данные и копии. Границу фиксируйте письменно до старта.
Гибрид. Регулируемый контур — на своё железо, остальное — в облако. Самый частый выбор у среднего бизнеса.
Отдельно — облако как временная площадка на период миграции: вы переносите нагрузку к провайдеру, освобождаете собственные серверы, перестраиваете их под новую платформу без ночных окон, затем возвращаете машины обратно либо оставляете часть в облаке. Приём убирает главное ограничение проекта — необходимость мигрировать на то же железо, на котором работает продуктив.
Для такой временной площадки подходит аренда облачного сервера в Cloud4U: ресурсы CPU, RAM и диска выделяются под задачу и масштабируются по мере переноса волн, тарификация почасовая — вы платите ровно за время проекта. Инфраструктура размещена в собственных ЦОД уровня Tier III, управление виртуальным дата-центром ведётся через Cloud Director, что для команды с опытом vSphere означает знакомую логику. Есть бесплатный тестовый период — удобно под пилот и проверку конвертации нескольких машин.
Что смотреть в договоре, помимо цены: SLA на доступность с указанием, что измеряется и как считается компенсация; сценарий выхода — в каком формате вы получите машины при расторжении (образ диска, OVA/OVF, qcow2) и платная ли выгрузка; аттестация сегмента — если провайдер держит аттестованный сегмент, предметом аттестации остаётся только ваша ИС.
Что делать со старым железом, не проходящим по списку совместимости
Список совместимости консервативен: разверните узел на одном сервере, прогоните нагрузочные тесты, согласуйте статус с вендором. Не прошедшее — под некритичные задачи. Часто дело не в сервере, а в контроллере хранилища или сетевой карте — замена платы дешевле замены узла. Отдельный случай — прикладное ПО, вендор которого поддерживает только VMware (промышленные и медицинские системы): такой контур остаётся на VMware, изолируется по сети и выводится из аттестуемого сегмента.
Сайзинг новой площадки: почему конфигурации ВМ не переносятся один в один
- Механики работы с памятью различаются. Балансировщик памяти и дедупликация страниц VMware позволяли жить с переподпиской 1,2–1,5 к 1. В KVM закладывайте не более 1,1 к 1, а для баз данных и 1С — без переподписки.
- Планировщик процессора устроен иначе. Машины с большим числом vCPU чувствительнее к конкуренции за ядра. Значительная часть машин имеет 8 vCPU при загрузке 5% — есть возможность сократить конфигурации и сэкономить на лицензиях.
- NUMA перестаёт прощать ошибки. Машина, чья память не помещается в один узел NUMA, теряет в производительности заметнее, чем на vSphere.
- Дисковая подсистема. На SDS полезная ёмкость считается после фактора репликации (×2 или ×3) плюс резерв на восстановление при отказе узла.
Механика переноса: от инвентаризации до переключения
Шаг 1. Инвентаризация. Полный список машин через RVTools или API vCenter: не только vCPU/RAM/диски, но и версия и разрядность гостевой ОС, режим загрузки (BIOS/UEFI, Secure Boot), тип контроллера диска, наличие RDM и общих дисков кластера, цепочки снимков, проброшенные устройства, MAC-адреса, VLAN.
Шаг 2. Карта зависимостей. Самая недооценённая часть. За машиной тянутся сервер приложений, база, служба каталогов, сервер лицензий, интеграционная шина. Карта собирается из сетевых потоков, правил экрана, балансировщиков и разговоров с владельцами систем. Ошибка стоит дороже всего: переносите один сервер, а падают три соседних из-за жёстко прописанного IP.
Шаг 3. Классификация нагрузок. Некритичные (тест, служебные), средней критичности (окно в несколько часов), критичные (окно 15–60 минут), особые (кластеры СУБД, 1С, проброшенные устройства, машины больше 2 ТБ).
Шаг 4. Пилот. 10–15 машин разного типа ОС. Задача не «перенести», а замерить: сколько занимает конвертация машины на 200 ГБ, какие сбои возникают, сколько уходит на проверку после запуска.
Шаг 5. Волны. Дальше волнами по 20–50 машин, от менее критичных к более критичным, связанные системы — в одной волне. Старая среда работает параллельно, пока новая не подтвердит стабильность.
V2V — конвертация машины из формата одной платформы в формат другой: VMDK превращается в qcow2 или raw, описание оборудования переписывается под новый гипервизор. Инструменты: virt-v2v забирает машину напрямую из vCenter или ESXi, конвертирует диск и правит гостевую систему — ставит драйверы VirtIO, чинит загрузчик, удаляет следы VMware Tools; qemu-img делает быструю низкоуровневую конвертацию, но гостя не трогает, без VirtIO машина не загрузится; Hystax Acura и аналоги дают репликацию через агенты с досинхронизацией и коротким окном переключения; штатный импорт платформы — самый простой путь, если поддерживает вашу версию.
Сетевые нюансы: проверочные запуски делайте только в изолированной сети или с отключённым адаптером — иначе получите конфликт IP с работающей машиной; разница MTU между площадками даёт не отказ, а плавающие просадки скорости; транки новых узлов должны нести те же VLAN; при смене IP или подсети ломаются правила экрана, доступы к базам по адресу и интеграции, где ваш адрес зарегистрирован у контрагента.
Подготовка гостевой ОС и типовые сбои после конвертации
Правило, экономящее больше всего времени: всё, что можно сделать внутри работающей машины до выключения, надо сделать до выключения.
Порядок для Windows Server:
- Установить драйверы VirtIO (блочный, сетевой, шина памяти) заранее, пока машина работает на VMware. Иначе получите синий экран с ошибкой недоступного загрузочного устройства.
- Проверить режим загрузки: при UEFI с Secure Boot его надо либо поддержать на новой платформе, либо отключить до переноса.
- Записать IP-конфигурацию отдельно: MAC меняется, Windows создаёт новый профиль подключения со сброшенными статическими настройками. Учтите и активацию — смена «железа» может потребовать переактивации.
- Удалить VMware Tools до выключения — после конвертации служба штатно не удаляется и мешает сетевому стеку. Затем поставить qemu-guest-agent, без него платформа не завершит работу гостя корректно и не снимет согласованные копии.
Для Linux проще: современные ядра несут VirtIO внутри, но проверьте наличие модулей в initramfs и способ монтирования в fstab. Если разделы примонтированы по имени устройства (/dev/sda1), а не по UUID, после смены контроллера система уйдёт в аварийный режим.
Что ещё ломается чаще всего:
- Снимки. Машину с активной цепочкой конвертировать нельзя — сначала объединяйте, причём объединение снимка на 500 ГБ само занимает время и нагружает хранилище.
- Диски RDM и общие диски кластеров. Прямой доступ к тому не конвертируется: либо перевод на обычные виртуальные диски с копированием, либо перестроение кластера с нуля.
- Большие машины. Для машины на 4 ТБ окно считается арифметически: по 10G-сети при реальных 400–500 МБ/с это 2,5–3 часа только на копирование, плюс конвертация и проверка. Если такое окно недопустимо — только репликация с досинхронизацией.
Перенос 1С-контуров: лицензии, дисковая задержка, порядок остановки и запуска
Лицензии и ключи. Программные лицензии 1С привязаны к параметрам оборудования — при смене процессора, MAC и серийных номеров слетают. Получите у поставщика пин-коды для повторной активации либо вынесите сервер лицензий отдельно. Ключи HASP, проброшенные по USB, требуют сетевого ключа с менеджером лицензий: прямой проброс порта при переезде в облако невозможен в принципе.
Дисковая задержка. Критична не пиковая пропускная способность, а задержка на записи: ориентир — средняя до 1 мс, устойчивые всплески выше 5 мс пользователи видят как подтормаживания при проведении документов. Замерьте показатель до миграции, иначе потом не докажете, стало хуже или так и было.
Порядок остановки и запуска. Останавливать: клиентские сеансы и веб-публикации, затем сервер приложений, затем СУБД с корректным завершением. Запускать в обратном порядке, с проверкой журналов между шагами. Регламентные задания отключите до окончания приёмки.
Сколько реально длится простой и как его сократить
Момент, когда сервис останавливается на старой площадке и поднимается на новой, существует всегда. Вопрос в его длительности — и это управляемый параметр.
Методы переключения и достижимый RTO для каждого
| Метод | Достижимый простой | Что нужно | Для чего подходит |
|---|---|---|---|
| Холодная конвертация (virt-v2v, qemu-img) | 1,5–6 часов на машину 500 ГБ–1 ТБ | Канал и место на хранилище | Некритичные системы, разработка, широкое окно |
| Репликация с досинхронизацией (Hystax Acura) | Минуты, значение проверяйте на своём контуре | Лицензии, агент репликации в гостевой ОС и контроллер на целевой площадке | Критичный продуктив, большие машины |
| Репликация на уровне системы хранения | 10–30 минут | Совместимые СХД на обеих площадках | Крупные инсталляции с одинаковыми СХД |
| Миграция на уровне приложения (реплика СУБД, вторая нода) | 1–5 минут | Поддержка репликации приложением, двойные ресурсы | Базы данных, критичные бизнес-системы |
| Балансировщик перед фермой серверов приложений | Без потери сервиса | Приложение без состояния или общая сессионная база | Веб-серверы, терминальные кластеры |
Чем критичнее система, тем выше по таблице надо подниматься — и тем дороже переключение. Для 80% парка обычной компании холодной конвертации достаточно.
Из чего складывается окно переключения критичной системы с репликацией: последняя синхронизация изменений — 3–10 минут; корректная остановка сервисов — 2–5 минут; запуск машины и загрузка ОС — 2–4 минуты при подготовленном госте; смена IP или переключение DNS — от нуля до времени жизни записи (TTL в 3600 секунд означает, что часть клиентов будет обращаться на старый адрес ещё час, TTL снижают до 60 секунд за сутки до окна); обновление ARP — 1–2 минуты; проверка интеграций — 15–40 минут, самая недооценённая часть.
Точка невозврата — момент, после которого на новой площадке появились данные, которых нет на старой. До него откат стоит минут, после — означает потерю данных либо ручное сведение расхождений. Критерии отката формулируются заранее и в измеримых величинах: сервис не поднялся за 45 минут; ключевая интеграция не работает; задержка диска превышает порог более чем вдвое; обнаружено расхождение данных.
Критерии приёмки и оценка сроков: от чего зависит вилка
| Показатель | Как измеряется | Проходное значение |
|---|---|---|
| Задержка записи на диск | fio, случайная запись 8 КБ, очередь 32 | Не хуже, чем на VMware, более чем на 15%; для СУБД и 1С — до 1 мс |
| IOPS дисковой подсистемы | fio, профиль 70/30 до и после | Отклонение от базового замера не более 10% |
| Производительность процессора | Синтетический тест в гостевой ОС до и после | Деградация не более 5% |
| Время живой миграции | Машина 64 ГБ RAM под нагрузкой на запись | До 5 минут, без разрыва сессий |
| Срабатывание HA | Выключение узла с 20 работающими машинами | Все машины запущены на других узлах за 10 минут |
| Фактический RTO | Восстановление машины 500 ГБ из копии | Замеренное значение фиксируется как норматив |
| Обновление платформы | Накат обновления на кластер под нагрузкой | Без остановки сервисов, откат отработан |
Замеры «до» на работающей VMware обязательны: без них спор о производительности превращается в обмен субъективными оценками.
Пример: кластер из 8 узлов, 220 машин, 60 ТБ дисков, корпоративный продуктив с ИСПДн, без КИИ. Сроки по фазам: инвентаризация и карта зависимостей — 3–4 недели; выбор платформы и стенд — 6–8 недель; закупка лицензий и оборудования — от 2 недель в облаке до 12–16 недель при закупке серверов; развёртывание площадки — 4–6 недель; пилот — 2–3 недели; волны переноса при 20–40 машинах в неделю — 6–10 недель; приёмка и вывод старой среды — 4 недели. Итого 7–11 месяцев на своём железе и 5–7 месяцев в облаке провайдера.
| Статья затрат (горизонт 3 года) | Своё железо | Частное облако провайдера |
|---|---|---|
| Серверы: 8 узлов (2×32 ядра, 1 ТБ RAM) | 28 800 000 ₽ | 0 ₽ (входит в подписку) |
| Система хранения на 100 ТБ полезной ёмкости | 12 000 000 ₽ | 0 ₽ (входит в подписку) |
| Лицензии платформы виртуализации на 3 года | 5 800 000 ₽ | 0 ₽ (входит в подписку) |
| Подписка на ресурсы облака (≈1 750 000 ₽/мес × 36 мес) | — | 63 000 000 ₽ |
| Система резервного копирования (лицензии + хранилище) | 4 200 000 ₽ | 3 600 000 ₽ |
| Проектирование и внедрение площадки | 3 500 000 ₽ | 1 200 000 ₽ |
| Работы по миграции (внешняя команда, 220 машин) | 5 500 000 ₽ | 5 500 000 ₽ |
| Двойные лицензии и ресурсы на 4 месяца параллельной работы | 1 900 000 ₽ | 2 300 000 ₽ |
| Обучение и сертификация 4 администраторов | 900 000 ₽ | 450 000 ₽ |
| Размещение в ЦОД: 3 стойки × 65 000 ₽/мес × 36 мес | 7 020 000 ₽ | 0 ₽ (входит в подписку) |
| Эксплуатация: 2 инженера × 3 года (с налогами) | 14 400 000 ₽ | 7 200 000 ₽ (1 инженер) |
| Продление поддержки оборудования на 2-й и 3-й годы | 6 100 000 ₽ | 0 ₽ (входит в подписку) |
| Простой при миграции: 26 часов × 180 000 ₽/час | 4 680 000 ₽ | 4 680 000 ₽ |
| Итого за 3 года | 94 800 000 ₽ | 87 930 000 ₽ |
Стоимость часа простоя считают индивидуально: средняя выручка за час плюс стоимость простаивающего персонала. 26 часов — сумма окон по всем волнам, а не единовременная остановка. Разница между сценариями за три года невелика — около 7%. На горизонте 5 лет при стабильной нагрузке своё железо обычно дешевле. Для конкретной компании итог сдвинется на ±25%.
Главные выводы
Переход с VMware в 2026 году — проект на 5–11 месяцев, в котором конвертация машин занимает меньше трети времени, а остальное уходит на инвентаризацию, выбор платформы под контуры, перестройку экосистемы и приёмку. Российская виртуализация даёт рабочую замену vSphere по базовым сценариям, но требует пересмотра привычек: без DRS, без Fault Tolerance, с более скромной переподпиской памяти и с автоматизацией, которую придётся переписать. При планировании бюджета смотрите не на цену лицензий, а на совокупные затраты за три года.
Окно простоя есть всегда, но его длительность вы выбираете сами — методом переключения и качеством подготовки. Наибольшую отдачу даёт работа до окна: заранее установленные драйверы VirtIO, снижённый TTL, объединённые снимки, замеренные показатели «до», выписанные критерии отката и зафиксированная точка невозврата.
