Миграция из VirtualBox в Proxmox (KVM). Шпаргалка

Важно!

При загрузке русской версии винды, невозможно переключить язык ввода в окне входа в консоли web-интерфейса proxmox, поэтому нужно перед переездом в русской версии вин заводить админа с русским именем и паролем из пробелов и цифр или русских букв

Переключение работает, при подключени с помощью tigerVNC

ЧТо нужно сделать для переезда:

1. Загрузить переезжающую виртуальную машину с Linux Rescue CD

2. Оживить сеть в загруженном Linux Rescue CD

ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up 

dhcpcd eth0

3. Теперь можно копировать данные с диска переносимой машины непосредственно на хост proxmox:

dd if=/dev/sda | ssh root@proxmox dd of=/var/lib/vz/images/vmid/diskname.raw

4. Файл /var/lib/vz/images/vmid/diskname.raw — это файл диска виртуалки в формате raw. Теперь создаем виртуалку с диском минимального размера (1гб) и заменем её диск только что скопированным файлом.

Ниже приведен англоязычный оригинал и некоторые дополнения. Приведенный метод подходит и для WIndows и для Linux. Я так переносил, например, Kerio Control 7.

download SystemRescueCD ( http://www.sysresccd.org ), burn it and reboot the physical machine with it in the cd tray.

At its bash prompt, give eth0 an ip, or use dhcp:

To assign ip:

ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up (use ip on same subnet as proxmox server)

To use DHCP:

To start the image process on the physical machine:

since you want to clone to a smaller partition, we will operate at the filesystem level, copying all the files from the source filesystem to the destination one.

so, we have to make sure that the destination partition has enough room to get all the files, at least, with better some free space left there.

the cloning is not possible directly, i.e disk-to-disk, but we have to “save” the source partition, and then “restore” it on the destination one.

we have to be sure that the tools used know very well how to copy files on the filesystems involved, including symlinks, hardlinks, filesystem specific attributes, and so on.

main tool: fsarchiver

One free tool you can use for this is fsarchiver, which «is a system tool that allows you to save the contents of a file-system to a compressed archive file. The file-system can be restored on a partition which has a different size and it can be restored on a different file-system. Unlike tar/dar, FSArchiver also creates the file-system when it extracts the data to partitions. Everything is checksummed in the archive in order to protect the data. If the archive is corrupt, you just loose the current file, not the whole archive. Fsarchiver is released under the GPL-v2 license. It’s still under heavy development so it must not be used on critical data.», So, you’ve been warned. Latest fsarchiver should be in the latest SystemRescueCD, although you can obtain it on your favourite recent distribution.

Cloning NTFS, be sure to use either version 0.6.10 or a patched previous version, because there was a bug that caused errors with NTFS junctions (something like linux symlinks).

mergeide

As other said, install mergeide.reg on the physical Windows machine (see Microsoft KB article for details) to provide support for the natively supported IDE controllers in Windows. Without this, cloned XP booting failed for me.

running fsarchiver from ubuntu livecd

I used a Ubuntu 10.04 LiveCD, where I installed the package 0.6.8-1ubuntu0.1 from the universe repository: this repository is disabled by default, you have to enable it before, doing:

#sudo nano /etc/apt/sources.lst

then, after uncommenting universe lines, installing it:

#sudo apt-get update

#sudo apt-get install fsarchiver

once installed, confirm the version is right typing

# sudo aptitude show fsarchiver

it shoud be at least “0.6.10”, or “0.6.8-1ubuntu0.1” (pathced from 0.6.9 and 0.6.10), particularly if you are cloning NTFS filesystems.

then run

#sudo fsarchiver probe simple

=====DEVICE===== ==FILESYS== ======LABEL====== ====SIZE==== MAJ MIN

loop0 squashfs <unknown> 671.85 MB 7 0

vda1 ntfs System 15.00 GB 8 1

ramzswap0 swap <unknown> 248.47 MB 251 0

giving a suitable password when asked.

backup the partition

then,you have to perform the “backup”, BE CAREFUL the first path is the backup file to save, the second the source partition, do not invert

I used:

#sudo fsarchiver savefs -v -o /mnt/tmpfolder/physical.fsa /dev/sda1

then (if no errors reported) mounted the same LiveCD in a kvm vm with a 15GB virtual empty disk (virtio), so /dev/vda. After installing smbfs and fsarchiver in the same way, i’ve run Gparted (installed on the LiveCD) and created a empty ntfs partition there, /dev/vda1.

restore the partition

Then, I run

Note: i use here /dev/vda1 while the original was /dev/sda1, and id=0 because i restore the first partition in the physical.fsa (yes, it may store more than one) as /dev/vda1

#sudo fsarchiver restfs -v /mnt/tmpfolder/physical.fsa id=0,dest=/dev/vda1

check if there are no restore errors. It was quite quick and just worked. Well, no, the first times i tried a few and in the end it worked :-^

successful cases

• Last modified:
• by 127.0.0.1

В моем блоге уже была статья о том, как выполняется установка Proxmox. В этой публикации я кратко покажу, как выполняется миграция виртуальных машин из Hyper-V в Proxmox. Причем миграция разных поколейний виртуальных машин Hyper-V – как ВМ первого поколения, так и ВМ второго поколения.

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

В руководстве от Proxmox не так много пояснительной информации о процессе миграции с Hyper-V. Поэтому я постараюсь наглядно показать весь процесс.

Содержание

1. Создание копии vhd/vhdx диска
2. Копирование vhd/vhdx диска на сервер Proxmox
3. Создание виртуальных машин
4. Для ОС Linux
5. Для ОС Windows
6. Если что-то пошло не так
7. Экспорт из VMware
8. Через графическую оболочку
9. Через консоль
10. Импорт в Proxmox
11. Донастройка
12. Для Windows
13. Сетевой интерфейс
14. Комментарии
15. Introduction
16. Prerequisites
17. Export process
18. Alternative to export via ESXi server
19. Import process
20. Bios type
21. Change disk type to SATA
22. Boot order
23. Remainder tasks
24. Qemu quest agent
25. All done
26. Установка Proxmox VE
27. Требования к серверу
28. Запуск установки Proxmox VE
29. Подготовка к переезду
30. Два способа миграции виртуальных машин
31. Оценка свободного места на дисках сервера Proxmox VE
32. Ревизия доступных адресов IP
33. Копирование образа виртуальной машины
34. Поиск файлов с образами виртуальных машин
35. Определение и преобразование формата образа виртуальной машины
36. Настройка правил брандмауэра
37. Завершение работы виртуальной машины
38. Копирование файла образа VM на сервер Proxmox
39. Создание VM для импорта загруженного файла
40. Импорт файла образа виртуальной машины
41. Запуск импортированной виртуальной машины
42. Изменение настроек сетевого интерфейса
43. Замена адреса IP в приложениях

Для тестового сценария создал несколько виртуальных машин.

Виртуальная машина 1.

Виртуальная машина 2.

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

В качестве исходного гипервизора Hyper-V выступал Windows Server 2022.

В качестве целевого гипервизора выступает Proxmox 7.2-7.

Шаги по предварительной подготовке виртуальных машин одинаковы, как для платформы Linux, так и для платформы Windows:

1. Создание копии vhd/vhdx диска.
2. Копирование vhd/vhdx диска на сервер Proxmox.

Создание копии vhd/vhdx диска

На самом деле здесь есть несколько вариантов. В зависимости от того, насколько возможен перерыв в работе виртуальной машины Hyper-V.

Итак, для создания копии диска есть следующие варианты:

1. Первый вариант самый оптимальный – вы просто останавливаете виртуальную машину и загружаете диски на сервер Proxmox. Этот метод обеспечит вам гарантированную целостность данных на диске. К тому же, если после этого вы не будите запуска ВМ на сервере Hyper-V, то по завершении миграции получите на Proxmox самую актуальную версию ВМ. И вам не нужно будет думать о том, как перенести дельту изменений виртуальной машины.

2. Если виртуальная машина критическая и нельзя выполнять её остановку, то вы можете выполнить экспорт виртуальной машины. В результате вы получите копию всех файлов работающей виртуальной машины Hyper-V, в т.ч. и виртуальных дисков. Недостаток этого метода в том, что выполняется экспорт всех дисков. Если какие-то из дисков нужно исключить, то это не ваш метод. Однако, именно этим методом пользовался я. Из своей практике скажу – я ни разу не получал “битых” дисков при использовании этого метода.

3. Если виртуальную машину останавливать нельзя и нужно выполнить экспорт только части дисков. (например, нужен только системный диск), то вы можете использовать утилиту Disk2vhd. На своей практике я тоже её использовал довольно часто. Лично у меня проблем с консистенцией данных не было. Но это самый относительно ненадежный метод, т.к. на высоконагруженных системах есть шанс получить не совсем консистентные данные.

Повторюсь – я использовал метод №2.

Копирование vhd/vhdx диска на сервер Proxmox

Это тоже относительно понятный шаг. Все, что вам нужно сделать – это скопировать виртуальный диск (или диски) на сервер Proxmox в локальную директорию. Инструмент для копирования можете использовать любой. Если вы выполняете копирования из среды Windows, то можете использовать WinSCP.

Если вы работаете в среде Linux, то можете использовать старую добрую утилиту scp. Формат команды для scp следующий:

scp <source_vhdx> <proxmox_user>@<proxmox_ip>:<proxmox_folder_path>

scp tst-lin.vhdx root@10.10.10.20:/mnt/pve/HDD
scp tst-win.vhdx root@10.10.10.20:/mnt/pve/HDD

По итогу вы должны увидеть ваши vhd(x) диски в директории на сервере Proxmox:

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

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

Для ОС Linux

Итак, создает заготовку виртуальной машины для Linux:

1. Указываем сервер Proxmox (если у вас их несколько) и имя виртуальной машины:

2. Указываем тип операционной системы – Linux.

3. Далее необходимо указать ряд важных параметров:

Тип эмулируемого аппаратного обеспечения – я укажу i440fx.

Тип BIOS – выберу OVMF (UEFI) (т.к. исходная ВМ использовала UEFI BIOS).

Тип SCSI контроллера – VirtIO SCSI, т.к. его поддержка есть в Linux из коробки.

Также необходимо выбрать формат и хранилище для UEFI раздела.

4. На странице конфигурации виртуальных дисков я удалю вообще все диски:

5. Указываем количественные ресурсы процессора:

6. Указываем количество оперативной памяти:

7. И параметры сети:

Обратите внимание на тип сетевого адаптера – VirtIO. Аналогично контроллеру SCSI его поддержка есть в Linux из коробки.

8. На странице со сводными параметрами создаваемой виртуальной машины нажмите кнопку “Finish“.

9. Импортируем виртуальный жесткий диск:

qm importdisk 104 /mnt/pve/HDD/tst-lin.vhdx NVMe

Формат команды следующий:

qm importdisk <vmid> <source> <storage> 

10. После этого в настройках виртуальной машины у на должен появиться неиспользуемый виртуальный жесткий диск:

11. Перейдем в настройки виртуального жесткого диска (кнопка “Edit“) и добавим его в используемые диски виртуальной машиной (кнопка “Add“):

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

13. Вот теперь вы можете попробовать запустить виртуальную машину на сервере Proxmox:

По крайней мере в моем случае результат был положительный. Единственный нюанс с которым я столкнулся – это то, что сетевой интерфейс был переименован с eth0 на ens18. Соответственно, нужно было скорректировать файл с настройками сети и изменить имя адаптера на ens18:

nano /etc/netplan/00-installer-config.yaml

И изменить имя сетевого адаптера:

И применить изменения в конфигурации сети:

netplan apply

После этого виртуальная машина успешно получила IP адрес от сервера DHCP:

Для ОС Windows

В целом миграция виртуальных машин Windows выполняется аналогично миграции виртуальных машин Linux. Но есть ряд нюансов. Собственно, именно нюансам и будет посвящен этот раздел.

Я лишь очень верхнеуровнево опишу процесс миграции виртуальных машин Windows, но буду подробно останавливаться на тех шагах, где есть отличия от платформы Linux:

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

Очень важный момент – выбор типа SCSI контроллера. В Windows из коробки нет драйвера для virtio. Поэтому я укажу другой тип контроллера – LSI 53C895A.

Так же на этапе выбора модели сетевого адаптера укажите Intel E1000

Причины аналогичны – в Windows из коробки нет поддержки адаптеров типа VirtIO.

Читайте также:  Максимизируйте производительность с помощью 1с Сервера и PostgreSQL на Linux

2. Импортируем виртуальный жесткий диск:

qm importdisk 105 /mnt/pve/HDD/tst-win.vhdx NVMe

3. Подключаем импортированный виртуальный жесткий диск.

Не забудем в параметрах очередности загрузки выбрать подключенный диск:

4. Запускаем виртуальную машину.

5. Если запуск прошел успешно, то теперь необходимо установить драйвер VirtIO. ISO образ с драйвером для Windows можно загрузить вот по этой ссылке. Можете либо непосредственно выполнить загрузку в гостевой ОС, либо выполнить загрузку через в локальное хранилище Proxmox, а затем примонтировать ISO образ в гостевую ОС. Я буду использовать второй метод – через загрузку в локальное хранилище Proxmox и подключение ISO в гостевую ОС.

6. Примонтирую ISO образ.

7. Установим драйвер VirtIO.

8. Меняем тип контроллера SCSI на VirIO.

И снова запускаем виртуальную машину. Проверяем, что ВМ запустилась успешно.

9. Так же можем поменять тип сетевого адаптера на VirtIO. Но нужна будет перезагрузка ВМ.

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

Если что-то пошло не так

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

Подробности

Создано 20.04.2014 22:10

Обновлено 21.04.2014 01:13

Автор: Mr.Bublik

Просмотров: 29206

Встал вопрос о переносе со старого сервера win 2003 std. 32-bit. Попытки переноса, путем «накатывания образа» акрониса, потерпели неудачу. Так же и восстановления ntbackub, на новую систему. Не могу точно сказать, какая причина главнее, мои кривые руки или древний софтовый рейд. Главное итог — не получалось. На выручку, как это ни странно, пришел Мелкософт,

с утилитой Disk2vhd v2.01 ( идем на сайт MS ), которая позволяет конвертировать Windows системы в VHD файлы, не прерывая их работы. Особый респект и уважуха ее авторам — Mark Russinovich и Bryce Cogswell.
Итак порядок действий, что бы не забыть:

• замечательной утилитой Disk2vhd, делаем клон диска С: в имидж VHD.
• Имидж закладываем на сервер proxmox по ssh.
• Не забываем создать виртуальную машину для переноса. Диски делаем IDE
• Заходим по ssh на Proxmox
• Запускаем конвертацию в папку где лежит образ. Как пример, машина с ID 333 (myserver2003) и файлы ее лежат в /media/stor/myserver2003/images/333 .

  qemu-img convert -O qcow2 /<путь куда клали>/mysrv2003.vhd /media/stor/myserver2003/images/333/vm-304-disk-1.qcow2

После конвертации пробуем запустить. Если взлетела — отлично, работайте спокойно. Если вылезла ошибка 0x0000007b — это хорошо. Значит больной подлежит реанимации. Если вылезло «NTOSKRNL.EXE отсутствует или поврежден» — капец, статья вам не помогла, можно дальше не читать.
Реанимация:

• Качаем изумительный образ Hiren’s BootCD. Респект и уважуха авторам !
• Подключаем этот образ к виртуалке.
• Загружаемся с него (Load Mini XP)
• Далее тынц в иконку HBCD Menu
• Выбираем Programs → Registry → Fix hard disk controller (fix_hdc.cmd). Эта фиксилка, отвяжет привязки к установленным драйверам рейдов и прочего. У вас будет стоять по умолчанию ide.

• Выбираем T и указываем путь : c:\windows
• Нажимаем М для отвязки.

Перегружаемся и видим винду!!!! Она долго хрюкает перенастраивая свои дрова, но потом работает нормально.

You have no rights to post comments

Подробности

Создано 03.02.2014 14:22

Обновлено 17.10.2014 10:19

Автор: Mr.Bublik

Просмотров: 31567

Стоит задача — мигрировать виртуалку из VB в Proxmox, в его KVMную часть. Proxmox достаточно удобен в работе, но есть ряд подводных камней, зная которые работать станет легче. Итак по порядку:

Первым делом необходимо зайти на VB и посмотреть какой диск использовался для хранения. Если динамический, то надо сделать его копию в статический vdi (я использую этот формат). Это можно сделать либо в графической морде VB, либо в командной строке:

VBoxManage clonehd dynamic.vdi static.vdi —format VDI —variant Fixed

Пункт 2. Подцепить новый диск, назовем его static.vdi, вместо динамического и удалить в Windows все VB Addonsы.

Пункт 3. Отцепить образ и скопировать по ssh на машину с proxmox, к примеру в домашнюю папку . На этом работа со старым сервером завершена.

Пункт 4. Для успешной работы Windows необходимо иметь в наличии дрова для KVM. Поэтому цепляемся по ssh к серверу proxmox. Переходим в хранилище local и заливаем туда iso образ с virtio драйверами:

Содержимое: выбрать все (просто кликайте мышкой по выпавшему списку).

У нас должно появиться в дереве хранилище monstr_storage.

Пункт 6. Создать машину (в правом углу кнопка Создать VM) с параметрами:

OS: нужная нам винда (в моем случае 2008)

CD/DVD: Хранилище local, образ virtio-win-0.1-74.iso

Жесткий диск: IDE (именно IDE !!!!) , Хранилище monstr_storage, размер больше static.vdi.

CPU: определитесь сами по загрузке и свободным ресурсам :), тип qcow2.

