Миграция · VMware
Миграция виртуальных машин VMware на Apache CloudStack
Apache CloudStack может импортировать виртуальные машины из VMware vCenter и, начиная с версии 4.19, конвертировать их в KVM. Для безопасного выполнения все равно требуются инвентаризация, целевая зона, тестовый запуск и план переключения для каждой машины. В рамках 30 рабочих дней NexCMP Source инженер-эксперт выполнит эту работу вместе с вами без дополнительной платы.
Входит в NexCMP Source ($499 разово), не входит в NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor и Apache CloudStack являются товарными знаками соответствующих владельцев. NexCMP является независимым решением, не аффилирован с ними и не одобрен ими.
Проблема: миграция с VMware без потери контроля
Переход на Apache CloudStack означает смену платформы для каждой виртуальной машины: дисков, сетевых адаптеров, драйверов и зачастую IP-адресов. При спешке именно здесь машины перестают загружаться, клиенты теряют доступ, а лицензии выходят из строя.
CloudStack предоставляет инструменты импорта, но не решает за вас, какие машины переносить первыми, как сопоставить сети, что делать с виртуальными машинами на Windows и сколько времени займет простой каждой системы. Принятие этих решений и сопутствующее тестирование и составляют суть миграции.
Если вы продаете виртуальные машины клиентам, у миграции есть вторая часть: машины должны быть привязаны к правильным клиентам, тарифам и ценам в вашей биллинговой системе. NexCMP берет на себя уровень биллинга и клиентского портала поверх CloudStack, и обе эти задачи закрывает один и тот же инженер.
Что поддерживает сам CloudStack
Существует два документированных сценария перехода с VMware. Выбор зависит от того, остаются ли хосты VMware в вашем облаке.
A. Конвертация в KVM с помощью virt-v2v
- Что описано в документации CloudStack
- Начиная с версии 4.19 администратор может выбрать ВМ VMware в существующем или внешнем дата-центре vCenter и импортировать её в кластер KVM через меню Tools, Import-Export Instances. Машина экспортируется, конвертируется через virt-v2v, а её диски импортируются в формате QCOW2. В свежей документации к методу на основе OVF добавлен потоковый вариант через VDDK; в версии 4.22 появилась прямая конвертация в пул хранения, а в 4.22.1 — подбор гостевой ОС на базе исходной системы.
- Ограничения из документации
- Пакет virt-v2v не входит в состав агента CloudStack и должен быть вручную установлен на каждом хосте KVM, иначе конвертация завершится сбоем. Успешный результат не гарантирован и зависит от гостевой ОС и файловых систем, поэтому документация рекомендует проводить предварительное тестирование. В версии 4.19 импортированная машина по умолчанию получает тип гостевой ОС CentOS 4.5 (32-bit), который затем нужно скорректировать.
Source: Apache CloudStack — импорт виртуальных машин VMware в KVM · дата обращения 2026-10-19
B. Импорт на месте (unmanaged instances)
- Что описано в документации CloudStack
- Для кластеров vSphere, хосты которых уже подключены к CloudStack, команда listUnmanagedInstances выводит список ВМ, а importUnmanagedInstance переводит их под управление CloudStack. Просмотр unmanaged VMware instances появился в версии 4.14, вывод из-под управления — в 4.15, а импорт через интерфейс — в 4.16.
- Ограничения из документации
- Целевая сеть уже должна быть создана в CloudStack, а хранилище — подключено как primary storage. Диски данных должны быть сопоставлены с disk offerings; использование контроллеров дисков или сетевых карт разного типа вызывает ошибку. Работающую ВМ можно импортировать только при точном совпадении VLAN сети и compute offering, иначе её предварительно придется выключить.
Source: Apache CloudStack — Об импорте и экспорте Instances · дата обращения 2026-10-19
Сценарий A используется, если целевой средой является KVM. Документация NexCMP определяет KVM как протестированный гипервизор, поэтому мы ориентируемся на сценарий A, если только ваша инфраструктура не предполагает сохранение хостов VMware под управлением CloudStack. Проверьте версию CloudStack: в документации описаны заметные различия в поведении между 4.19 и последним релизом.
Что переносится и на что обратить внимание
Диски
- Что происходит
- Конвертируются в QCOW2 и импортируются в пул primary storage на целевой стороне (сценарий A) либо сопоставляются с disk offerings в CloudStack (сценарий B).
- Внимание
- В сценарии B размер диска не увеличивается, даже если выбранный disk offering больше исходного. Временным хранилищем при конвертации по сценарию A по умолчанию выступает secondary storage; использовать для этого primary storage можно только в случае NFS.
Source: Apache CloudStack — импорт виртуальных машин VMware в KVM · дата обращения 2026-10-19
Сети
- Что происходит
- Сети должны быть созданы в CloudStack до начала импорта. Скрипт обнаружения собирает список сетей vCenter, к которым подключена хотя бы одна ВМ, чтобы вы могли заранее создать аналогичные сети.
- Внимание
- virt-v2v не меняет сетевые настройки внутри гостевой ОС и не изменяет MAC-адрес. Если целевая подсеть отличается, конфигурацию внутри системы потребуется обновить после конвертации.
Source: libguestfs — руководство virt-v2v · дата обращения 2026-10-19
Гостевые ОС Linux
- Что происходит
- Работающую ВМ на базе Linux можно импортировать по сценарию A: CloudStack клонирует её перед экспортом, поэтому конвертация выполняется в состоянии crash-consistent.
- Внимание
- В документации CloudStack рекомендуется предварительно выключать виртуальные машины Linux. virt-v2v не устанавливает новые ядра или драйверы и предупреждает об отсутствии поддержки virtio, поэтому гостевая ОС должна соответствовать минимальным требованиям к версии еще до конвертации.
Source: libguestfs — руководство virt-v2v · дата обращения 2026-10-19
Гостевые ОС Windows
- Что происходит
- Должны быть корректно выключены перед импортом по маршруту A. Драйверы virtio берутся из пакета virtio-win и устанавливаются при первой загрузке; после первой загрузки Windows может перезагружаться четыре и более раз.
- Внимание
- Быстрый запуск (Fast Startup) или гибернация препятствуют конвертации, а системный диск на Dynamic Disk не поддерживается. Для импорта Windows требуются драйверы virtio на хосте конвертации.
Source: libguestfs — руководство virt-v2v · дата обращения 2026-10-19
VMware Tools
- Что происходит
- virt-v2v пытается удалить VMware Tools.
- Внимание
- Согласно документации, удаление не всегда надежно работает в Windows, где Tools, возможно, придется удалять другим способом.
Source: libguestfs — руководство virt-v2v · дата обращения 2026-10-19
Тип гостевой ОС
- Что происходит
- Импортированная ВМ получает тип гостевой ОС по умолчанию.
- Внимание
- В версии 4.19 это CentOS 4.5 (32-bit), и его необходимо менять вручную; версия 4.22.1 может сопоставлять его с исходной гостевой ОС при наличии правил маппинга.
Source: Apache CloudStack — импорт виртуальных машин VMware в KVM · дата обращения 2026-10-19
Биллинг и клиенты
- Что происходит
- Тарифы, цены и учетные записи клиентов настраиваются в NexCMP, а каждая перенесенная машина привязывается к нужному клиенту.
- Внимание
- Согласовывается на неделе 1 для вашей версии CloudStack. Это задача внедрения NexCMP, а не функционал CloudStack.
План по неделям
Типовой график, адаптируемый под ваш проект. 30 рабочих дней непрерывной работы — это около шести календарных недель.
Неделя 1 — Инвентаризация и решения
Получив доступ только для чтения к vCenter, мы инвентаризируем каждую ВМ: гостевая ОС, диски, сетевые адаптеры, VLAN, снапшоты, статус питания и взаимные зависимости. Мы выбираем маршрут A или B, формируем волны миграции и отмечаем машины, требующие особого внимания: гостевые ОС Windows, ВМ с большими дисками и системы с фиксированными лицензиями.
Неделя 2 — Подготовка целевой среды
Проверяется или развертывается зона CloudStack: KVM-хосты, хранилища, сети, соответствующие структуре VMware. Мы устанавливаем virt-v2v на хосты KVM (и nbdkit на хосты Ubuntu), подготавливаем драйверы virtio для Windows и открываем сетевой доступ между хостами конвертации, vCenter и ESXi. Если вы продаете машины клиентам, на этой же неделе устанавливается NexCMP и подключается к CloudStack.
Неделя 3 — Пилот
Несколько некритичных машин — по одной для каждого типа гостевых ОС — проходят реальную процедуру миграции. Мы проверяем их запуск, работу сети и корректность драйверов, задаем тип гостевой ОС и замеряем время простоя каждой машины. По итогам определяются окна для основных волн.
Недели 4 и 5 — Волны миграции
Машины переносятся группами в согласованное с вами время. Каждая группа проверяется перед стартом следующей, а исходные машины VMware выключаются, но сохраняются для возможности отката. Если вы продаете машины клиентам, параллельно в NexCMP заводятся клиенты, тарифы и цены, а биллинг работает параллельно до переключения.
Неделя 6 — Финальное переключение и сдача
Переносятся последние машины, переключается дата биллинга (если вы продаете машины) и вносятся изменения в DNS. Мы документируем все выполненные шаги, проверяем параметры безопасности и резервные копии и остаемся на связи для поддержки до завершения 30 рабочих дней.
Предварительный план. Точный график составляется по итогам недели 1, а единственное жестко зафиксированное в предложении обязательство по срокам — 30 рабочих дней.
Риски и способы их минимизации
Ни одна миграция не обходится без рисков, и мы не обещаем нулевой downtime. Ниже описано, какие сложности могут возникнуть и что мы предпринимаем.
Время простоя на одну машину
Машины с Windows невозможно конвертировать во включенном состоянии, а работающая машина с Linux конвертируется в состоянии crash-consistent. В CloudStack не регламентируется длительность конвертации. Мы замеряем ее на пилотном этапе, после чего согласовываем окно остановки для каждой группы машин.
Неудачная конвертация
В документации CloudStack указано, что успешность не гарантируется и зависит от гостевой ОС. Мы тестируем каждый тип гостевой ОС на пилотном этапе до начала волн, а исходная машина остается нетронутой до проверки новой.
Драйверы и VMware Tools
Машины Windows получают драйверы virtio во время конвертации, машинам Linux требуется поддержка virtio заранее, а VMware Tools может потребовать ручного удаления. Все это проверяется для каждой гостевой ОС на пилотном этапе.
IP-адреса, MAC-адреса и DNS
Гостевые ОС сохраняют свои MAC-адреса и сетевые настройки, поэтому при переходе в другую подсеть потребуются изменения внутри ОС. Мы фиксируем все адреса на неделе 1, заранее снижаем TTL записей DNS перед переключением и заблаговременно информируем ваших клиентов.
Лицензии ПО в гостевых ОС
Windows и коммерческое ПО внутри виртуальных машин могут быть привязаны к лицензиям старой платформы. Мы включаем их в инвентаризацию, чтобы вы могли согласовать условия с каждым вендором до начала миграции.
Прерванная конвертация
В документации CloudStack указано, что перезапуск серверов управления во время миграции прерывает процесс, и импорт приходится запускать заново. Мы планируем волны миграции с учетом регламентных работ и исключаем перезапуски во время их выполнения.
Перевод биллинга и откат
Если вы продаете виртуальные машины клиентам, дата переключения биллинга согласовывается с вами, и сначала обе системы работают параллельно. Исходные копии в VMware сохраняются до тех пор, пока вы не подтвердите завершение миграции, что гарантирует возможность отката для каждой группы.
Кто за что отвечает
Доступ к vCenter только для чтения и список критически важных виртуальных машин
- Эксперт выполняет
- Проводит инвентаризацию каждой ВМ и планирует волны миграции
Доступ к среде CloudStack и KVM-хостам либо к оборудованию для их развертывания
- Эксперт выполняет
- Подготавливает зону, сети и хосты конвертации
Пакеты VDDK и virtio, необходимые для выбранного сценария, если их поставщики требуют самостоятельной загрузки
- Эксперт выполняет
- Устанавливает и тестирует их на хостах конвертации
Согласованные окна техобслуживания и уведомления для ваших клиентов
- Эксперт выполняет
- Проводит пилотную миграцию и основные волны, после чего проверяет каждую машину
Ваша тарифная политика, если вы продаете виртуальные машины
- Эксперт выполняет
- Настраивает тарифы, клиентов и биллинг в NexCMP и сопровождает период параллельной работы
Что входит в 30 рабочих дней
Миграция входит в обновление до NexCMP Source: единовременный платеж $499 включает полный исходный код (сервер на Rust, портал и панель администратора на Vue, агент узла на Go, CLI, скрипты сборки), право на неограниченную модификацию и сборку собственной версии, 12 месяцев обновлений исходного кода, все приложения и 30 рабочих дней непрерывной работы с ведущим инженером.
В течение этих 30 рабочих дней эксперт переведет вашу инфраструктуру с VMware на Apache CloudStack без дополнительной платы. Также это время можно частично или полностью использовать для миграции с WHMCS или другой системы, либо для полной настройки под ключ и сборки ваших приложений. Отсчет начинается с момента старта совместной работы с экспертом и отображается на странице вашей лицензии. Поддержка миграции действует в течение этих же 30 дней.
В NexCMP Free это не входит. NexCMP Free предоставляется бесплатно на один год со всеми модулями без техподдержки (только исправление ошибок в исходном коде) и продлевается за $99 в год.
VMware на CloudStack — часто задаваемые вопросы
Сколько это стоит?
Входит ли это в NexCMP Free?
Какие версии CloudStack и VMware поддерживаются?
Будет ли простой у виртуальных машин?
Можно ли сконвертировать любую ВМ?
Нужно ли сохранять инфраструктуру VMware после переноса?
Что необходимо предоставить?
Источники и примечания
Технические сведения взяты из официальной документации Apache CloudStack и руководства по virt-v2v. Документация меняется от релиза к релизу, поэтому проверяйте используемую вами версию. Формулировка для 4.19 взята из документации к версии 4.19, где страница миграции с VMware на KVM начинается со слов «As of CS 4.19». VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor и Apache CloudStack являются товарными знаками соответствующих владельцев. NexCMP является независимым решением и не связана с ними, не аффилирована и не одобрена ими.
Переходите с VMware при поддержке инженера
Перейдите на NexCMP Source за $499 и начните свои 30 рабочих дней или предварительно проконсультируйтесь по вашей инфраструктуре по адресу [email protected].
Последнее обновление: