Как перенести виртуальную машину proxmox на другой сервер

Миграция виртуальной машины proxmox на другой сервер

Смена IP адреса при переносе виртуальной машины на другой сервер
Всем добра! Ситуация следующая: переношу виртуальные машины(Hyper-V) с одного железа, на котором.

Перемещение виртуальной машины на другой диск
Всем доброго дня! Такой вопрос, начал работать в VirtualBox, но не расчитал места для нее, тем.

Характеристики виртуальной машины под веб сервер
имеется приложение написанное на python (Django) имеется база данных postgresql так же имеется.

VirtualBox. Перенос виртуальной машины на другой HDD
Привет! Появилась нужда перенести виртуальную машину на другой жесткий диск этого же хоста.

alex13v, привет. я просто перекинул нужные мне данные на другую виртуалку.

Бэкап работающей виртуальной машины с компа на Windows за NAT на Linux-сервер по SFTP
В общем такая задачка: есть Windows на которой в Workstation крутится виртуалка, нужно.

Настройка выхода с виртуальной машины в интернет от имени хост-машины
Добрый день. Столкнулся с проблемой выхода в интернет после того как поднял виртуалку на.

Создание виртуальной машины
У меня стоит windows 7. Хочу создать сайт, для этого собираюсь использовать virtualbox, и.

Перенос виртуальной машины
Сама программа Virtual Box 4.3.12 r93733. Стоит она у меня как и полагается на диске С. Ну и по.

Источник

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.

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.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Перенос виртуальных машин и контейнеров Proxmox VE на другой сервер

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

Богатство возможностей вариантов хранения в Proxmox, являющееся несомненным преимуществом, в данной задаче поворачивается к нам обратной стороной медали. Во множестве гуляющие по сети рекомендации: скопировать образ диска виртуальной машины и настройки еще больше запутывают и сбивают с толку. А при использовании некоторых вариантов хранилища у вас просто может не быть привычного файла, который можно скопировать.

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

Мы не использовали никакого алгоритма сжатия, так как не видим в этом особого смысла если образ будет передаваться по локальной сети или при помощи съемного носителя, но при необходимости можете ее сжать, мы рекомендуем использовать современный быстрый и эффективный алгоритм Zstandard:

Теперь передадим копию на новый сервер виртуализации любым удобным способом, например, можно использовать SCP:

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

В нашем примере видно, что свободные ID начинаются со 105, а хранилищем образов является local-lvm. Далее все зависит от того, что мы восстанавливаем, виртуальную машину или контейнер. Для виртуалки выполним:

Где мы сначала указываем путь к резервной копии, затем любой свободный ID (он может отличаться от старого ID, в нашем случае просто совпало) и хранилище local-lvm при помощи ключа -storage, если этого не сделать, то виртуальная машина будет восстановлена в хранилище local.

Для контейнеров команда будет немного иной:

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

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

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Администрирование и не только

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

Страницы

среда, 11 марта 2020 г.

Руководство администратора Proxmox VE R 6.0 Глава 10.3-7.

Виртуальные машины Qemu/KVM

Миграция

Онлайн-Миграция

Когда ваша виртуальная машина запущена и у нее нет определенных локальных ресурсов (таких как диски в локальном хранилище, передаваемые через устройства и т. д.) вы можете инициировать динамическую миграцию с флагом-online.

Это запускает процесс Qemu на целевом хосте с флагом incoming, что означает, что процесс запускается и ожидает данных памяти и состояний устройства от исходной виртуальной машины (так как все другие ресурсы, например диски, являются общими, содержимое памяти и состояние устройства-единственные вещи, оставшиеся для передачи).

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

Offline Миграция

Копии и клоны

Установка виртуальной машины обычно выполняется с помощью установочного носителя (CD-ROM) от поставщика операционной системы. В зависимости от операционной системы, это может быть трудоемкой задачей, которую можно избежать.

Простой способ развернуть множество виртуальных машин одного типа-скопировать существующую виртуальную машину. Мы используем термин «Клон» для таких копий и различаем связанные и полные клоны.

Полный Клон

