Перенос ВМ из VMware в DVP

Это руководство описывает перенос существующей виртуальной машины из VMware на Deckhouse Virtualization Platform (DVP).

Для переноса могут использоваться:

• дистрибутив виртуальной машины (файл OVA, tar-архив с дисками в формате vmdk, метаданными ВМ в формате ovf и контрольными суммами в формате mf);
• отдельные файлы дисков VMDK.

Способы переноса

Прямой импорт VMDK

DVP поддерживает импорт дисков в формате vmdk. Можно загрузить файл VMDK из OVA или экспорта vSphere в VirtualImage или ClusterVirtualImage, создать из образа диск и затем виртуальную машину. Подробная инструкция приведена в разделе «Образы».

Рекомендуемый путь

Для типичных ВМ из VMware используйте утилиту virt-v2v: она конвертирует VMDK в qcow2 и адаптирует гостевую ОС к KVM (virtio-драйверы, загрузчик, замена VMware-устройств). Подготовленный диск загружается напрямую в ресурс VirtualDisk с type: Upload. Том создаётся в выбранном StorageClass, минуя DVCR.

Ниже приведена пошаговая инструкция по этому сценарию.

Этапы переноса

Перенос ВМ из VMware в DVP включает в себя следующие этапы:

1. Установка необходимых инструментов.
2. Конвертация диска.
3. Загрузка диска в кластер в виде ресурса VirtualDisk.
4. Создание виртуальной машины (ресурс VirtualMachine), которая загружается с этого диска.

Что необходимо для переноса

Перед началом переноса убедитесь, что у вас есть:

• доступ к кластеру DVP с установленной утилитой Deckhouse CLI (d8) и правами на создание ресурсов виртуализации в нужном неймспейсе;
• Linux-хост с virt-v2v и libguestfs и достаточным местом на диске под распаковку OVA (или отдельных VMDK) и результат конвертации;
• файлы исходной ВМ (OVA или VMDK).

Подробнее о загрузке дисков в кластер описано в разделе «Диски».

Установка инструментов

На этом шаге вы подготавливаете рабочую станцию для конвертации. Это не обязательно должен быть узел кластера DVP: достаточно любого Linux-хоста с доступом в интернет или локальным репозиторием пакетов.

Перечень необходимых пакетов зависит от гостевой ОС в переносимой ВМ:

• для Linux достаточно virt-v2v и libguestfs;
• для Windows дополнительно понадобится ISO virtio-win, чтобы после миграции гостевая ОС корректно работала с виртуальными устройствами в KVM.

Установите инструменты:

sudo apt update
sudo apt install -y virt-v2v libguestfs-tools

sudo dnf install -y virt-v2v libguestfs-tools-c virtio-win

export VIRTIO_WIN=/path/to/virtio-win.iso

Затем перейдите к конвертации диска.

Конвертация диска

На этом шаге вы конвертируете данные VMware в один или несколько файлов формата qcow2, которые DVP сможет использовать как том виртуальной машины. Если у вас уже есть готовый VMDK, можно сразу перейти к подразделу «Конвертация VMDK в qcow2 через virt-v2v». Если используется дистрибутив виртуальной машины OVA, сначала распакуйте его.

Распаковка OVA

Файл OVA представляет собой tar-архив с манифестом, описанием ВМ в формате OVF и одним или несколькими VMDK. Распаковка нужна, чтобы получить путь к файлу диска для утилиты virt-v2v. Сохраните файл OVF: позже из него возьмёте CPU, память и тип загрузчика для ресурса VirtualMachine.

Распакуйте архив целиком, если хотите сверить контрольные суммы или посмотреть OVF:

tar -xvf machine.ova

Типичное содержимое:

machine.ova
├── machine.mf          # контрольные суммы (SHA256)
├── machine.ovf         # метаданные ВМ (CPU, RAM, диски, сети)
└── machine-disk1.vmdk  # образ диска

Если архив большой, достаточно извлечь только нужный VMDK по имени из OVF:

tar -xvf machine.ova machine-disk1.vmdk

Конвертация VMDK в qcow2 через virt-v2v

Утилита virt-v2v в режиме -i disk обрабатывает локальный VMDK и сохраняет результат в указанную директорию. Для конвертации выполните команду:

virt-v2v -i disk ./machine-disk1.vmdk \
    -o local -os ./out -of qcow2

VIRTIO_WIN=/path/to/virtio-win.iso virt-v2v -i disk ./machine-disk1.vmdk \
    -o local -os ./out -of qcow2

После конвертации в директории ./out появится файл вида ./out/machine.qcow2 (точное имя может совпадать с именем исходной ВМ из метаданных). Этот файл далее загружается в кластер.

Загрузка диска в кластер

Этот подраздел описывает, как передать подготовленный образ qcow2 в DVP через API Kubernetes. На этом этапе файл становится постоянным томом в кластере: создайте ресурс VirtualDisk с type: Upload и передайте qcow2 по HTTP. Диск попадёт в выбранный StorageClass, минуя DVCR.

Загрузка образа диска в кластер включает следующие шаги:

1. Выбор StorageClass.
2. Создание VirtualDisk для загрузки.
3. Получение URL для загрузки.
4. Загрузка образа.
5. Проверка статуса загруженного образа.

Выбор StorageClass

StorageClass в Kubernetes определяет, где и как будет создан том. По смыслу это ближе всего к datastore в VMware. От класса зависят производительность, тип репликации и политика расширения томов.

