Перенос физической машины в виртуальную proxmox
Migration of servers to Proxmox VE
Contents
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 steps to do a P2V migration and turn a physical machine into a Proxmox VE virtual machine that uses Qemu and KVM.
Clonezilla Live CDs
This method is fast, reliable and OS independent as it uses live CDs.
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
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:
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 Finish.
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:
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
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.
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.
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
Virtual-to-Virtual (V2V)
Follow these steps to do a V2V migration and move a virtual machine from another hypervisor to a Proxmox VE virtual machine that uses Qemu and KVM.
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:
Exporting
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
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/ «. This way you can export directly to a storage that you created in Proxmox VE.
Importing
Go to the command line interface of Proxmox VE. Use the command qm importovf
to import the virtual machine. For example:
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 your guest is Windows, you additionally have to execute the following commands. This example assumes that your imported virtual machine has the ID 130.
This gives you a first working version. You can then improve your experience 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).
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.
5. List all available drives to identify the VMFS formatted ones
6. Mount the VMFS disk partition (note it is read only)
7. Convert the vSphere disk to a suitable format for Proxmox VE
8. While the conversion is in progress you may create the 1st VM from ovf
9. As soon as the conversion is finished you may mount the new Proxmox VE disk image to the VM.
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.
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.
XEN also uses qemu disk format, so it should work in the same manner as described under «VMware to Proxmox VE (KVM)».
You can 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
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
Importing to Proxmox VE
Qemu/KVM
Create an new VM on Proxmox VE and add the existing disk image to this new VM, set the boot order and start.
First a VM has to be created. 120 is an unused VM ID.
someImage.img is an image that was created before. someStorage is the name of a storage as listed in pvesm status.
qm importdisk adds the image as unused disk to the virtual machine. Thus, making it the bootdisk is still necessary.
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.
Конвертация физического Windows Server 2003 R2 на Proxmox VE4
Данная статья не откроет Америку, но позволит избежать многих проблем и курения форумов в течении пары дней.
У Windows Server 2003r2 есть проблемы с конвертацией, а именно — с драйверами VIRTIO. Не хочет данная система кушать эти драйвера как все остальные, нужны танцы с бубном и немного магии последовательности действий. Причины проблемы найти не удалось, зато методом тыка, гугла и боли был найден рабочий путь.
Создание пустой виртуальной машины
Передача данных в пустой виртуальный диск
Для передачи я использовал программу Selfimage. Простая программка с отличным функционалом.
Настройка проста: в верхней части программы нужно выбрать локальный диск, а в нижней — путь куда будет писаться образ. В данном случае будет использован NBD (Network Block Device) на сервере Proxmox, который по 1024 порту будет писать образ прямо в диск виртуальной машины.
На сервере Proxmox нужно запустить сервер NBD, выполнив команду:
После этого в Selfimage нажать кнопку «Start». После копирования данных — готово. Но проблемы начинаются после.
Драйвера
Вот тут начинается головная боль. Если вы поставите драйвера как обычно с диска — обновил все устройства и готово, то получите BSOD 7b без возможности восстановления системы, так как безопасный режим будет приводить к той же ошибке.
Итак, имеется два диска с различными драйверами VIRTIO, последовательность действий:
1) Нужно установить Baloon драйвер версии 0.1.100, после этого перезагрузиться;
2) Установить на маленький диск VIRTIO (о котором говорилось ранее) драйвер VirtSTOR версии 0.1.100. Выключить машину. Основной диск переключить в режим VIRTIO. Включить машину;
3) Переключите настройку электропитания ОС в «Максимальная производительность» и установите драйвер контроллера версии 0.1.52. Перезагрузка.
4) После перезагрузки можно продолжать установку драйверов (с любого диска) и настройку сервера в обычном режиме.
Что не работает: Драйвер мыши не устанавливается, работать с мышью из терминала физически трудно.
Так же рекомендую данную статью, позволит провести дополнительные настройки системы.
Перенос физической машины в кластере ProxmoxVE2(3) с DRBD на новое железо
Имея кластер из двух серверов стоящих на Proxmox с объединенным по DRBD хранилищем, бывает нужно обновить узел в этом кластере, без остановки работы машин в нем. Задача не сложная, но некоторые моменты не всегда вспоминаешь в процессе.
Поэтому, для себя, действия были записаны для будущего копипаста в консоль. Ну а раз уже написаны, почему бы не поделиться с людьми?
P.S. В конце небольшой бонус про расширение блочного устройства по имени DRBD, тюнинг и полезные ссылки.
1. Мигрируем все виртуальные машины на один узел который остаётся живым (PM2).
2. Заходим консолью на PM2 от привилегированного пользователя. Разрешаем находиться в кластере одному узлу:
3. Смотрим узлы в кластере:
4. Удаляем переезжающий узел из кластера:
5. Останавливаем синхронизацию DRBD:
и проверяем статус StandAlone командой
6. Удаляем записи о старой машине в /etc/pve/priv/
7. Устанавливаем на новую машину (PM1) ProxmoxVE2, указав при установке размеры разделов, написав в приглашении
boot: linux ext4 maxroot=8 swapsize=1 maxvz=10 (есть еще ключ minfree=200)
8. Заходим в консоль свежей PM1, обновляемся:
9. Добавляемся в кластер:
(192.168.0.12 это IP адрес PM2)
10. Установим утилиты для работы с DRBD:
но т. к. в репозитории дебиан старые утилиты нам нужно обновить их на аналогичные в ядре:
(в Proxmox 3 основаном на Debian 7 версия актуальна, поэтому пропускаем этот пункт)
11. Создаем/копируем файл с PM2 /etc/drbd.d/r0.res для примера следующего содержания:
12. Создаем логический раздел размером точь в точь как на рабочей машине:
и смотрим что мы наделали командой
14. Создаём метадату:
15. На всякий случай делаем вторичным
и отключаемся от всех
16. Говорим что на нашей машине хранилище в не актуальном состоянии командой:
и перезагружаем машину
17. В консоли первого сервера смотрим статус синхронизации командой:
18. В web интерфейсе в сторадже кластера разрешаем у хранилища с drbd наши узлы
Bonus: Расширение объема DRBD
Это все актуально для мета диска external.
1. Мы добавили объём дисков в рэйде. Расширяем раздел на котором лежит drbd:
2. На пустой машине сделаем хранилище вторичным:
3. Расширяем drbd, запустив на машине где крутятся виртуалки, т.к. диск на второй машине временно стопорнётся.:
4. Расширение устройства drbd увеличит только это блочное устройство, но не pv, чтобы увеличить его:
Если диск internal то придется на время или навсегда перенести метаданные на отдельный диск. Без остановки это можно сделать в два этапа
1. На одном из серверов:
a) Cтопорим drbd:
затем меняем в конфиге строчки
meta-disk internal
на
meta-disk /dev/”ваше устройство для метаданных”[0]
для которого очень рекомендуется ssd диск, но на время можно создать lvm раздел.
b) Затем на другой машине
и смотрим процес синхронизации
После завершения процесса у нас на этом сервере метаданные вынесены на отдельное устройство.
2. Повторяем пункт 1 на другом сервере.
Если ssd нет, то после расширения, дабы не испортить скорость работы хранилища, придется сделать обратные манипуляции. Но лучше купить пару ssd, а может и четыре, на запас или соединив их в RAID1 на каждом из серверов.
Перед любыми действиями вполне естественно делать резервные копии, а сделать их быстрее поможет строчка в файле /etc/vzdump.conf:
которая сделает ограничение скорости в 100 мегабит, по умолчанию стоит всего 10, что для 100 мегабитной сети вполне нормально, но для гигабит(а) слишком мягко.
UPD: Поздравляю с релизом Proxmox 3.0 на основе Debian Wheezy
Перенос физической машины в кластере ProxmoxVE2(3) с DRBD на новое железо
Имея кластер из двух серверов стоящих на Proxmox с объединенным по DRBD хранилищем, бывает нужно обновить узел в этом кластере, без остановки работы машин в нем. Задача не сложная, но некоторые моменты не всегда вспоминаешь в процессе.
Поэтому, для себя, действия были записаны для будущего копипаста в консоль. Ну а раз уже написаны, почему бы не поделиться с людьми?
P.S. В конце небольшой бонус про расширение блочного устройства по имени DRBD, тюнинг и полезные ссылки.
1. Мигрируем все виртуальные машины на один узел который остаётся живым (PM2).
2. Заходим консолью на PM2 от привилегированного пользователя. Разрешаем находиться в кластере одному узлу:
3. Смотрим узлы в кластере:
4. Удаляем переезжающий узел из кластера:
5. Останавливаем синхронизацию DRBD:
и проверяем статус StandAlone командой
6. Удаляем записи о старой машине в /etc/pve/priv/
7. Устанавливаем на новую машину (PM1) ProxmoxVE2, указав при установке размеры разделов, написав в приглашении
boot: linux ext4 maxroot=8 swapsize=1 maxvz=10 (есть еще ключ minfree=200)
8. Заходим в консоль свежей PM1, обновляемся:
9. Добавляемся в кластер:
(192.168.0.12 это IP адрес PM2)
10. Установим утилиты для работы с DRBD:
но т. к. в репозитории дебиан старые утилиты нам нужно обновить их на аналогичные в ядре:
(в Proxmox 3 основаном на Debian 7 версия актуальна, поэтому пропускаем этот пункт)
11. Создаем/копируем файл с PM2 /etc/drbd.d/r0.res для примера следующего содержания:
12. Создаем логический раздел размером точь в точь как на рабочей машине:
и смотрим что мы наделали командой
14. Создаём метадату:
15. На всякий случай делаем вторичным
и отключаемся от всех
16. Говорим что на нашей машине хранилище в не актуальном состоянии командой:
и перезагружаем машину
17. В консоли первого сервера смотрим статус синхронизации командой:
18. В web интерфейсе в сторадже кластера разрешаем у хранилища с drbd наши узлы
Bonus: Расширение объема DRBD
Это все актуально для мета диска external.
1. Мы добавили объём дисков в рэйде. Расширяем раздел на котором лежит drbd:
2. На пустой машине сделаем хранилище вторичным:
3. Расширяем drbd, запустив на машине где крутятся виртуалки, т.к. диск на второй машине временно стопорнётся.:
4. Расширение устройства drbd увеличит только это блочное устройство, но не pv, чтобы увеличить его:
Если диск internal то придется на время или навсегда перенести метаданные на отдельный диск. Без остановки это можно сделать в два этапа
1. На одном из серверов:
a) Cтопорим drbd:
затем меняем в конфиге строчки
meta-disk internal
на
meta-disk /dev/”ваше устройство для метаданных”[0]
для которого очень рекомендуется ssd диск, но на время можно создать lvm раздел.
b) Затем на другой машине
и смотрим процес синхронизации
После завершения процесса у нас на этом сервере метаданные вынесены на отдельное устройство.
2. Повторяем пункт 1 на другом сервере.
Если ssd нет, то после расширения, дабы не испортить скорость работы хранилища, придется сделать обратные манипуляции. Но лучше купить пару ssd, а может и четыре, на запас или соединив их в RAID1 на каждом из серверов.
Перед любыми действиями вполне естественно делать резервные копии, а сделать их быстрее поможет строчка в файле /etc/vzdump.conf:
которая сделает ограничение скорости в 100 мегабит, по умолчанию стоит всего 10, что для 100 мегабитной сети вполне нормально, но для гигабит(а) слишком мягко.
UPD: Поздравляю с релизом Proxmox 3.0 на основе Debian Wheezy
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Перенос виртуальных машин и контейнеров Proxmox VE на другой сервер
Перенос виртуальных машин между серверами (нодами) гипервизора Proxmox VE не входящими в кластер довольно часто встречающаяся задача. На первый взгляд она довольно простая, но имеет свои особенности, которые могут поставить в тупик начинающих администраторов этой системы виртуализации. Основная сложность заключается в том, что Proxmox может использовать различные виды хранилищ и форматов виртуальных дисков и, подходящие в одном случае рекомендации окажутся бесполезны в другом. Поэтому нужен универсальный способ, о котором мы хотим рассказать в этой статье.
Богатство возможностей вариантов хранения в Proxmox, являющееся несомненным преимуществом, в данной задаче поворачивается к нам обратной стороной медали. Во множестве гуляющие по сети рекомендации: скопировать образ диска виртуальной машины и настройки еще больше запутывают и сбивают с толку. А при использовании некоторых вариантов хранилища у вас просто может не быть привычного файла, который можно скопировать.
Затем создадим дамп виртуальной машины или контейнера, явно указав его размещение и режим копирования:
Мы не использовали никакого алгоритма сжатия, так как не видим в этом особого смысла если образ будет передаваться по локальной сети или при помощи съемного носителя, но при необходимости можете ее сжать, мы рекомендуем использовать современный быстрый и эффективный алгоритм Zstandard:
Теперь передадим копию на новый сервер виртуализации любым удобным способом, например, можно использовать SCP:
Покинем старый гипервизор и перейдем в командную строку нового, но перед этим уточним с какого номера начинаются на нем свободные идентификаторы и в каком хранилище располагаются образа дисков.
В нашем примере видно, что свободные ID начинаются со 105, а хранилищем образов является local-lvm. Далее все зависит от того, что мы восстанавливаем, виртуальную машину или контейнер. Для виртуалки выполним:
Где мы сначала указываем путь к резервной копии, затем любой свободный ID (он может отличаться от старого ID, в нашем случае просто совпало) и хранилище local-lvm при помощи ключа -storage, если этого не сделать, то виртуальная машина будет восстановлена в хранилище local.
Для контейнеров команда будет немного иной:
В ней мы сначала указываем желаемый свободный ID, а затем путь к архиву.
После завершения восстановления не спешите включать новую виртуальную машину, особенно если оба сервера находятся в пределах одной сети. Сначала выключите виртуальную машину на старом сервере, а потом внимательно проверьте настройки новой, иначе вы вполне можете получить глупые и досадные ошибки, например, такую:
А всего лишь потому, что на старом узле в привод виртуалки был смонтирован образ, который на новом месте отсутствует. Также внимательно проверьте все внешние устройства, например USB, удалите неиспользуемые и добавьте новые. После чего включите виртуальную машину или контейнер. Также не забудьте добавить ее в планы резервного копирования на новом сервере.
Затем тщательно проверяем работоспособность, после чего виртуальную машину со старого сервера желательно удалить. Также удалите использовавшиеся для переноса резервные копии на обоих узлах.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 