Результатом такой копии является независимая виртуальная машина. Новая виртуальная машина не имеет общих ресурсов хранения с исходной.

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

Связанный Клон

Они называются связанными, потому что новый образ все еще ссылается на оригинал. Немодифицированные блоки данных считываются из исходного изображения, но изменения записываются (а затем считываются) из нового места. Эта техника называется «Copy-on-write» (копирование на запись).

Для этого требуется, чтобы исходный том был доступен только для чтения. С помощью Proxmox VE можно преобразовать любую виртуальную машину в шаблон только для чтения). Такие шаблоны впоследствии могут быть использованы для эффективного создания связанных клонов. На заметку Вы не можете удалить исходный шаблон, пока существуют связанные клоны. Изменить целевое хранилище для связанных клонов невозможно, поскольку это внутренняя функция хранилища.

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

Чтобы избежать конфликтов ресурсов, все MAC-адреса сетевого интерфейса рандомизируются, и мы генерируем новый UUID для настройки VM BIOS (smbios1).

Шаблоны виртуальных машин

Идентификатор поколения виртуальной машины

Proxmox VE поддерживает Virtual Machine Generation ID (vmgenid) 15 для виртуальных машин. Он может быть использован гостевой операционной системой для обнаружения любого события, приводящего к событию сдвига времени, например, восстановления резервной копии или отката моментального снимка.

При создании новых виртуальных машин, vmgenid виртуальной машины будет автоматически сгенерирован и сохранен в файле конфигурации.

Импорт виртуальных машин и образов дисков

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

Образы дисков могут быть в формате vmdk, если диски поступают из VMware или VirtualBox, или qcow2, если диски поступают из гипервизора KVM. Наиболее популярным форматом конфигурации для экспорта виртуальных машин является стандарт OVF, но на практике взаимодействие ограничено, поскольку многие настройки не реализованы в самом стандарте, а гипервизоры экспортируют дополнительную информацию в нестандартные расширения.

Помимо проблемы форматирования, импорт образов дисков из других гипервизоров может завершиться неудачей, если эмулируемое оборудование слишком сильно меняется от одного гипервизора к другому. Виртуальные машины Windows особенно чувствительны к этому, так как ОС очень придирчива к любым изменениям оборудования. Эта проблема может быть решена путем установки утилиты MergeIDE.zip доступной в интернете, перед экспортом и выбором типа жесткого диска IDE, перед загрузкой импортированной виртуальной машины Windows.

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

GNU/Linux и другие свободные Unix обычно можно импортировать без хлопот. Обратите внимание, что мы не можем гарантировать успешный импорт/экспорт виртуальных машин Windows во всех случаях из-за проблем, описанных выше.

Пошаговый пример импорта Windows OVF

Microsoft предоставляет виртуальные машины для загрузки, для быстрого старта разработчиков Windows. Мы собираемся использовать один из них, чтобы продемонстрировать функцию импорта OVF.

Скачать виртуальную машину zip

После получения информации о пользовательском соглашении выберите Windows 10 Enterprise (Evaluation-Build) для платформы VMware и загрузите zip.

Извлеките образ диска из архива zip

Используя утилиту unzip или любой архиватор по вашему выбору, распакуйте zip и скопируйте через ssh/scp файлы ovf и vmdk на ваш хост Proxmox VE.

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

Это позволит создать новую виртуальную машину, используя ядра, память и имя виртуальной машины, считанные из манифеста OVF и импортировать диски в local-lvm хранилище. Вы должны настроить сеть вручную. Виртуальная машина готова к запуску.

Добавление образа внешнего диска к виртуальной машине

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

Источник

Миграция с Proxmox на VMmanager

Хостеры, уже выросшие из домашнего сервера с 1-2 виртуальными серверами до нескольких высокопроизводительных серверов в ДЦ, задумываются об автоматизации рутинных действий и администрировании виртуальных серверов.
Наиболее популярным из бесплатных менеджеров виртуализации является Proxmox.
При своих плюсах (он бесплатный, с открытым исходным кодом и сообществом), он имеет и минусы, которые с лихвой перекрывают эти плюсы:

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

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

