Как уйти с VMware без остановки бизнеса: план миграции на Proxmox, Hyper-V, KVM или Nutanix

Уйти с VMware без остановки бизнеса можно, если считать миграцию не переносом файлов ВМ, а отдельным инфраструктурным проектом: сначала провести аудит сервисов, выбрать целевую платформу, проверить перенос на пилотных машинах, подготовить сети и хранилища, затем переносить нагрузки волнами с понятным планом возврата. Полного «нуля простоя» для всех систем почти никогда не бывает, но простой критичных сервисов можно сократить до контролируемого окна и избежать ситуации, когда бизнес узнает о проблемах уже после переключения.

Что на самом деле означает миграция без остановки бизнеса

Главная ошибка — понимать «без остановки» буквально. Для бизнеса важно не то, что ни одна виртуальная машина ни разу не перезагрузилась, а то, что пользователи, клиенты, склад, бухгалтерия, производство и внешние сервисы не столкнулись с неконтролируемым простоем. Поэтому миграцию нужно планировать не по списку ВМ, а по бизнес-сервисам.

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

Перед началом проекта стоит разделить системы на три уровня:

• критичные сервисы — базы данных, ERP, CRM, платежные системы, производственные контуры, сервисы авторизации;
• важные сервисы — файловые серверы, внутренние порталы, системы разработки, мониторинг, почта;
• низкорисковые ВМ — тестовые среды, архивные системы, вспомогательные серверы, временные стенды.

Для каждого сервиса нужно определить два показателя. Первый — сколько времени он может быть недоступен. Второй — сколько данных допустимо потерять при аварии или откате. Если для системы нельзя потерять даже несколько минут изменений, простая конвертация ВМ не подойдет: понадобится репликация, штатные средства базы данных или другой способ синхронизации.

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

Почему нельзя просто сконвертировать VMDK и считать работу законченной

Виртуальная машина — это не только файл диска. Она зависит от сетевых настроек, виртуального контроллера, порядка загрузки, драйверов, политик хранилища, резервного копирования, мониторинга, лицензий и соседних сервисов. При переходе с VMware на Proxmox, Hyper-V, KVM или Nutanix меняется не только место, где лежит диск, но и часть виртуального оборудования.

После переноса может измениться сетевой адаптер, тип дискового контроллера, имя интерфейса внутри Linux, скрытый сетевой адаптер в Windows, режим загрузки BIOS или UEFI. Если приложение привязано к MAC-адресу, серийному номеру диска или аппаратному идентификатору, оно может перестать запускаться даже при успешной загрузке ОС.

Чаще всего после поверхностного переноса ломаются:

• статические IP-адреса;
• порядок сетевых интерфейсов;
• загрузка старых операционных систем;
• драйверы дискового контроллера;
• лицензии прикладного ПО;
• задания резервного копирования;
• мониторинг и оповещения;
• правила межсетевого экрана;
• интеграция с доменом и агентами безопасности;
• расписания регламентных заданий.

Отдельный риск — старые снимки ВМ. Если на исходной VMware-инфраструктуре накопились снапшоты, перенос может стать долгим и непредсказуемым. Перед миграцией нужно проверить их наличие, понять, зачем они были созданы, и по возможности аккуратно удалить или объединить.

Аудит виртуальных машин и зависимостей

Миграция начинается не с выбора конвертера, а с инвентаризации. Нельзя безопасно переносить то, что не описано. В идеале на каждую ВМ должна быть карточка: кто владелец сервиса, для чего машина нужна, какая у нее ОС, сколько ресурсов выделено, какие есть диски, сети, зависимости, резервные копии и окно обслуживания.

По каждой ВМ нужно собрать:

• имя — как название виртуальной машины, так и имя хоста;
• назначение и влияние — что на ней развёрнуто и на какие бизнес-процессы оно влияет;
• владельца сервиса и контакт для проверки;
• операционную систему и версию;
• количество процессорных ядер и объем памяти;
• размер дисков, фактически занятое место и скорость роста данных;
• тип загрузки: BIOS или UEFI;
• наличие шифрования, защищенной загрузки, виртуального TPM;
• сетевые адаптеры, VLAN, IP-адреса, MAC-адреса;
• ключевое программное обеспечение и зависимости;
• зависимости от баз данных, файловых хранилищ, каталогов, внешних API;
• наличие снимков;
• расписание резервного копирования;
• допустимое время простоя;
• допустимую потерю данных;
• критерии успешного запуска после миграции.

Отдельно нужно найти «красные флаги». Это ВМ со старыми ОС, машины с USB-ключами, проброшенными PCI-устройствами, GPU, нестандартными сетевыми настройками, RDM-дисками, старыми агентами безопасности, неизвестным владельцем или отсутствующей резервной копией. Такие системы нельзя переносить в общей волне. Для них нужен отдельный план.

Полезно построить карту зависимостей. Например, веб-сервер может зависеть от базы данных, база — от сетевого хранилища, авторизация — от контроллера домена, а доступ пользователей — от балансировщика и DNS. Если перенести только одну ВМ и забыть о цепочке, формально машина запустится, но сервис для пользователей останется недоступным.

Выбор платформы: Proxmox, Hyper-V, KVM или Nutanix

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

Proxmox часто выбирают компании, которым нужна контролируемая стоимость, понятная веб-панель, кластеризация, ZFS или Ceph. В Proxmox VE есть официальные материалы по переходу с других гипервизоров, а в документации описан импорт ВМ из VMware ESXi через встроенный мастер импорта. Это упрощает старт, но не отменяет проверки драйверов, сети, загрузки и резервного копирования после переноса.

Hyper-V логичен там, где большинство серверов работает на Windows, используется Active Directory, Windows Server, System Center или Windows Admin Center. Microsoft описывает перенос VMware → Hyper-V через расширение VM Conversion в Windows Admin Center: сначала выполняется синхронизация дисков, а финальная миграция планируется отдельно, чтобы уменьшить простой.

KVM подходит компаниям, которые готовы строить платформу на Linux-основе: через libvirt, OpenStack, другие решения или собственную автоматизацию. Для миграции в такой сценарий часто используют virt-v2v: инструмент преобразует гостевые системы из VMware и других гипервизоров для запуска на KVM и может подготовить гостевую ОС к работе с нужными драйверами.

Nutanix имеет смысл рассматривать, если компания хочет не просто заменить VMware, а перейти на готовую гиперконвергентную архитектуру с единым управлением вычислениями и хранилищем. Nutanix Move использует миграционные планы, предварительное заполнение данных и финальное переключение, что помогает снижать простой при переносе ВМ.

Проектирование новой архитектуры до переноса ВМ

Нельзя просто взять список виртуальных машин из VMware и создать такие же на новой платформе. За годы эксплуатации ВМ часто получают больше ресурсов, чем реально используют. У одних машин завышена память, у других — слишком много виртуальных процессоров, у третьих — диски давно разрослись из-за логов, временных файлов и старых данных.

Перед переносом нужно посмотреть реальную нагрузку хотя бы за 30–90 дней: среднее и пиковое потребление процессора, памяти, дисков и сети. Особенно внимательно нужно оценивать крупные базы данных, файловые серверы и системы, чувствительные к задержкам диска. Если новая платформа формально имеет столько же ресурсов, но другое хранилище или сетевую схему, производительность может измениться.

По вычислительным ресурсам важно:

• не переносить CPU и память механически один к одному;
• проверить пиковые нагрузки;
• заложить запас на отказ одного узла;
• не перегружать кластер сверх разумного;
• учитывать NUMA для крупных ВМ;
• заранее определить, какие машины должны запускаться первыми после аварии.

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

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

По сети нужно заранее сопоставить группы портов VMware с сетями новой платформы: VLAN, мосты, виртуальные коммутаторы, правила на физических коммутаторах, MTU, маршрутизацию, межсетевые экраны, балансировщики и DNS. Если этого не сделать, ВМ может успешно запуститься, но оказаться в неправильном сегменте или потерять связь с базой данных.

Выбор способа миграции

Нет одного способа, который одинаково хорошо подходит для всех ВМ. Простые машины можно переносить через импорт или конвертацию. Критичные базы данных лучше переносить через репликацию или штатные инструменты приложения. Старые и замусоренные системы иногда безопаснее пересоздать.

Прямая конвертация подходит для простых серверов: небольшие внутренние приложения, тестовые среды, вспомогательные сервисы. Но даже здесь нужно проверять загрузочный режим, драйверы, сетевой адаптер, контроллер диска, состояние файловой системы и наличие старых снимков.

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

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

Пересборка сервиса часто выглядит более трудоемкой, но в долгосрочной перспективе оказывается надежнее. Если ВМ много лет не обновлялась, содержит старые временные настройки и неизвестные зависимости, перенос «как есть» только закрепит технический долг на новой платформе.

Пилотная миграция