Память: рекомендую использовать Automatically allocate memory within this range и указать там от 1024 (или что вам надо) до 4096 (предположительный максимум). Это сэкономит ресурсы системы.

Пункт 7. Перейти в терминале в хранилище :

cd /var/lib/vz/monstr_storage/images/<ID Nomer(к примеру 101) >/

и там выполнить

Покажется файл с образом для машины — vm-101-disk-1.qcow2 . 101 — это номер вашей машины, а 1 это номер диска. Его и надо подменить на наш файл. Для этого ВНИМАТЕЛЬНО ЗАПОМИНАЕМ (ЗАПИСЫВАЕМ, ВЫСЕКАЕМ НА СКАЛЕ и т. д.) имя файла. Далее удаляем его и на его место конвертим наш vdi файлик.

qemu-img convert -f vdi static.vdi -O qcow2 vm-101-disk-1.qcow2

Далее перекур, кофе-брейк или что вы любите. Это не быстро.

Пункт 8. После конвертации машина готова к запуску. Есть варианты сразу имплантировать драйвера VirtIO, путем запуска с образа Hiren’s boot cd. Коллега Никита Менькович, aka librarian очень хорошо это описал в своей статье «Перенос виртуальной машины из Virtualbox в KVM». Я обхожусь без этого.
Открываем консоль и запускаем. Во время первого запуска машинка возмутившись адаптируется к новым девайсам. Именно по этому для первого старта нужен IDE !!!

