Introduction
There are various ways to migrate existing servers to Proxmox VE. They can be divided into two categories:
- Physical-to-Virtual (P2V)
- Migration of physical servers to Proxmox VE
- Virtual-to-Virtual (V2V)
- Migration of virtual machines and containers from other hypervisors to Proxmox VE
Physical-to-Virtual (P2V)
Follow these how-to for a P2V migration, to turn a physical machine into a Proxmox VE hosted virtual machine.
Clonezilla Live CDs
This method is fast, reliable and OS independent as it uses live CDs.
- Get a live Linux CD like Clonezilla.
- Prepare the source host, make sure that you have standard IDE drivers enabled (for WinXP/Win2003 use the mergeide.reg (File:Mergeide.zip)), for W2k I followed this link (solution 2 worked for me): [1]
- Now, boot the physical host with Clonezilla, go for the beginner mode and select device — device and then remote, just follow the wizard
- On the Proxmox VE host, prepare a KVM guest, make sure you got a big enough IDE disk assigned (add 1 GB extra to be on the safe side) and also boot this KVM guest with the Clonezilla live CD and execute a shell.
- Become root and run fdisk (e.g.,
fdisk /dev/sda) to make sure thatsdais here, exit fdisk by enteringwand pressing enter, this is essential. - Now enter all commands that wizard on the source server instructs you too to configure the network and then start the disk copy.
- After the clone operation succeeded, stop the VM, then change the boot device to the hard disk in the VM «Options» panel, and then start the VM again. Windows should install all needed drivers automatically, just the Intel NIC drivers for e1000 must be loaded from ISO
VMware Converter
Physical (running) Windows server to Proxmox VE (KVM) using VMware vCenter Converter Standalone Client (V5)
Tested on an HP ProLiant ML350 G5 and G6
Prepare Windows
VMware vCenter Converter Standalone Client
- Download here(version 5.x is Free Software and also free of charge but you need to create an account and login before download)
Mergeide.reg
- Execute mergeide.reg (File:Mergeide.zip)
Prepare location to save local image
This guide is using an external USB Hard Drive. You may also save to a mapped network share.
NOTE Although the final image will be around the same size as the actual amount of data on the server, the Proxmox VE server should have enough free space to fit the total physical disk of the server unless you plan to shrink the windows disks. once migrated to Proxmox VE.
VMware vCenter Settings
Launch VMware vCenter and use the following settings:
- Source type: Powered-on machine
- Specify the powered-on machine: This local machine
- Select destination type: VMware Workstation or other VMware virtual machine
- Select VMware Product: VMware Workstation 8.0.x
- Name: Enter the desired name for the image
- Select a location for the virtual machine: Browse to the USB or Network drive where the image will be saved.
The next screen shows the settings for the virtual machine.
Click on «Advanced options», select the Post-conversion tab and make sure ‘Install VMware Tools on the destination virtual machine’ is NOT check. We do not want to install VMware tools.
Click next and then «Finish».
It will now convert your physical machine to a .vmdk file.
NOTE: Depending on your hardware, you may need to boot the .vmdk file using VMware Workstation or Player before moving the file to the Proxmox VE server. This allows windows to install additional drivers for the disk controller. If promoted to convert the disk to Workstation 9.x compatibility, say Yes. You won’t know if you need this step until starting the Windows VM in the final step. If you get a blue screen during boot, you should try this step.
Prepare the VM on Proxmox VE
Create a new KVM virtual machine. You’ll want to use similar CPU and memory as the physical system. In the Hard Disk menu, leave everything as default. We won’t be using the disk created by Proxmox VE. Finish creating the VM. Make note of the VMID. For this guide, we’ll be using 100 as an example.
Once the VMware converter has completed, disable all of the networks adapters on the physical server and shut down. Disabling the network adapters will avoid potential IP conflicts if you will start the physical server back into Windows after you have your new virtual server running.
Move the image to the Proxmox VE Server
Plug a USB Hard Drive into the server
From the Proxmox VE command line:
mkdir /mnt/usb
mount /dev/sdc1 /mnt/usb/
ls /mnt/usb
You should see the contents of the USB drive. In my case, the vmdk file was located in /mnt/usb/windows-server/
Converting to qcow2
We want to convert the .vmdk image file to qcow2. To do this, use the following command:
qemu-img convert -f vmdk /mnt/usb/windows-server/windows-server.vmdk -O qcow2 /var/lib/vz/images/100/windows-server.qcow2
This can take a while depending on the size of file and speed of your system.
Final Steps
Once the conversion is complete, we need to edit the configuration file for the VM.
nano /etc/pve/local/qemu-server/100.conf
In the line with ide0: we want to change vm-100-disk-1.raw,size=32G to windows-server.qcow2
You may delete the empty disk created by Proxmox VE when you created the VM.
rm /var/lib/vz/images/100/vm-100-disk-1.raw
Start the VM and open the console. Windows should boot up normally. It’ll take a few minutes to detect the hardware changes. If the Windows system had a static IP address, you’ll have to reconfigure the settings.
Alternative Methods
- OpenVZ Template Creators to create non Debian (we have DAB for it) templates.
Virtual-to-Virtual (V2V)
Follow these how-to for a V2V migration, to move a virtual machine (VM) from another hypervisor to VM on Proxmox VE.
VMware
This explains the migration from a VMware ESXi 6.7 hypervisor to Proxmox VE 6.1. It is tested with guests with the following operating systems:
- Debian 10
- Windows 10 Pro
- Windows Server 2016 Standard
Exporting
GUI
In VMware ESXi navigate to your virtual machine in the tree on the left.
Choose Actions->Export.
This will download disk images and information about your virtual machine in the .ovf format in the browser.
Move those files to a storage that is accessible by your Proxmox VE host.
CLI
Install VMware’s ovftool on your Proxmox VE host.
ovftool version 4.4 has been reported to work with the following versions of ESXi: 6.5 and 6.7. Others (for example, 6.0) might crash with an unhelpful error message
Remove any attached disk or ISO from your ESXi VM and run
ovftool vi://root@<ip-of-esxi>/<name-of-a-virtual-machine> .
to export a virtual machine from ESXi directly into your current directory.
You can replace the dot with any other path, for example «/mnt/pve/<some-storage>».
This way you can export directly to a storage that you created in Proxmox VE.
| Note: You have to extract .ova archives |
With some configurations you get a single (.ova) archive file that contains all .vmdk disk images and the small XML description .ovf file. If this is the case, then you have to extract it before you continue with qm importovf.
Importing
Go to the command line interface of Proxmox VE.
Use the command qm importovf <new-vmid> </path/to/file.ovf> <storage> to import the virtual machine. For example:
qm importovf 200 /tmp/exported-vm.ovf local-lvm
This will create a new virtual machine using cores, memory and VM name as read from the OVF manifest, and
import the disks. You have to configure the network manually.
You can find syntax and an example on how to use this command on its man page.
| Note: Windows guests require a few additional steps |
If you are migrating a Windows guest, you additionally have to execute the following commands. This example assumes that your imported virtual machine has the ID 130.
- Use UEFI instead of BIOS for the virtual machine:
qm set 130 --bios ovmf
- Windows requires additional drivers to use SCSI. Therefore, you should temporarily use SATA instead. In the following command, ‘scsi0’ should be replaced with the drive that’s used to boot Windows.
sed -i 's/scsi0:/sata0:/' /etc/pve/qemu-server/130.conf
This will give you a initial working version. You can then improve your experience and access remaining SCSI drives by installing additional drivers as explained in Windows 10 guest best practices.
Server self-migration
It is also possible to migrate without the need to export each VM separately including virtual disks.
This way, you can convert a server from vSphere to Proxmox VE without the need of a second server.
For this process your vSphere should use VMFS6 and you need at least one empty HDD.
1. Export the VM information without the disks using ovftool (you still need to configure the network configuration for each VM).
ovftool --noDisks vi://root@<ip-of-esxi>/<name-of-a-virtual-machine> .
2. Install Proxmox VE on some disk that does not contain any important data. You don’t need vSphere anymore at this point. If you have an OS disk with only vSphere on it, then you can now overwrite it with Proxmox VE.
Warning: Do not use/touch any other existing drives which are VMFS formatted
3. Create a directory on the above mention spare HDD.
4. Install vmfs6-tools which you need to mount (ready-only) the VMFS-formatted drives with the vSphere virtual disks.
apt install vmfs6-tools -y
5. List all available drives to identify the VMFS formatted ones
fdisk -l
6. Mount the VMFS disk partition (note it is read only)
vmfs6-tool /dev/<device><partition>
7. Convert the vSphere disk to a suitable format for Proxmox VE
qemu-img convert -f vmdk <path to your vmdk file>.vmdk -O <raw/qcow2> <path to your empty directory>.raw/qcow2 -p
8. While the conversion is in progress you may create the 1st VM from ovf
qm importovf 200 /tmp/exported-vm.ovf
9. As soon as the conversion is finished you may mount the new Proxmox VE disk image to the VM.
qm rescan
If all VM images have been moved away from a VMFS6 disk, you can format it and use it at Proxmox VE
HyperV
This explains the migration from a Hyper-V on Windows 10 hypervisor to Proxmox VE 6.1. It is tested with a Proxmox VE 6.1 guest.
Proxmox VE uses qemu-img to import disks. In my tests it supported .vhdx even though some sources don’t explicitly list .vhdx as supported format. There are additional options if this should not work anymore:
- Convert-VHD is a command line tool that is built-in in Windows and converts .vhdx to .vhd. This format is supported by qemu-img.
- StarWind V2V Converter is a graphical tool that can create .qcow2 disks from Hyper-V guests.
In Hyper-V-Manager choose «Export…» at the right side and then a destination. While many files (for example for snapshots) will be exported, we are only interested in the .vhdx file(s). Move those files to a storage that is accessible by your Proxmox VE host. You will have to recreate the virtual machine settings yourself.
Go to the GUI of Proxmox VE and create a new virtual machine. We don’t need the hard disk that the virtual machine creation wizard created. Delete it in the hardware options of the virtual machine.
Now go to the command line interface of Proxmox VE. Use the command «qm importdisk» to import the .vhdx virtual hard disk. You can find syntax and an example on how to use this command on its man page.
XEN
XEN also uses qemu disk format, so it should work in the same manner as described under «VMware to Proxmox VE».
You could use xenmigrate to do it.
FreeNAS
Those are the necessary steps to migrate a Ubuntu Bionic VM from FreeNAS 11.2 to Proxmox VE 6.2-1.
The VM in FreeNAS was created with the following parameters
- Boot Loader Type: UEFI
- Guest OS: Ubuntu Bionic
- Disk
- Disk Mode: AHCI
- Zvol: test/ubuntu-1xmtpt
Check the name of your zvol by going to Virtual Machines → Options of the VM ⋮→ Devices → Options of your disk ⋮ → Edit → Zvol
Preparation in FreeNAS
- Create a shared directory in Sharing → Unix (NFS) Shares with path
/mnt/test. - Enable SSH in Services & edit the SSH service (Actions) to allow password login for root
- Copy the zvol to the shared directory
- Log in to FreeNAS via SSH
ssh root@ip.of.your.freenas
- Copy the zvol to the shared directory
dd if=/dev/zvol/test/ubuntu-1xmtpt of=/mnt/test/ubuntu.raw bs=1m
- Log in to FreeNAS via SSH
Importing to Proxmox VE
- Create a virtual machine (here vmid is 103) in Proxmox VE. Make sure to set BIOS to OVMF (this is UEFI).
- Delete the disk that was created in step 1.
- Create a directory
mkdir /home/user/freenas - Mount the shared directory from FreeNAS
sudo mount -t nfs 192.168.31.241:/mnt/test /home/user/freenas
- Import the image of the FreeNAS VM to the Proxmox VE VM as unused disk (vmid 103, storage local)
qm importdisk 103 /home/user/freenas/ubuntu.raw local --format qcow2
- In the GUI of Proxmox VE:
- Go to the hardware view of your new virtual machine
- Set the display to spice
- Double click on the unused disk to attach it and choose Virtio as bus
- Go to the options view of your new virtual machine
- Choose your new virtio disk as bootdisk
RHEV
The last released version of Red Hat Enterprise Virtualization (RHEV) is out of full support since August 2022[1] and you might want migrate to a supported Proxmox VE releases earlier than it’s EOL date.
To move existing VMs you need to export them as OVA (archived docs).
You should be able to do so by selecting the virtual machine, use the More Actions menu and there click on Export to OVA and use a directory or share that PVE either can directly access or easily moved later on.
On the Proxmox VE side you can extract the OVA, for example with tar xf exported-vm.ova for the more common tar format (or unzip if compressed as zip archive).
Then you can use qm importovf VMID /path/to/extracted.ovf and qm importdisk VMID PATH/TO/DISK.img STORAGE-ID
QEMU/KVM
- Create an new VM on Proxmox VE
- add the existing disk image to the new VM
- add network, usb, pcie, … devices as they where in the original VM
- set the boot order and adapt other options
- start the VM
Basic Example, Step-by-Step:
First a VM has to be created, for that you need to select an unused VMID (e.g., use pvecm nextid.
qm create 120
In the next step the some-image.img refers to the disk image you want to import and the some-storage refers to the name of a target storage, as listed in pvesm status.
Please adapt those to the respective values.
qm disk import 120 some-image.img some-storage
Please note that qm importdisk adds the image as unused disk to the virtual machine, you can re-attach it to the VM via the web-interface.
You also need to mark it as a boot-disk, this can be done by using qm set 120 --boot order=scsi0.
qm set 120 --scsi0 some-storage:vm-120-disk-0
Basic Example: All-in-One:
Since Proxmox VE 7.2 you can use the qm create command to achieve all steps in one go:
qm create VMID --scsi0 STORAGE:0,import-from=/PATH/TO/DISK.IMG --boot order=scsi0
Please replace ALL-CAPS parts with the respective value. After that you can adapt the remaining basics (memory, vCPU core count, vNICs, …) via the web-interface.
Further information
If your use case is not covered by this article you should check out the additional ways to migrate to Proxmox VE in the wiki.
It gathers years of knowledge for cases which are not as common as the ones explained here, but sometimes is also rather outdated.
See Also
- Migrate to Proxmox VE
- Reference docs for importing VMs and their disk images.
References
- ↑ https://access.redhat.com/support/policy/updates/rhev
-
Конвертируем системные диски с помощью disk2vhd
-
Конвертируем диск vhdx в qcow2 в Windows
-
Создаем виртуальную машину Proxmox
-
Отключаем и удаляем диск виртуальной машины в Proxmox
-
Переносим сконвертированный диск формата qcow2 на локальный store Proxmox или хранилища подключенного к нему по SMB или NFS.
-
Делаем импорт диска в Proxmox и подключаем его к нашей виртуальной машине
-
Запускаем и проверяем
-
Уменьшение диска виртуальной машины
Конвертируем системные диски с помощью disk2vhd
Скачать disk2vhd можно здесь
Распаковываем и запускаем на сервере который хотим конвертировать.
При конвертации я выбираю системный диск, остальные диски отдельно так как их можно подключить и перенести данные вручную, а на самой виртуальной машине в Proxmox можно создать диски на тех разделах что предпочтительнее по скорости и размерности.
Конвертируем диск vhdx в qcow2 в Windows
Для конвертации диска нам понадобится программа qemu-img скачать можно тут.
Скачиваем и распаковываем, запускаем командную строку с правами администратора.
Выполняем команду: D:\qemu>qemu-img.exe convert -O qcow2 d:\JSERVER.VHDX d:\JSERVER.qcow2 и ждем процесс долгий
Создаем виртуальную машину Proxmox
Создаем виртуальную машину с любым размером жесткого диска.
Отключаем и удаляем диск виртуальной машины в Proxmox
Выбираем нашу виртуальную машину, переходим на вкладку оборудование выбираем жесткий диск и сверху кнопка отключить.
После отключения диска появится кнопка удалить, нажимаем ее.
Переносим сконвертированный диск формата qcow2 на локальный store Proxmox или хранилища подключенного к нему по SMB или NFS.
Чтобы выполнить перенос диска на гипервизор Proxmox используем WInSCP, тем кто пользовался вопросов не возникнет. Скачать можно тут.
Вот сконвертированный диск, который я забросил на хранилище подключенное к Proxmox по NFS и его переименовал, имя такое же как на фото выше, так как оно прописано в конфигурационном файле.
Делаем импорт диска в Proxmox и подключаем его к нашей виртуальной машине
Импорт диска в нашу созданную виртуальную машину взамен удаленного делается командой: qm importdisk 105 /mnt/pve/Backup/vm-105-disk-0.qcow2 Backup
где 105 — id виртуальной машины,
/mnt/pve/Backup/vm-105-disk-0.qcow2 — полный путь к диску
Backup — название store.
После успешного выполнения команды по импорту, выбираем виртуальную машину заходим в оборудование и видим не используемый диск.
Сверху выбираем редактировать
откроется окно и выбираем добавить
Все диск добавился.
Запускаем и проверяем
Как видно из скриншота машинка благополучно стартанула.
Уменьшение диска виртуальной машины
Не забывайте, что предварительно нужно в службе управления дисками сжать наш диск с системой на тот объем, который хотим отрезать, эта область перейдет в статус неразмеченная.
Выключаем машину и отключаем жесткий диск в разделе оборудование виртуальной машины.
Идем в консоль гипервизора и выполняем команду:
qemu-img resize —shrink /Data/images/105/vm-105-disk-0.raw -400G
где -400G — объем на который уменьшаем диск.
Добавляем повторно диск и стартуем машину.
В моем блоге уже была статья о том, как выполняется установка Proxmox. В этой публикации я кратко покажу, как выполняется миграция виртуальных машин из Hyper-V в Proxmox. Причем миграция разных поколейний виртуальных машин Hyper-V – как ВМ первого поколения, так и ВМ второго поколения.
Приведенная ниже последовательность действий покрывает основные типовые сценарии миграции. Поскольку дополнительных вводных при миграции может быть много, то маловероятно, что это руководство можно рассматривать как универсальное и охватывающее все возможные случаи.
В руководстве от Proxmox не так много пояснительной информации о процессе миграции с Hyper-V. Поэтому я постараюсь наглядно показать весь процесс.
Исходные данные
Для тестового сценария создал несколько виртуальных машин.
Виртуальная машина 1.
| Параметр | Значение |
| Поколение виртуальной машины Hyper-V | 2 |
| Операционная система | Ubuntu Server 22.04 LTS |
| Тип BIOS | UEFI |
| Размер диска 1 (системный) | 60 ГБ |
Виртуальная машина 2.
| Параметр | Значение |
| Поколение виртуальной машины Hyper-V | 2 |
| Операционная система | Windows Server 2016 Standard |
| Тип BIOS | UEFI |
| Размер диска 1 (системный) | 60 ГБ |
Немного забегая на перед скажу, что миграция виртуальных машин Linux чуть проще, т.к. драйвер для Virtio уже на есть на борту. Для виртуальных машин Windows этот драйвер нужно будет установить вручную.
В качестве исходного гипервизора Hyper-V выступал Windows Server 2022.
В качестве целевого гипервизора выступает Proxmox 7.2-7.
Предварительная подготовка
Шаги по предварительной подготовке виртуальных машин одинаковы, как для платформы Linux, так и для платформы Windows:
- Создание копии vhd/vhdx диска.
- Копирование 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“.
При следующем шаге важно определиться с форматом дисков, которые вы будите использовать (raw|qcow2|vmdk). У каждого формата есть свои особенности. Например, в raw (формат по умолчанию, если ничего не указывать) не будут работать снимки. Если вам нужны снимки, то используйте формат qcow2. Для этого необходиммо использовать дополнительный параметр –format. Например так: qm importdisk 104 /mnt/pve/HDD/tst-lin.vhdx NVMe –format qcow2
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.
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. В случае каких-то затруднений я могу порекомендовать ознакомиться вот с этим руководством. Вероятнее всего там вы сможете найти ответы на какие-то ваши вопросы или ошибки.
Модератор: UncleFather
-
UncleFather
- Site Admin
- Сообщения: 1569
- Зарегистрирован: 17 авг 2004 16:20, Вт
- Контактная информация:
Перенос MS Windows Server с железного сервера на гипервизор Proxmox
Задача:
Необходимо перенести «железный» сервер под управление MS Windows Server в виртуальную среду под управлением гипервизора Proxmox.
Решение:
-
Подготавливаем образ сервера утилитой Disk2vhd;
-
В Proxmox создам новую виртуальную машину. Диск не подключаем;
-
Подключаем носитель с образом, созданном на шаге 1, к серверу и открываем консоль Proxmox;
-
Если подключаем диск NTFS, то для того, чтобы он подключился в режиме, поддерживающем запись, нужно установить ntfs-3g:
-
Монтируем диск в папку, например, в /var/lib/win2003/:
Код: Выделить всё
mount -t ntfs-3g /dev/sdb2 /var/lib/win2003/ -
Для использования в Proxmox, образ диска vhdx необходимо переконвертировать в формат iso (raw). Можно воспользоваться сторонним ПО, например, StarWind V2V Converter, либо установить gemu-utils в Proxmox:
-
И конвертировать сразу в Proxmox:
Код: Выделить всё
qemu-img convert -f vhdx -O raw '/var/lib/win2003/hdd2vhd server1C System.VHDX' /var/lib/win2003/win2003.img -
Импортируем полученный образ в виртуальную машину:
Код: Выделить всё
qm importdisk 100 /var/lib/win2003/win2003.img local-lvmздесь:
-
100 — ID виртуальной машины в Proxmox;
-
local-lvm — хранилище, где будет лежать импортированный образ;
-
-
Открываем Hardware в виртуальной машине, находим подключенный неиспользуемый диск и добавляем его:
-
-
Пытаемся загрузиться. Если возникает BSOD с ошибкой 0000007b, то:
-
Качаем образ Hiren’s BootCD;
-
Подключаем его к виртуалке и загружаемся с него в Load Mini XP;
-
Открываем HBCD Menu, выбираем Programs → Registry → Fix hard disk controller (fix_hdc.cmd). Этот патч удаляет привязки к установленным драйверам рейдов и прочих нестандартных контроллеров и оставит IDE по умолчанию;
-
Далее, выбираем «T», указываем путь : c:\windows и нажимаем «М» для завершения отвязки.
-
-
В установленной копии Windows понадобится установка драйверов:
-
Качаем образ с драйверами Windows VirtIO Drivers (по ссылке можно скачать предыдущие версии образов), подключаем его к ВМ и устанавливаем драйверы из папки D:\i386\w10;
-
Качаем драйверы для Hardware ID — ACPI\QEMUVGID, распаковываем и устанавливаем драйверы из папки wgencounter.
-
Alexander A. Manaeff©
Понравилась статья? Будем крайне признательны за репосты в соцсетях! Материально поддержать проект можно здесь
В современном мире, где IT-инфраструктуры постоянно развиваются, виртуализация становится все более востребованной в корпоративной среде. Однако для некоторых устаревших систем или клиентов, скептически настроенных к виртуализации, процесс миграции с физического сервера на ВМ (P2V) может показаться сложным и трудным. Особенно учитывая, что некоторые классические инструменты P2V, такие как VMware Converter, постепенно выводятся из эксплуатации, важно найти эффективный, надежный и совместимый метод миграции.
В этой статье мы представим простое и практичное решение для миграции P2V с использованием инструмента Disk2vhd от Microsoft Sysinternals в сочетании с мощной поддержкой виртуализации, предоставляемой Proxmox. Это решение не только абсолютно бесплатно, но и эффективно и гибко при миграции с физических устройств в современные виртуализированные среды на базе Proxmox.
Как перенести физический сервер Windows в Proxmox?
Создайте файлы VHDX с помощью Disk2vhd
1. Скачайте утилиту Disk2vhd
2. Откройте Disk2vhd и выберите уровень диска (а не уровень раздела) для создания образа, чтобы избежать создания множества хаотичных файлов VHD.
3. Сохраните созданный файл VHDX на локальное хранилище физической машины.
Конвертируйте VHDX в формат QCOW2
Перенесите файлы VHDX на сервер Proxmox, рекомендуемый путь это /var/lib/vz/harddrives/
Используйте следующую команду для преобразования файлов VHDX в формат QCOW2
qemu-img convert -O qcow2 /var/lib/vz/harddrives/XXXX.vhdx /var/lib/vz/images/XXX/vm-XXX-disk-X.qcow2
Добавьте сконвертированные диски в виртуальную машину на Proxmox
1. Создайте новую виртуальную машину в веб-интерфейсе Proxmox и настройте базовую информацию.
2. Привяжите преобразованные файлы QCOW2 к ВМ
3. Перейдите к файлу конфигурации виртуальной машины (обычно расположенному по адресу /etc/pve/qemu-server/VMID.conf) и добавьте записи дисков:
scsi0: local:XXX/vm-XXX-disk-X.qcow2
Или добавьте диск через веб-интерфейс Proxmox, выбрав существующий файл QCOW2
Подготовьте ВМ для оптимальной производительности
Шаг 1: Добавьте пустой диск размером 1 ГБ и выберите контроллер VirtIO для установки драйвера VirtIO.
Шаг 2: Подключите преобразованный диск как IDE к виртуальной машине.
Шаг 3: Запустите виртуальную машину, загрузитесь с IDE диска и установите драйвер VirtIO.
Шаг 4: Измените контроллер диска с IDE на VirtIO и удалите ранее пустой диск.
Проверьте и оптимизируйте
Запустите виртуальную машину и проверьте способна ли она корректно функционировать.
Проверьте, что производительность соответствует ожиданиям, и обратитесь к руководству по настройке драйвера VirtIO, если требуется дальнейшая оптимизация.
Рекомендуемое использование Vinchin для обеспечения безопасности данных после миграции
Миграция P2V является лишь первым шагом в виртуализации, но также критически важно обеспечить безопасность и стабильность виртуальных машин после миграции. Vinchin Backup & Recovery рекомендуется как надежное средство защиты данных после миграции.
Vinchin предоставляет широкий спектр платформ виртуализации и совместим с более чем 15 основными технологиями виртуализации, включая Proxmox, VMware, Hyper-V, XenServer, XCP-ng и OLVM. Оно обеспечивает централизованную защиту различных типов виртуальных машин через единую платформу управления, что особенно подходит для сложных потребностей в управлении данными в гибридных облачных средах.
Операция Vinchin Backup & Recovery очень проста, всего несколько шагов.
1. Просто выберите виртуальные машины на хосте
2. Затем выберите место назначения для резервной копии
3. Выберите стратегии
4.Наконец отправьте работу
Vinchin предлагает пользователям бесплатную 60-дневную пробную версию, чтобы вы могли глубже ознакомиться с возможностями продукта в реальной рабочей среде. Для получения дополнительной информации, пожалуйста, свяжитесь напрямую с Vinchin.
FAQs о миграции с физического сервера на виртуальную машину в Proxmox
Вопрос 1: Можно ли конвертировать работающий физический сервер в виртуальную машину?
Ответ 1: Да, некоторые инструменты поддерживают «живую» миграцию P2V (Physical to Virtual), при которой физический сервер остается в рабочем состоянии во время процесса конвертации. Однако это может быть более сложным и потребовать дополнительных ресурсов и планирования.
Вопрос 2: Могу ли я отменить изменения, если что-то пошло не так во время конвертации P2V?
Ответ 2: Да, если у вас есть резервная копия физического сервера, вы можете восстановить его в исходное состояние. Всегда полезно иметь надежную резервную копию перед выполнением крупных изменений.
Заключение
В условиях быстро меняющейся IT-среды миграция P2V является важным шагом между традиционными системами и современными виртуализированными инфраструктурами. Используя такие бесплатные инструменты, как Disk2vhd и Proxmox, предприятия могут упростить этот переход, при этом обеспечив безопасность данных после миграции с помощью Vinchin Backup & Recovery.