Пилот нужен не для галочки. Он должен проверить весь будущий процесс: от подготовки ВМ до приемки владельцем сервиса. Для пилота лучше выбрать не самую простую и не самую критичную машину, а несколько типовых ВМ: одну Windows, одну Linux, одну машину с несколькими дисками, одну с типичной сетевой схемой и одну, похожую на продуктивную нагрузку.

Во время пилота нужно измерить:

• сколько времени занимает перенос 100 ГБ и 1 ТБ данных;
• как быстро читаются данные из VMware;
• как быстро они записываются в новую платформу;
• что происходит при первом запуске, стартует ли система;
• сохраняются ли IP-настройки;
• как меняется производительность дисков;
• работает ли ключевое ПО;
• видит ли мониторинг новую ВМ;
• запускается ли резервное копирование;
• сколько ручных действий требуется инженеру.

После пилота должен появиться рабочий шаблон миграции. В нем фиксируются типовые ошибки, порядок подготовки, список проверок, критерии успеха и действия при откате. Если пилот показал, что часть ВМ требует ручной настройки сетей или драйверов, причём до этапа конвертации, это нужно учитывать при планировании сроков, а не надеяться, что на продуктивных системах «как-нибудь пройдет».

Подготовка ВМ перед переносом

Перед миграцией каждая ВМ должна пройти подготовку. Минимальный набор действий: проверить актуальную резервную копию, убедиться, что восстановление возможно, удалить старые снимки, очистить временные файлы, проверить файловую систему, зафиксировать IP-адреса, маршруты, DNS, список служб и конфигурации приложения.

Для Windows-серверов особенно важны драйверы и сетевые адаптеры. После переноса система может увидеть новый адаптер, а старый останется скрытым. Из-за этого статический IP иногда оказывается привязан к несуществующему устройству. Также стоит заранее проверить активацию Windows и прикладного ПО, службы, зависящие от имени интерфейса, и агенты безопасности.

Для Linux-серверов нужно проверить загрузчик, initramfs, fstab, имена сетевых интерфейсов, правила udev, cloud-init, если он используется, и поддержку нужных драйверов. Старые дистрибутивы могут не загрузиться без предварительной подготовки.

Хорошая практика — перед переносом сохранить:

• вывод сетевых настроек;
• таблицу маршрутов;
• список дисков и точек монтирования;
• список запущенных служб;
• конфигурации приложения;
• последние журналы ошибок;
• данные о производительности до миграции.

Это поможет быстро понять, что изменилось после запуска на новой платформе.

Перенос сетей и хранилища

Сеть нужно готовить до переноса ВМ. Для каждой группы портов VMware должна быть понятная целевая сеть: VLAN, мост, виртуальный коммутатор, физический порт, правила маршрутизации и межсетевого экрана. Отдельно нужно проверить trunk- и access-порты на физических коммутаторах, MTU, балансировщики, NAT-правила и DNS.

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

Хранилище требует не меньшего внимания. Нельзя смешивать все нагрузки в одном пуле только потому, что «места хватает». Базы данных, файловые архивы, системные диски и временные данные дают разный профиль нагрузки. Для одних важны задержки, для других — последовательная запись, для третьих — емкость и резерв.

Перед миграцией нужно проверить:

• где будут лежать системные и дополнительные диски;
• как работает тонкое выделение места;
• сколько нужно временного пространства;
• как новая платформа делает снимки;
• как будет работать резервное копирование;
• что произойдет при отказе узла или дискового пула;
• не станет ли новая система медленнее старой из-за хранилища.

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

Миграция волнами

Массовый перенос за одну ночь выглядит заманчиво, но почти всегда увеличивает риск. Гораздо безопаснее переносить системы волнами.

Первая волна — лаборатория и тестовые ВМ. Здесь проверяются инструменты, скорость переноса, драйверы, сеть и порядок действий. Вторая волна — низкорисковые сервисы: вспомогательные серверы, архивы, внутренние инструменты. Третья — типовые продуктивные системы, которые важны, но имеют понятное окно обслуживания. Четвертая — критичные сервисы. Пятая — исключения: старые ОС, GPU, USB-ключи, нестандартные лицензии, сложные базы данных.

Для каждой волны должны быть указаны:

• дата и окно работ;
• список ВМ;
• владелец каждого сервиса;
• способ миграции;
• ответственный инженер;
• критерии успешности;
• план возврата;
• время, после которого принимается решение об откате;
• контакт для бизнес-подтверждения.