Пункт 9. Адаптируем машину к KVM. Завершаем работу винды. Создаем 2й диск размера 2гига типа VIRTIO. Для этого достаточно выбрать в дереве нашу машину — monstr, перейти на вкладку Оборудование и нажать Добавить.

Пунт 10. Запускаем машну. На вопросы где взять драйвера указываем на CD с папкой версии винды. У меня Win7 для 2008. Если диск виден в управлении носителями — все ОК. Добиваем дрова сетевухи и прочее. Помните, что ИП-адрес если у вас был статический — уплывет. Верните его на новой сетевухе. А старую найдите в списке устройств (скрытые устройства) и удалите.

Пункт 11. Гасим машину и проделываем виртуозную операцию по переходу с IDE на VIRTIO. Удаляем 2й диск. Для этого встав на маленький диск в Оборудовании нажимаем кнопку удалить. Диск просто так не удалится — он обретет статус «Неиспользуемый диск». Встаем на него и еще раз жмем Удалить. Все, диска нет.

— Теперь надо перевести основной диск в «Неиспользуемый диск». Встать на основной диск и нажать удалить. НЕ УДАЛЯЙТЕ ЕГО ЕЩЕ РАЗ !!!!!!

— Дважды кликаем по «Неиспользуемый диск» и выбираем тип VIRTIO номер 0. Он получил обратно статус «Жесткий диск».