Посмотрите список доступных классов в вашем кластере:

d8 k get storageclass

Пример вывода:

NAME                 PROVISIONER                             VOLUMEBINDINGMODE   AGE
rv-thin-r1 (default) replicated.csi.storage.deckhouse.io     Immediate           48d
rv-thin-r2           replicated.csi.storage.deckhouse.io     Immediate           48d

Запомните имя класса, который подходит под ваши требования к хранилищу для дисков ВМ.

Создание VirtualDisk для загрузки

Создайте ресурс диска, указав StorageClass и размер тома. Значение spec.persistentVolumeClaim.size должно быть не меньше фактического размера загружаемого qcow2. При сомнениях заложите запас: если размера не хватило, пересоздайте ресурс с большим PVC.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualDisk
metadata:
  name: uploaded-disk
spec:
  persistentVolumeClaim:
    storageClassName: rv-thin-r1
    size: 10Gi
  dataSource:
    type: Upload
EOF

После создания ресурс перейдёт в фазу WaitForUserUpload: том выделен, и можно начинать передачу файла.

Получение URL для загрузки

Платформа формирует два URL: внутренний (imageUploadURLs.inCluster) и внешний (imageUploadURLs.external). Используйте тот адрес, который доступен из вашей сети (изнутри кластера или с рабочей станции администратора).

Внутренний URL (используйте, если загрузка выполняется с узла кластера или из пода):

d8 k get vd uploaded-disk -o jsonpath="{.status.imageUploadURLs.inCluster}"

Внешний URL (используйте с рабочей станции администратора при настроенном доступе к DVP):

d8 k get vd uploaded-disk -o jsonpath="{.status.imageUploadURLs.external}"

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

d8 k get vd uploaded-disk -o jsonpath="{.status.imageUploadURLs}" | jq

Загрузка образа

Передайте файл qcow2 методом PUT на полученный на предыдущем шаге адрес. Ниже пример для внешнего URL. Подставьте свой адрес из статуса VirtualDisk и путь к файлу после конвертации.

curl https://virtualization.example.com/upload/<secret-url> \
    --progress-bar -T ./out/machine.qcow2 | cat

Дождитесь завершения загрузки без ошибок HTTP. После этого контроллер обработает образ и переведёт диск в фазу Ready.

Проверка статуса

Убедитесь, что ресурс диска вышел в рабочее состояние и размер тома соответствует ожидаемому:

d8 k get vd uploaded-disk

Пример вывода:

NAMESPACE   NAME             PHASE   CAPACITY   AGE
default     uploaded-disk    Ready   10Gi       1m

Если фаза долго не меняется с WaitForUserUpload или ресурс перешёл в Failed, проверьте сообщения в d8 k describe vd uploaded-disk и события в соответствующем неймспейсе.

Когда диск в статусе Ready, можно создавать виртуальную машину.

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

Последний шаг: опишите виртуальную машину, которая загрузится с перенесённого диска. Укажите, сколько CPU и памяти выделить, к какой сети подключить и какой диск считать загрузочным. Конфигурация VMware (OVF/VMX) напрямую не импортируется: перенесите параметры вручную, ориентируясь на OVF и таблицу соответствий ниже.

Соответствие понятий VMware и DVP

Для администраторов, знакомых с vSphere, ниже приведено соответствие привычных объектов VMware ресурсам Kubernetes и виртуализации DVP.

Подробнее о подключении ВМ к сетям см. «Сети виртуальных машин».

Пример VirtualMachine

Ресурс VirtualMachine ссылается на уже загруженный диск через blockDeviceRefs. Порядок элементов в blockDeviceRefs задаёт порядок загрузки: первым должен идти диск с загрузчиком ОС.

Минимальный пример для Linux после миграции диска:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachine
metadata:
  name: my-vm
spec:
  virtualMachineClassName: generic
  osType: Generic
  cpu:
    cores: 2
  memory:
    size: 4Gi
  networks:
    - type: Main
  blockDeviceRefs:
    - kind: VirtualDisk
      name: uploaded-disk
EOF

Для Windows укажите osType: Windows.

Если исходная ВМ в VMware загружалась через UEFI, добавьте bootloader: EFI (см. таблицу параметров ниже).

Если в кластере настроены дополнительные сети и модуль SDN, к основной сети можно добавить интерфейсы:

  networks:
    - type: Main
    - type: Network
      name: user-net

Дополнительные возможности (cloud-init, несколько дисков, классы виртуальных машин для production-окружения) описаны в разделе «Виртуальные машины».

Основные параметры спецификации

Ниже перечислены поля, которые чаще всего нужно сверить после переноса с VMware. Значения CPU, памяти и типа загрузчика обычно можно взять из распакованного OVF.

Проверка статуса ВМ

После применения манифеста дождитесь, пока ВМ запустится и получит адрес (если настроена основная сеть с выдачей IP из virtualMachineCIDRs):

d8 k get vm my-vm

Пример вывода:

NAME    PHASE     NODE           IPADDRESS     AGE
my-vm   Running   virtlab-pt-2   10.66.10.12   2m

При фазе Pending или ошибках запуска используйте d8 k describe vm my-vm, последовательную консоль d8 v console my-vm (см. раздел «Подключение к ВМ» ниже) и журналы компонентов виртуализации в кластере.

Подключение к ВМ

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

Имя пользователя для SSH задаётся в гостевой системе; в примерах из документации DVP после cloud-init часто создаётся пользователь cloud.