Нельзя начинать с самых сложных сервисов. Но и бесконечно тестироваться на бесполезных ВМ тоже нельзя: пилот должен отражать реальные типы нагрузок. Иначе проект будет выглядеть успешным до первого переноса действительно важной системы.

Финальное переключение и план возврата

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

Типовой порядок выглядит так:

1. остановить изменения на исходной ВМ или перевести сервис в режим обслуживания;
2. выполнить финальную синхронизацию данных;
3. выключить исходную ВМ или изолировать ее сеть;
4. запустить ВМ на новой платформе;
5. проверить загрузку ОС;
6. проверить диски, сеть, службы и приложение;
7. переключить DNS, NAT или балансировщик;
8. получить подтверждение от владельца сервиса;
9. включить мониторинг и резервное копирование на новой платформе;
10. оставить старую ВМ выключенной до конца периода наблюдения.

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

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

Чек-лист после миграции

Миграция не заканчивается в момент, когда ВМ включилась. После запуска нужно проверить не только ОС, но и сам сервис.

После каждого переноса нужно убедиться, что:

• ВМ загрузилась без критичных ошибок;
• все диски видны;
• файловая система в порядке;
• IP-адрес, шлюз, DNS и маршруты корректны;
• сервис отвечает внутри сети;
• сервис доступен пользователям;
• базы данных подключаются;
• права доступа не нарушены;
• журналы ОС и приложения не показывают критичных ошибок;
• время синхронизируется правильно;
• мониторинг видит ВМ;
• оповещения работают;
• резервное копирование запущено;
• агенты безопасности активны;
• производительность не хуже согласованного минимума;
• старая ВМ выключена или изолирована;
• документация обновлена.

Через 24–72 часа стоит провести повторную проверку. Именно в этот период часто всплывают задержки дисков, ошибки плановых заданий, проблемы с лицензиями, переполнение хранилища, неработающие ночные бэкапы и жалобы пользователей, которые не были заметны сразу после запуска.

Особые случаи, которые нельзя переносить по общей схеме

Старые операционные системы требуют отдельного внимания. Они могут не поддерживать новые виртуальные контроллеры, современные драйверы или режим загрузки. Иногда безопаснее оставить такой сервис в изолированном контуре на время, а затем заменить его, чем пытаться срочно перенести старую ОС на новую платформу.

Базы данных нельзя оценивать только как «еще одну ВМ». Для них важна целостность данных, задержка диска, порядок остановки, штатный дамп или репликация. Горячий снимок ВМ не всегда гарантирует корректное состояние базы. Для критичных БД лучше использовать встроенные механизмы самой СУБД и отдельно тестировать восстановление.

Файловые серверы тоже сложнее, чем кажутся. Нужно учитывать права доступа, открытые файлы, длинные пути, дедупликацию, индексацию, антивирусную нагрузку и интеграцию с каталогом пользователей. После переноса файловый сервер может работать, но пользователи начнут получать ошибки доступа или заметят падение скорости.

Контроллеры домена нужно переносить особенно аккуратно. Лучше иметь несколько контроллеров и проверять репликацию, чем полагаться на один перенесенный сервер. Откат контроллера домена из старого снимка без понимания последствий может создать больше проблем, чем сама миграция.

ВМ с лицензиями, USB-ключами, GPU, прямым доступом к устройствам или нестандартными аппаратными привязками нельзя считать обычными. По ним нужно заранее связаться с поставщиками ПО, проверить возможность повторной активации и убедиться, что целевая платформа поддерживает нужный сценарий.

Когда миграцию можно считать завершенной

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

Признаки завершенной миграции:

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

Если VMware продолжает жить «на всякий случай» без срока отключения, проект фактически не закончен. Такая ситуация создает двойные расходы, путаницу в документации и риск, что часть забытых сервисов останется на старой платформе до следующей аварии.

Вывод

Миграция с VMware на Proxmox, Hyper-V, KVM или Nutanix может пройти без остановки бизнеса, но только при поэтапном подходе. Сначала нужно понять, какие сервисы есть в инфраструктуре и насколько они критичны. Затем выбрать платформу под реальные требования, провести пилот, подготовить сети и хранилища, определить способ переноса для каждой группы ВМ и заранее описать план возврата.

Самая рискованная стратегия — переносить виртуальные машины «как есть» и считать успешной миграцией сам факт запуска ОС. Рабочий результат появляется только тогда, когда приложения доступны пользователям, данные целостны, производительность проверена, резервные копии выполняются, мониторинг видит новую среду, а старая платформа больше не нужна для продуктивной работы.