Перенос инфраструктуры с VMware на другую платформу виртуализации — проект на месяцы, но пугает он сильнее, чем того заслуживает. При грамотном плане сервисы переезжают волнами, бизнес простоев почти не замечает, а команда получает управляемый процесс вместо аврала. Разбираем путь по шагам: от аудита до плана отката, с инструментами и типичными граблями.
Зачем компании уходят с VMware
Мотивы за последние годы сложились в устойчивый список. Подписки Broadcom для российских юрлиц недоступны, а работа на замороженных версиях означает накапливающиеся уязвимости ядра инфраструктуры. Субъектам КИИ регуляторика прямо предписывает замещение иностранных решений. Наконец, новое железо перестает попадать в списки совместимости старых релизов ESXi — рано или поздно гипервизор просто не встанет на купленный сервер. Чем дольше откладывается решение, тем уже выбор момента — мигрировать лучше по плану, а не по инциденту.
Шаг 1. Аудит текущей инфраструктуры
Инвентаризация всего парка
Выгружаем из vCenter полный список: машины, версии гостевых ОС, размеры дисков, сети, снапшоты. К списку добавляем то, чего в консоли не видно, — зависимости между сервисами, владельцев систем, окна, в которые каждую можно останавливать.
Категории критичности
Парк делится на три корзины: тестовые и вспомогательные системы поедят первыми, рабочие сервисы — вторыми, критичные для бизнеса — последними, когда процесс отработан до автоматизма. Такой порядок превращает рискованный проект в серию репетиций с нарастающей ставкой.
Скрытые якоря
Отдельный чек-лист — все, что цепляется за платформу: агенты резервного копирования, антивирусы уровня гипервизора, ПО с лицензией, привязанной к MAC-адресу или идентификатору оборудования, проброшенные USB-ключи. Каждый такой якорь — строка в плане работ, иначе он всплывет в худший момент.
Шаг 2. Выбор целевой платформы
Российские продукты
zVirt, Базис.DynamiX, РЕД Виртуализация, Астра «Брест» — вендорская поддержка, реестр отечественного ПО, сертификаты для регуляторов. Логичный выбор для госсектора, КИИ и компаний, которым нужен договор SLA.
Открытые платформы
Proxmox VE и oVirt бесплатны, развиваются сообществами и закрывают типовые сценарии виртуализации. Расплата — сопровождение собственными силами. Подробное сравнение платформ — тема отдельного разговора; здесь важно одно: выбирать стоит до пилота, а не после. Если фаворита нет, обкатайте двух кандидатов параллельно — неделя на стенде скажет больше месяца переговоров.
Критерии, которые реально работают
Смотрите на четыре вещи: есть ли штатный инструмент миграции именно с VMware, поддерживается ли ваша СХД, что с резервным копированием и сколько стоит поддержка на три года вперед. Маркетинговые сравнения функций можно пропустить — базовый набор у всех зрелых платформ совпадает.
Шаг 3. Подготовка целевой площадки
Параллельный контур или ротация хостов
Идеальный сценарий — параллельная площадка: новые серверы виртуализации разворачиваются рядом со старой, машины переезжают без спешки, старое железо высвобождается и встает в резерв. Бюджетный вариант — ротация: из кластера VMware выводится один хост, переустанавливается под новую платформу, принимает первую волну, затем цикл повторяется. Дольше и рискованнее, зато без закупки.
Сеть и хранилище
Обе площадки должны видеть общие VLAN — тогда машина после переезда сохраняет адресацию. Если СХД одна на двоих, проверьте, что целевая платформа умеет работать с ней по тем же протоколам: это снимает самый тяжелый этап — перекачку томов.
Судьба старого железа
Хосты из-под ESXi редко уходят на свалку: часть переустанавливается под новую платформу и пополняет кластер, часть становится площадкой резервного копирования или тестовым контуром. Этот маневр закладывается в план заранее — тогда проект обходится минимальной докупкой.
Бэкап перед стартом
Полная копия всех машин до начала работ — не формальность, а страховка всего проекта. Система резервного копирования должна уметь восстанавливать на обе платформы: тогда она же становится запасным каналом миграции.
Шаг 4. Инструменты переноса
Что происходит при конвертации
Диски VMDK переводятся в формат QCOW2 или RAW, гостевая система получает драйверы virtio вместо VMware Tools, конфигурация машины пересобирается под новый гипервизор. Автоматика virt-v2v закрывает типовые случаи; руками остаются сетевые настройки и все, что вы пометили на аудите как якоря.
Шаг 5. Пилот и волны
Пилот: две-три машины на неделю
Для первой пробы берут некритичные, но живые системы — не пустышки. Неделя наблюдения отвечает на главные вопросы: корректно ли конвертируются диски, как ведет себя производительность, работает ли резервное копирование на новом месте. Из удачного пилота рождается регламент: точный порядок действий на одну машину. Документ живет — каждая следующая волна дописывает в него встреченные грабли.
Волны миграции
Дальше парк едет группами по 5-15 машин: вспомогательные, затем рабочие, последними — критичные в согласованные окна. Между волнами закладывают паузу на стабилизацию. Темп зависит от объема дисков: перенос терабайта занимает около часа даже по 10GbE, потому что скорость ограничивает не сеть, а конвертация и запись на целевое хранилище, — и именно копирование определяет окно простоя: каждая виртуальная машина получает свое, обычно от получаса до нескольких часов.
Сколько длится проект целиком
Ориентир для парка в 20-30 машин — один-два месяца с учетом пилота, волн и пауз. Темп удваивается, если два инженера ведут параллельные волны. Ускоряют процесс общая СХД, штатный мигратор и заранее установленные драйверы; затягивают — недоступность владельцев систем и непредвиденные якоря из шага 1.
Регламент одной машины
Из пилота рождается короткий документ — последовательность действий на единицу переноса: финальный бэкап, остановка, копирование и конвертация, первый старт, проверка сети и служб, подпись владельца системы. Когда каждый шаг записан, волну из пятнадцати машин может вести дежурный инженер, а не архитектор проекта.
Тестирование после переноса
Формальный старт ВМ — еще не успех. Тестирование включает прикладной уровень: открывается ли база, ходят ли интеграции, укладывается ли отклик в привычные рамки. Чек-лист проверок готовит владелец сервиса заранее — у него на это неделя пилота.
Типичные проблемы и как их обойти
Windows не загружается после переноса
Классика жанра: система не видит диск, потому что драйверы virtio не были установлены заранее. Лечится профилактикой — пакет ставится в гостевую ОС еще на стороне VMware, до конвертации.
Несовпадение режима загрузки
Машина, созданная под UEFI, не стартует в режиме BIOS — и наоборот. Режим проверяется на аудите и явно указывается при создании целевой ВМ; угадывать бесполезно.
Слетевшая сеть
После конвертации интерфейсы получают новые имена, и статические адреса остаются на осиротевших конфигурациях. В регламент вносится пункт: проверить адресацию и маршруты сразу после первого старта, до передачи машины владельцу.
DNS и переключение пользователей
Чтобы клиенты не стучались по старому адресу, за сутки до окна у нужных записей снижают TTL до пяти минут. Тогда переключение сервиса на новую площадку проходит для пользователей незаметно, а после стабилизации значение возвращают. Мелочь из тех, что отличает гладкий переезд от утра с жалобами.
Лицензии, привязанные к железу
Софт, считающий идентификатор оборудования, после переезда решает, что его украли. Список такого ПО составляется заранее, у вендоров запрашивается перенос активации — на это закладывайте дни, а не часы.
Команда проекта: кто нужен и когда
Минимальный состав — инженер виртуализации, администратор сети и владельцы переносимых систем; безопасность подключается на этапах с персональными данными и КИИ. Внешний подрядчик оправдан в двух точках: на старте, когда нужен опыт чужих миграций для плана, и на критичных волнах, где цена ошибки максимальна. Рутинные волны команда обычно ведет сама — по регламенту из пилота.
Частные случаи, требующие отдельного плана
Многотерабайтные диски
Файловый архив на 20 ТБ не влезает ни в какое разумное окно. Для таких машин применяют предварительную синхронизацию: основная масса данных копируется заранее, на работающем сервисе, а в окно остановки доезжает только дельта последних часов. Поддержка инкрементального копирования у выбранной СРК решает половину этой задачи.
СУБД и службы каталога
Системы с собственной репликацией удобнее переносить ролями, а не образами: на целевой площадке поднимается свежая реплика или дополнительный контроллер домена, данные перетекают штатными средствами, затем роли переключаются. Конвертация образа здесь проигрывает по всем статьям — от времени до рисков целостности.
Машины с GPU и аппаратными ключами
Проброс устройств настраивается на целевом гипервизоре заново и заранее: видеокарты, USB-ключи лицензий, токены. Для ключей предусмотрены сетевые концентраторы — иногда проще вынести их из машины совсем, чем тащить проброс через миграцию.
План отката: страховка, которая дает спать
Исходные машины не удаляются до официальной приемки — они выключены и ждут. Если на новой площадке что-то идет не так, сервис в течение часа поднимается на старом месте простым включением. Критерий приемки формулируется заранее: сервис отработал под боевой нагрузкой одну-две недели без замечаний. Только после этого старая копия уходит в архив, а ее место в хранилище освобождается. Отдельно фиксируются точки невозврата — моменты, после которых возврат дороже движения вперед: например, когда на новой площадке накопились свежие данные. К таким точкам подходят только с проверенными волнами.
Таймлайн типового проекта
Календарь для парка в 20-30 машин выглядит так. Первая и вторая недели — аудит, выбор целевой системы, согласование бюджета. Третья — подготовка площадки: установка, сети, подключение хранилища и СРК. Четвертая и пятая — пилот с наблюдением. С шестой по девятую идут волны переноса с паузами на стабилизацию. Десятая — приемка, разбор старого контура, передача документации. Запас на непредвиденное закладывают около 20% длительности — он расходуется всегда.
Сводный чек-лист перед стартом
Перед первой волной должно быть готово: полная инвентаризация с категориями критичности и списком якорей; выбранная и развернутая целевая площадка с доступом к нужным VLAN; свежие резервные копии всего парка с проверенным восстановлением; драйверы virtio в Windows-гостях; регламент переноса из пилота; согласованные окна и контакты владельцев систем; критерии приемки и план отката. Если хотя бы один пункт провисает — волну переносят, а не надеются на удачу.
Часто задаваемые вопросы (FAQ)
С чего начать миграцию с VMware?
С инвентаризации: полный список машин, зависимости, категории критичности, якоря вроде привязанных лицензий. Все остальные шаги опираются на эту картину.
Какими инструментами переносят ВМ?
Основные пути: virt-v2v для KVM-платформ, штатные миграторы коммерческих продуктов, ручная конвертация qemu-img и восстановление из резервной копии на новую площадку.
Что делает virt-v2v?
Забирает машину из ESXi или vCenter, конвертирует диски в QCOW2 и заменяет VMware Tools на драйверы virtio. На выходе — готовая к запуску ВМ под KVM.
Сколько времени занимает переезд?
Парк на 20-30 машин — ориентировочно один-два месяца волнами. Одна машина переносится за время копирования ее дисков плюс проверки: от получаса до нескольких часов.
Возможна ли миграция совсем без остановки?
Полностью без пауз — нет: офлайн-окно на финальное копирование нужно каждой машине. Минимизируют его предварительной синхронизацией дисков и переносом в нерабочие часы.
Почему Windows-машина не стартует на новой платформе?
В девяти случаях из десяти — нет драйверов virtio, и система не видит диск. Ставьте их заранее, до конвертации, и проблема не возникнет.
Нужно ли покупать новое железо?
Не обязательно: рабочая схема — поэтапная ротация существующих хостов под новую платформу. Параллельная площадка удобнее и быстрее, но это вопрос бюджета, а не технической необходимости.
Когда можно удалить исходные ВМ?
После формальной приемки: сервис стабильно отработал на новом месте одну-две недели под реальной нагрузкой. До этого момента старые копии — ваш план отката.
Спланируем переезд вместе
Мы помогаем компаниям уходить с VMware на российские и открытые платформы: рассчитаем целевую площадку, подберем серверы под Proxmox, zVirt или Базис, спланируем волны и окна простоя. Конфигурацию закладываем с запасом под рост парка — чтобы следующий переезд случился по вашему желанию, а не по нужде. Оставьте заявку — пришлем план и спецификацию.