— Переходим на закладку Опции. Щелкаем по «приоритет загрузки». Ставим первым virtio0

Пункт 12. Запускаем машину.

You have no rights to post comments

cd "C:\Program Files\VMware\VMware OVF Tool"Enter login information for source vi://192.168.109.45/
Username: root
Password: ************
Opening VI source: vi://root@192.168.109.45:443/bsd10
Opening OVF target: .
Writing OVF package: .\bsd10\bsd10.ovf

qm importovf 102 bsd10.ovf localFormatting '/var/lib/vz/images/102/vm-102-disk-0.raw', fmt=raw size=644245
transferred: 0 bytes remaining: 6442450 bytes total: 6442450 bytes progression: 0.00 %
transferred: 64424509 bytes remaining: 637802 bytes total: 644245 bytes progression: 1.00 %
transferred: 128849018 bytes remaining: 631360 bytes total: 644245 bytes progression: 2.00 %
transferred: 193273528 bytes remaining: 624917 bytes total: 644245 bytes progression: 3.00 %
...
transferred: 644245 bytes remaining: 0 bytes total: 644245 bytes progression: 100.00 %

sed -i 's/scsi0:/sata0:/' /etc/pve/qemu-server/102.conf

Introduction

Migrating virtual machines between platforms can be a pain in the ass to put it mildly.

I have recently decided to migrate from ESXi to Proxmox VE, simply because it allows me downscale my lab from several “BIG” machines into a single machine.

I am well aware that this makes my lab more fragile and prone to failures, but that is a price I am willing to take — at least for now.

So this leaves me with the task of migrating all my virtual machines from ESXi to Proxmox VE.

Luckily after a bit of googling, I decided on the simplest approach from my point of view.

Prerequisites

Software is required to allow the migration to happen, but not a lot.

Ovftool is what makes the magic work. It can convert a virtual machine into a ovf package.

Head to vmware’s website and download version 4.4.3 of ovftool.

Copy the downloaded zip VMware-ovftool-4.4.3-18663434-lin.x86_64.zip to your proxmox VE server.

Unzip the archive via the command unzip. If you get a command not found error message simply install unzip via apt-get install unzip

Then you unzip the archive via the command unzip VMware-ovftool-4.4.3-18663434-lin.x86_64.zip

This should create a folder in the current directory called ovftool.

Export process

Change directory to the ovftool folder and run the command:

The program will ask you for the root password, which you just enter and if everything checks out, i.e. you entered correct information, then the export starts.

An example from my environment is:

The the export is done, then a folder is created in the destination directory with the name of the virtual machine, i.e. in my case it would be named /tank/vms/devops.root.dom.

Inside that folder several files are located.

• The ovf file, which is the descriptor for the virtual machine, which describes the hardware of the vm and also extra anotations from ESXi.
• The vmdk files which is the virtual disks from your virtual machine
• A .mf file, which contains hashes of the files so you can be sure nothing has tampered with the files.
• A nvram file, which is where ESXi stores BIOS information I assume.

The export is done and there are several ways to import the VM into proxmox.

Alternative to export via ESXi server

If you have direct access to the same datastore where ESXi stores the virtual machines, i.e. NFS or similar, then you can also just do a direct export from the vmx file to a ovf.

This has almost the same syntax:

Doing it directly from the storage will have speed advantages since you cut out the ESXi server as the middle man, but it might not always be possible.

Import process