В этой статье я расскажу, как перенести виртуальные машины с Proxmox под управление VMmanager. VMmanager не поддерживает импорт или миграцию контейнеров и виртуальных серверов с других менеджеров виртуализации. Но это не сложно сделать при помощи API VMmanager.
Рассмотрим вариант миграции контейнеров с Proxmox на VMmanager-OVZ.

Миграция контейнеров с Proxmox на VMmanager-OVZ.

Миграция упрощается тем, что это можно проделать на одном сервере.
VMmanager-OVZ без проблем устанавливается на том же сервере, где работает Proxmox без какого-либо вмешательства в работу контейнеров.

Для этого следует скачать и запустить файл-инсталлятор —
http://download.ispsystem.com/install.5.sh
после чего ответить на несколько вопросов для выбора требуемого программного продукта и его версии.
Так же автоматически подключится официальный репозитарии и начнется установка панели управления и сопутствующего ПО.
Обратите внимание, что настройки openvz от proxmox без каких-либо проблем используются в VMmanager-OVZ.
Единственное замечание: после установки VMmanager-OVZ, необходимо вручную скачать пример конфигурационного файла для openvz. Он требуется для создания контейнера, и отсутствует в дистрибутиве proxmox, поэтому в логах при попытке создатьконтейнер можно будет наблюдать такую ошибку:

2014-12-03T10:39:28+0800 vzctl: CT 100: Sample config /etc/pve/openvz/ve-basic.conf-sample not found: No such file or directory
2014-12-03T10:39:28+0800 vzctl: CT 100: Creation of container private area failed

Скачиваем пример конфигурационного файла для openvz с официального репозитория и помещаем в директорию, где он должен находиться:

Хочу обратить на внимание на один момент при переносе. Существует вероятность того, что идентификационные номеры контейнров могут не совпасть.
В обоих случаях нумерация начинается с 100. Хотя в Proxmox можно выбрать произвольный ID для создаваемого контейнера, в VMmanager этот счетчик начинается с 100 и не сбрасывается, после удаления всех контейнеров, нумерация продолжается с того числа, которое является последующим для удаленных. На этот счет есть одно решение: нужно удалить все созданные ранее виртуальные серверы и аварийно завершить процесс vmmgr, тогда нумерация пойдет сначала.

Настройка параметров в VMmanager-OVZ

Создание шаблона контейнера с параметрами по умолчанию.

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

Создание контейнера в Proxmox

Создание контейнера в VMmanager

Перенос контейнеров затруднен тем, что оба менеджера виртуальных серверов используют разные методы хранения информации о ресурсах управляемых контейнеров.
Proxmox использует конфигурационные файлы openvz, VMmanager — хранит все в базе данных mysql, дублируя настройки в файлы для openvz. Поэтому схема усложняется тем, что потребуется создать контейнеры из VMmanager-OVZ и затем заменить этот контейнер на контейнер из Proxmox.

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

Теперь перейдем к варианту миграции с Proxmox с виртуальными серверами на VMmanager-KVM.

Миграции виртуальных серверов с Proxmox на VMmanager-KVM.

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

Производим настройку VMmanager-KVM, не особо отличающуюся от той, что я описал выше для VMmanager-OVZ

И действуем по следующему алгоритму:

Настройки виртуальных машин proxmox хранятся в файлах /etc/pve/qemu-server/.conf
Файлы образов виртуальных машин Proxmox хранятся в директориях /var/lib/vz/images/Чтобы каждый раз для соединения серверов не вводить авторизационные данные с помощью ssh-keygen создадим ключ-пару и отправим публичный ключ на сервер Proxmox.

И дальше уже все можно проделать с помощью этого скрипта.

При описании возможностей переноса контейнеров и виртуальных машин использовалась тестовая установка proxmox со значениями по умолчанию и ситуация с боевыми серверами может отличаться. Если у Вас есть опыт реального применения Proxmox и вы готовы поделиться им, то будет очень приятно увидеть ваши комментарии. Удачной миграции и максимальной автоматизации в сфере предоставления услуг хостинга!

Источник