The easiest way to get the virtual machine into proxmox is simply to create a new virtual machine inside proxmox and then attach the vmdk files directly.
This takes the least effort but will also give disadvantages, where the most important disadvantage in my opinion is that proxmox cannot resize disks that is backed by a vmdk — and also snapshots cannot be made.
So taking the least effort when importing into proxmox will bite you in the ass down the road.

Luckily its fairly easy to import the virtual machine.

An example from my lab:

qm importovf 300 /tank/vms/devops.root.dom/devops.root.dom.ovf vms — this command will convert the disks into whatever format the storage destination uses and import it as a VM with the given ID. In my case 300.

When the process is done you should have a vm called the same as the OVF file and with ID you provided.

In theory this should be enough, but I have had issues with the VM’s I have imported like that, so they needed a little tweaking.

Bios type

You have to ensure that the BIOS type in proxmox matches the bios type in ESXi, i.e. BIOS or UEFI — otherwise the machine will not boot, since all boot loaders are different.

The import seems to always default to BIOS.

Simply head to the options page and change it to match:

If you changed it to UEFI type, then you also have to add an EFI disk where proxmox can store information bout keys it uses for secure boot.Plus probably other information about the virtual machine. This is done in the hardware section.

Change disk type to SATA

This is a little counter intuitive how its done.

First you have to detach the hard drive — then you can edit it and select that it should become attached to the SATA bus:

Boot order

This confused me a lot — my VM’s refused to boot, but it was simply because when you detach and attach disks, they are not automatically added to the boot order again, so your machine will just stay at the boot prompt looking silly.

So you have to go the options and change the boot order so the SATA disk is first:

Remainder tasks

Hopefully this will allow it to boot — if not you might have to tweak a little in options or hardware.

Then you have to add a network device, unless you are happy with using the VMXnet3 device for the network controller — which I do not suggest you should be, since that will not allow proxmox to integrate properly.
So add or edit the network controller to use the Virt IO driver:

Qemu quest agent

When you have the hardware working as expected, then you should install the qemu-quest-agent, which is similar to the VMWare tools that you installed on the ESXi virtual machines.

Depending on what linux distribution you are running the commands are different, but the package should be named qemu-quest-agent.

On windows you can download a driver disk — simply update your drivers by going to device manager and pointing it to the iso you have have mounted in the virtual machine.

On the same CD-ROM the quest agent is also located in the folder quest-agent. Simply run the installer that maches your OS, i.e. 32 or 64 bit.

All done

This should be it. Hopefully everything works — if not feel free to leave a comment with what extra steps you had to take.

В данной статье мы расскажем, как своими силами перенести виртуальные машины с VMmanager 5 на Proxmox VE.

Установка Proxmox VE

Прежде всего, вам нужно будет установить Proxmox VE на сервер, размещенный в дата-центре. Это может быть арендованный или ваш собственный сервер.

Требования к серверу

Здесь подойдет такой же сервер, который вы использовали для VMmanager. Необходимо, чтобы на сервере была включена поддержка флага виртуализации в процессоре Intel VT или AMD-V.

Не помешает подключить к серверу два дисковых массива RAID-1 (зеркало). Первый из этих массивов имеет смысл собрать из быстродействующих дисков SSD или NVMe. На нем будет установлена система Proxmox и размещены файлы образов виртуальных машин. Второй массив можно собрать из дисков HDD для размещения резервных копий виртуальных машин.

Также будет полезен аппаратный контроллер дисков, оборудованный аккумулятором или суперконденсатором для защиты содержимого кэш-памяти контроллера при внезапном отключении электропитания сервера.

Что касается оперативной памяти и ядер процессора, то чем больше будет этих ресурсов, тем больше виртуальных машин вы сможете разместить на сервере. Если вы ранее использовали VMmanager, то уже знаете свои потребности в ресурсах сервера.

Запуск установки Proxmox VE

Далее нужно получить доступ к IP-KVM, допускающему удаленное монтирование на сервер ISO-образов дисков для загрузки. Некоторые модели серверов содержат встроенные порты управления с интерфейсом, допускающие монтирование ISO-образов, такие, например, как Intel RMM.

В том случае, когда средства удаленной загрузки недоступны, попросите сотрудников поддержки дата-центра записать ISO-образ на DVD-R диск или флеш-карту, вставить в сервер и выполнить загрузку. Ход загрузки контролируйте через IP-KVM, который есть в любом дата-центре.

Сама по себе установка очень простая. После загрузки на консоли появится приглашение (рис. 1).

Здесь с помощью клавиш перемещения курсора нужно выбрать строку Install Proxmox VE, а затем нажать клавишу Enter. Строка Advanced Options позволит вам запустить проверку оперативной памяти сервера, а также выполнить установку в отладочном режиме.

Через некоторое время после запуска установки вы увидите текст лицензионного соглашения. Для продолжения установки щелкните мышью клавишу I agree.

На следующем этапе выберите диск. Щелкнув кнопку Options, выберите тип файловой системы и размер дискового пространства, выделенного для Proxmox (рис. 2).

В том случае, когда ваш сервер оборудован контроллером диска, способным создать дисковый массив RAID, выберите файловую систему ext4 (используется по умолчанию). При этом будет использован менеджер логических томов Logical Volume Manager (LVM).

В том случае, если нужно создать программный дисковый массив RAID, можно остановиться на файловой системе ZFS или BTRFS.

Далее щелкните кнопку Next, выберите из списков страну, временную зону и раскладку клавиатуры (рис. 3).

На следующем экране вам будет предложено ввести пароль и адрес электронной почты администратора (рис. 4).

После ввода пароля и адреса электронной почты укажите сетевые настройки для вашего сервера Proxmox VE (рис. 5).

Используйте здесь данные, полученные от службы поддержки дата-центра, в котором размещен сервер. 

И, наконец, непосредственно перед запуском установки вы сможете проверить все введенные параметры и при необходимости вернуться назад для их редактирования (рис. 6).

Если параметры правильные, щелкните мышью кнопку Install. После установки сервер будет перезагружен автоматически. За ходом процесса установки можно наблюдать на консоли (рис. 7).

После завершения установки появится приглашение для входа в консоль с адресом панели управления Proxmox VE (рис. 8).

После входа вы увидите сообщение об отсутствии подписки. Вы можете его проигнорировать, щелкнув кнопку OK.

Чтобы подключить некоммерческий репозиторий для обновления бесплатной системы Proxmox VE, удалите файл коммерческого репозитория из источников apt:

# rm -f /etc/apt/sources.list.d/pve-enterprise.list

Далее создайте файл pve-no-subscription.list:

# touch /etc/apt/sources.list.d/pve-no-subscription.list

Добавьте в него адрес некоммерческого источника:

# deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Этот способ мы нашли в данной статье.

На странице https://www.proxmox.com/en/downloads/category/documentation-pve находится документация по установке, настройке и использованию Proxmox. Помимо официальной документации вы можете воспользоваться статьями с описанием установки и начальной настройки Proxmox VE:

Кроме того, можно попросить сотрудников дата-центра установить на арендованный сервер систему Proxmox VE и предоставить вам доступ к панели управления.

Подготовка к переезду

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

Теперь пришло время подумать над планом переезда и выбрать способ миграции для каждой виртуальной машины, а также оценить необходимые ресурсы на серверах с Proxmox VE.

Два способа миграции виртуальных машин

Первый способ миграции виртуальной машины (VM) заключается в том, что вы создаете на сервере Proxmox VE новую VM, устанавливаете на нее ПО, аналогичное установленному на исходной VM, а затем переносите файлы и базы данных проектов со старой VM на новую.

Преимущество такого способа заключается в том, что у вас есть возможность обновления ПО в процессе миграции без остановки работы проекта. После переноса файлов и баз данных вы все проверяете, а затем настраиваете переадресацию (например, с помощью nginx) и далее вносите изменения в DNS.

С другой стороны, обновление ПО на VM может привести к необходимости внесения изменений в исходные коды проектов. Иногда это может быть довольно сложно, особенно если проекты старые и давно не обновлялись.

Второй способ предполагает, что вы копируете двоичный файл образа VM с сервера VMmanager на сервер Proxmox VE, а затем импортируете его в новую VM, созданную специально для такого импорта. Этот способ позволяет перенести всю среду выполнения проектов и потребует лишь изменения сетевых настроек как в ОС, так и, возможно, в самом проекте.

Оценка свободного места на дисках сервера Proxmox VE

Как правило, размеры дисков виртуальных машин составляют десятки Гбайт, поэтому, прежде чем приступать к переносу, необходимо оценить свободное пространство на дисках ваших серверов Proxmox VE.

При установке Proxmox VE требуется определить формат хранилища для файлов образов VM. На рис. 10 показана ситуация, когда для размещения файлов образов VM использована система управления дисковым пространством LVM-Thing.

Здесь диски сервера объединены в зеркало RAID-1 с помощью аппаратного контроллера, поэтому Proxmox VE видит этот массив как один диск.

Если в дереве, показанном слева на рис. 10, выделить строку local-lvm, то справа на вкладке Summary появится график использования дисковой памяти (рис. 11).

На рис. 11 видно, что используется 266,33 Гбайт памяти из доступных на сервере 429,14 Гбайт.

Другой способ узнать распределение памяти в хранилище заключается в использовании команды lvs из командной строки:

# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert data pve twi-aotz-- 429.14g 62.06 3.29 root pve -wi-ao---- 96.00g swap pve -wi-ao---- 8.00g vm-100-disk-0 pve Vwi-aotz-- 120.00g data 18.06 vm-105-disk-0 pve Vwi-aotz-- 10.00g data 53.83 vm-106-disk-0 pve Vwi-aotz-- 10.00g data 52.21 vm-107-disk-0 pve Vwi-a-tz-- 32.00g data 20.60 vm-107-disk-1 pve Vwi-aotz-- 32.00g data 39.41 vm-108-disk-0 pve Vwi-aotz-- 50.00g data 76.65 vm-111-disk-0 pve Vwi-aotz-- 50.00g data 80.61 vm-200-disk-0 pve Vwi-aotz-- 80.00g data 99.89 vm-401-disk-0 pve Vwi-aotz-- <48.83g data 95.69 vm-501-disk-0 pve Vwi-aotz-- 39.06g data 24.47

На консоль выводится доступный объем памяти data в хранилище LVM-Thin, а также распределение этой памяти по VM. Для каждой VM также выводится процент использования дисковой памяти.

Панель управления Proxmox VE позволить вам создавать виртуальные машины в хранилище LVM-Thin даже в том случае, когда общий объем созданных для них дисков превышает размер хранилища. И все это будет работать, но только до тех пор, пока диски всех виртуальных машин не используются на сто процентов.

В примере, приведенном выше, для всех виртуальных машин было выделено 471,92 Гбайт дисковой памяти, однако размер хранилища составляет только 429,14 Гбайт. Избыток составляет 42,78 Гбайт. В данном случае требуется удалить какую-то из VM или уменьшить занимаемое ей дисковое пространство.

Объемы дисковой памяти, выделенной для VM, можно увидеть на вкладке Content (рис. 12).

Здесь, однако, не показан процент использования этой памяти.

На рис. 13 мы показали использование хранилища ZFS, созданного на обычном настольном компьютере с двумя дисками объемом 1 Тбайт.

График использования дисковой памяти, а также ее распределение для виртуальных машин можно посмотреть в панели управления Proxmox VE аналогично тому, как мы это делали для хранилища LVM-Thin.

Что касается командной строки сервера Proxmox VE с хранилищем ZFS, то вы можете использовать несколько команд для определения состояния хранилища и его распределения виртуальным машинам.

Команда zpool status покажет на консоли состояние массива:

# zpool status
pool: rpool
state: ONLINE
scan: scrub repaired 0B in 0 days 01:14:21 with 0 errors on Sun Feb 13 01:38:22 2022
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST1000DM003-9YN162_S1D1T1BB-part3 ONLINE 0 0 0
ata-ST1000DM003-9YN162_Z1D047K4-part3 ONLINE 0 0 0
errors: No known data errors

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

Команда zpool list покажет общий объем пространства SIZE, а также размеры занятого ALLOC и свободного FREE пространства:

# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 928G 594G 334G - - 17% 64% 1.00x ONLINE -

С помощью команды zfs list можно узнать размеры выделенного пространства для каждой виртуальной машины:

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 594G 305G 44.9G /rpool
rpool/ROOT 49.3G 305G 96K /rpool/ROOT
rpool/ROOT/pve-1 49.3G 305G 49.3G /
rpool/data 500G 305G 96K /rpool/data
rpool/data/vm-100-disk-0 12.7G 305G 12.7G -
rpool/data/vm-101-disk-0 2.55G 305G 2.55G -
…
rpool/data/vm-108-disk-0 5.06G 305G 5.06G -
rpool/data/vm-401-disk-0 44.0G 305G 44.0G -
rpool/data/vm-501-disk-0 6.92G 305G 6.92G -
rpool/data/vm-701-disk-0 20.1G 305G 20.1G -
…
rpool/data/vm-709-disk-0 8.64G 305G 8.64G -
rpool/data/vm-800-disk-0 1.67G 305G 1.67G -
…
rpool/data/vm-903-disk-0 72.9G 305G 72.9G -

Здесь вы можете узнать общий объем использованного и доступного пространства (594 Гбайт и 305 Гбайт, соответственно), а также объем пространства, распределенного для каждой VM.

Вся эта информация позволит вам контролировать использование дискового пространства на сервере Proxmox VE перед переносом в него виртуальной машины из VMmanager или другой платформы виртуализации. 

Ревизия доступных адресов IP

Приступая к переносу VM на сервер Proxmox VE, убедитесь, что дата-центр выделил вам достаточное количество адресов IP, а также необходимые сетевые настройки, такие как маска сети, адрес шлюза и адреса серверов DNS.

Вам потребуется как минимум один адрес IP на каждую виртуальную машину, плюс еще один адрес для сервера Proxmox VE.

Копирование образа виртуальной машины

Убедившись в наличии необходимых ресурсов, можно приступать к процедуре переноса VM с сервера VMmanager на сервер Proxmox VE.

Поиск файлов с образами виртуальных машин

Подключитесь к серверу VMmanager как root через SSH и найдите каталог с файлами образов виртуальных машин.

Если речь идет о VMmanager версии 5, то эти файлы находятся в каталоге /home. Что же касается VMmanager версии 6, то, согласно документации, файлы образов виртуальных машин находятся в каталоге /vm. 

Вы можете найти каталог с файлом по имени виртуальной машины, например:

# find / -name gitlab
/home/gitlab

Здесь мы определили, что файл виртуальной машины gitlab находится в каталоге /home/gitlab. При этом размер файла составляет 49 Гбайт:

# ls -lh /home/gitlab
-rw------- 1 root root 49G Oct 26 16:32 /home/gitlab

При необходимости задайте вопрос службе сопровождения VMmanager о расположении файлов образов для вашей версии VMmanager.

Определение и преобразование формата образа виртуальной машины

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

# file /home/gitlab
/home/gitlab: QEMU QCOW Image (v2), 52428800000 bytes

Для импорта образа виртуальной машины в Proxmox VE нужно, чтобы формат файла был QCOW2. В нашем случае VMmanager версии 5 использовал именно этот формат.

Если файл виртуальной машины находится в необработанном формате RAW, то его несложно конвертировать в формат  QCOW2. Для конвертации можно использовать программу qemu-img. Она уже установлена на серверах Proxmox VE и VMmanager.

Чтобы преобразовать RAW в QCOW2, используйте такую команду:

# qemu-img convert -f raw -O qcow2 vm.raw vm.qcow2

Обратное преобразование выполняется следующим образом:

# qemu-img convert -f qcow2 -O raw vm.qcow2 vm.raw

Настройка правил брандмауэра

Перед тем как начинать копирование, убедитесь, что настройки брандмауэра на сервере VMmanager разрешают подключение через SSH на порту 22 с сервера Proxmox VE. Инструкцию можно найти в документации.

Завершение работы виртуальной машины

Перед копированием файла образа VM нужно полностью завершить ее работу. Для этого лучше всего подключиться к VM через консоль, завершить основные процессы командой systemctl stop, а затем завершить работу ОС:

# shutdown -h now

Ход процесса завершения наблюдайте через консоль VM, доступную в панели управления VMmanager.

Как только работа ОС будет полностью завершена, выключите VM через консоль VMmanager.

Мы не рекомендуем завершать работу VM из панели управления VMmanager, не остановив предварительно запущенные сервисы через консоль ОС. У нас были случаи, когда такая попытка для VM с работающим сервисом GitLab приводила к тому, что образ VM получился непригодным для запуска после импорта в Proxmox VE.

Копирование файла образа VM на сервер Proxmox

Файл образа VM можно скопировать, например, при помощи программы sftp. Для этого найдите на сервере Proxmox VE каталог раздела, в котором достаточно свободного места для загрузки образа VM. Далее сделайте этот каталог текущим и подключитесь через SSH к серверу Proxmox VE. 

После этого введите следующие команды:

# cd /rpool
# sftp root@xxx.xxx.xxx.xxx
sftp> cd /home/
sftp> ls
gitlab
sftp> get gitlab

Здесь мы сделали текущим каталог /rpool, подключились к серверу VMmanager, перешли в каталог с образами виртуальных машин и запустили загрузку предварительно остановленной VM сервиса Gitlab.

Проверим, что файл был успешно загружен:

# ls -lh
total 41G
drwxr-xr-x 2 root root 2 Oct 13 2020 data
-rw------- 1 root root 49G Oct 26 19:11 gitlab
drwxr-xr-x 3 root root 3 Oct 13 2020 ROO

Создание VM для импорта загруженного файла

Теперь нашей задачей будет создание VM, импорт и подключение к ней скопированного образа диска.

Прежде всего, создайте в управляющей панели Proxmox VE виртуальную машину без ОС с любым размером диска (рис. 14).

После создания VM запускать ее не нужно. 

Откройте для новой VM вкладку Hardware и запомните параметры диска. На рис. 15 эти параметры выделены рамкой красного цвета.

Нам потребуется идентификатор созданной машины (в нашем случае 607), а также название хранилища (у нас local-zfs).

На другом сервере используется хранилище local-lvm, при этом идентификатор VM равен 401 (рис. 16).

После создания VM нужно отключить и удалить диск. Для отключения диска выделите строку Hard Disk (scsi0) мышью, а затем щелкните кнопку Detach. 

Отключенный диск будет обозначен как «Unused Disk 0». Удалите его кнопкой Remove.

Импорт файла образа виртуальной машины

Далее импортируем загруженный с сервера VMmanager файл образа VM с помощью программы qm с параметром importdisk. Для импорта в хранилище local-zfs диска виртуальной машины 401 команда выглядит так: 

# qm importdisk 401 /rpool/gitlab local-zfs

В случае хранилища local-lvm и VM с идентификатором 607 используйте следующую команду: 

# qm importdisk 607 /rpool/gitlab local-lvs

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

В консоли наблюдаем процесс импорта:

importing disk '/rpool/gitlab' to VM 401 ...
transferred: 0 bytes remaining: 52428800000 bytes total: 52428800000 bytes progression: 0.00 %
transferred: 524288000 bytes remaining: 51904512000 bytes total: 52428800000 bytes progression: 1.00 %
...
transferred: 52014612480 bytes remaining: 414187520 bytes total: 52428800000 bytes progression: 99.21 %
transferred: 52428800000 bytes remaining: 0 bytes total: 52428800000 bytes progression: 100.00 %
Successfully imported disk as 'unused0:local-zfs:vm-401-disk-0'

После успешного импорта нужно добавить импортированный диск к виртуальной машине. Для этого выделите его мышью, щелкните кнопку Edit, а затем кнопку добавления Add (рис. 17).

Запуск импортированной виртуальной машины

На данном этапе можно приступать к запуску импортированной виртуальной машины. Единственное, что имеет смысл сделать перед запуском, это проверить порядок загрузки. Для этого выберите мышью строку Options в свойствах VM и убедитесь, что в первую очередь загрузка будет выполняться с диска (рис. 18).

При необходимости измените порядок загрузки.

Теперь запустите VM и подключитесь к ней с помощью консоли Proxmox VE. Если все сделано правильно, вы увидите в консоли приглашение для входа (рис. 19). 

Изменение настроек сетевого интерфейса

Импортированная виртуальная машина запустилась, однако у нее старые сетевые настройки, предназначенные для работы под управлением VMmanager на старом сервере. Эти настройки необходимо изменить.

При изменении настроек руководствуйтесь документацией на ОС, установленной в виртуальной машине. Для Debian зайдите через консоль (рис. 19) пользователем root и отредактируйте содержимое файла /etc/network/interfaces:

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.73
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.1

Здесь нужно указать правильные значения для полей address, netmask, gateway и dns-nameservers. Эти значения вы должны получить в дата-центре, который разместил ваш сервер или предоставил вам сервер в аренду.

Далее отредактируйте файл /etc/resolv.conf:

nameserver 192.168.0.1

В нем нужно добавить строки для каждого сервера DNS, предоставленного дата-центром, указав правильные адреса IP.

После редактирования файлов /etc/network/interfaces и /etc/resolv.conf перезагрузите ОС виртуальной машины, а затем убедитесь, что она доступна через SSH с вашей рабочей станции.

Замена адреса IP в приложениях

Чтобы приложения, установленные на импортированной VM, продолжили свою работу, необходимо отыскать в файлах конфигурации этих приложений старый адрес IP и заменить его новым. В этом вам помогут знания архитектуры приложений, а также команда grep.

Ниже мы привели пример команды, которая ищет адрес 192.168.0.73 в файлах конфигурации, расположенных в каталоге /etc:

# grep -r "192.168.0.73" /etc/

Если в импортированной VM был установлен брандмауэр, то его конфигурацию также следует отредактировать.

Например, если конфигурация хранится в файле /etc/iptable/iptable.conf, измените его, а затем загрузите правила следующей командой:

# iptables-restore < /etc/iptable/iptable.conf

Автор статьи: Александр Фролов.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

Импорт образа диска (виртуальной машины) приходится делать, например, при переносе из тестовой среды в продакшн или миграции из vmware esxi (в этом случае предварительно нужно конвертировать образ в qcow2).

Сначала скопируем файл qcow2 в домашнюю директорию пользователя root на Proxmox:

scp disk.qcow2 root@pve.koobik.lan:/root

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

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

qm importdisk ХХХ /путь/к/файлу.qcow2 имя_хранилища --format qcow2

Где ХХХ — id виртуальной машины (на скриншотах — 103), а имя хранилища — целевой накопитель (в standalone-конфигурациях — local):

root@KoobikHV:~# qm importdisk 103 /root/disk.qcow2 local --format qcow2importing disk '/root/disk.qcow2' to VM 103 ...
Formatting '/var/lib/vz/images/103/vm-103-disk-1.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=53687091200 lazy_refcounts=off refcount_bits=16
transferred 0.0 B of 50.0 GiB (0.00%)
transferred 517.1 MiB of 50.0 GiB (1.01%)
...
transferred 50.0 GiB of 50.0 GiB (100.00%)
Successfully imported disk as 'unused0:local:103/vm-103-disk-1.qcow2'

Диск подключен и не используется, в веб-интерфейсе это видно на вкладке Hardware:

Теперь выбираем диск, созданный при развёртывании машины (на скриншоте) — local:103/vm-103-disk-0.qcow2 и сверху кликаем на отключение (detach) и подтверждаем.

Теперь неискользуемых диска стало два:

Обратите внимание, импортированный диск остался Unused Disk 0, а отключенный стал Unused Disk 1 (его можно удалить), не перепутайте их.

Для подключения импортированного Unused Disk 0 — local:103/vm-103-disk-0.qcow2 дважды кликните на него и нажмите Add.

Теперь переходим в раздел Options:

Открываем настройки очередности загрузки (Boot Order) и включаем новый диск:

Виртуальная машина готова к запуску с импортированным диском.