Kvm перенос виртуальной машины на другой сервер

Обновлено: 09.01.2025

При миграции виртуальной машины с локальным хранилищем копируется память и копируется диск. Форматы хранилища-источника и хранилища-приемника должны совпадать (RAW или Qcow2).

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

Типы миграции

Существует два типа миграции:

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

Алгоритм живой миграции виртуальной машины:

Копируется XML-описание виртуальной машины на сервер назначения;
Выполняется перенос диска виртуальной машины:
1. Если диск в локальном хранилище, он копируется на сервер назначения;
2. Если диск в сетевом хранилище, он подключается к серверу назначения.
Алгоритм миграции остановленной виртуальной машины:
1. Копируется XML-описание виртуальной машины на сервер назначения;
2. Выполняется перенос диска виртуальной машины:
  1. Если диск в локальном хранилище, он копируется на сервер назначения;
  2. Если диск в сетевом хранилище, он подключается к серверу назначения.
  В случае живой миграции активно используемой виртуальной машины, процесс переноса может занимать продолжительное время и приводить к потере данных.
  
  Живая миграция может быть прервана, если во время выполнения процесса переноса произойдет перезагрузка виртуальной машины. В таком случае миграция завершится, а виртуальная машина останется на исходном узле кластера.
  
  Если ВМ находится в сетевом хранилище, при миграции её снапшоты будут удалены.
  
  Запуск миграции
  
  Нажмите Управление → Виртуальные машины → Миграция, чтобы мигрировать виртуальную машину.
  
  Состояние миграции
  
  После подтверждения указанных данных начинается процесс миграции. В статусе виртуальной машины появится иконка:
  
  Отмена миграции виртуальной машины осуществляется по нажатию данной иконки.
  
  В данном небольшом how-to хотел бы поделиться с вами своим опытом использования утилиты lvmsync.
  
  Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
  Передавать мы будем весь раздел LVM, на который установлена виртуальная машина. Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.
  
  Вот как выглядит перенос виртуальной машины в кратком виде:
  1. Делаем снимок LVM раздела.
  2. Передаем основной LVM раздел по сети, не останавливая нашу VM.
  3. Когда закончится передача основного раздела, останавливаем VM.
  4. Запускаем lvmsync для передачи снимка по сети. Передается не весь снимок, а только измененные блоки.
  5. Подготавливаем и запускаем VM на новом сервере.
  Подробнее о работе lvmsync, и дополнительных плюшках вы можете почитать на страничке проекта.
  
  Далее предполагается что у нас есть права sudo в системе, ssh доступ настроен по ключам, а вход под рутом запрещен.
  
  Приступим к переносу VM:
  
  Установка:
  
  Для работы lvmsync нам потребуется Ruby 1.8 (or later), ssh, и dmsetup.
  Скачиваем lvmsync на локальный компьютер:
  
  Копируем lvmsync в root PATH, например в /usr/bin/
  
  Подготовка удаленного сервера (server2):
  
  1) Скачиваем и устанавливаем lvmsync.
  2) Создаем LVM раздел для копируемой VM.
  
  Размер раздела должен быть равен исходному разделу (в принципе он может быть и больше исходного, но этот вариант мной не тестировался).
  
  Подготовка локального сервера и перенос VM.
  
  Далее все команды необходимо выполнять на сервере, с которого мы хотим переместить виртуальную машину (server1).
  
  1) Создаем definition xml:
  
  2) Делаем снимок раздела:
  Обратите внимание, что размер снимка должен выбираться в зависимости от интенсивности использования VM. Т.к. все данные, пока мы переносим основной раздел, будут «сохраняться» на снимок.
  И при полном заполнении снимка, он автоматически деактивируется.
  
  3) Не останавливая VM, переносим основной раздел с помощью dd:
  
  Здесь добавлено сжатие передаваемых данных гзипом, и отображение хода передачи данных с помощью pv.
  
  4) Когда перенос будет закончен, останавливаем виртуальную машину:
  
  5) И после полной остановки машины запускаем lvmsync для переноса снимка:
  
  Эта операция не только перенесет снимок на новый сервер, но и смержит его сразу с основным разделом LVM.
  
  6) Копируем definition xml на удаленный сервер:
  
  Подготовка и запуск виртуальной машины на новом сервере:
  
  1) Изменяем definition xml, если необходимо.
  
  2) Создаем виртуальную машину на основе xml:
  
  3) Запускаем нашу виртуальную машину, и прописываем ее в автостарт:
  
  Виртуальная машина KVM осуществляет горячую миграцию онлайн
  - 1. Метод миграции виртуальной машины KVM и вопросы, требующие внимания.
  - Два, пример конфигурации горячей миграции виртуальной машины kvm
  1. Метод миграции виртуальной машины KVM и вопросы, требующие внимания.
  
  1. Холодная миграция
  
  Обычно каталог, в котором мы храним диски виртуальных машин, представляет собой смонтированный на нем диск файловой системы nfs, и этот диск обычно является файловой системой LVM. Поэтому, когда вам нужно выполнить холодную миграцию, просто смонтируйте файловую систему nfs на целевом хосте, и вы увидите дисковый файл виртуальной машины, которую нужно перенести, обычно заканчивающийся на .qcow2 или .raw, а затем вы только необходимо добавить виртуальную машину. Отправьте файл конфигурации .xml на целевой сервер, а затем переопределите его для просмотра перенесенной виртуальной машины с помощью команды «virsh list --all».
  
  2. Термическая миграция
  
  При использовании общей системы хранения конкретный процесс динамической миграции KVM:
  1. В начале миграции клиент все еще работает на хосте, и в то же время страницы памяти клиента передаются на хост назначения.
  2. QEMU / KVM будет отслеживать и записывать любые изменения всех внутренних страниц, которые были переданы во время процесса миграции, и начинать передачу измененного содержимого страниц памяти в предыдущем процессе после того, как все страницы памяти были перенесены.
  3. QEMU / KVM оценит скорость передачи в процессе миграции. Когда оставшиеся данные памяти могут быть переданы в течение установленного периода времени (30 миллисекунд по умолчанию), QEMU / KVM завершит работу клиента на исходном хосте. оставшиеся данные для хоста назначения, и окончательно переданное содержимое памяти восстанавливает рабочее состояние клиента на хосте назначения.
  4. На этом операция динамической миграции KVM завершена. Мигрированный клиент должен быть максимально согласованным перед миграцией, если на целевом узле не отсутствует какая-либо конфигурация, например сетевой мост. Обратите внимание, что когда использование памяти в клиенте очень велико и часто изменяется, а скорость, с которой данные в памяти постоянно изменяются, превышает скорость памяти, которую может передавать KVM, процесс динамической миграции не может быть завершен, и только статическая миграция может быть выполнена в это время.
  
  3. Меры предосторожности при миграции
  
  Независимо от того, холодная это миграция или горячая, меры предосторожности в основном одинаковы.
  - Лучше всего переносить серверы той же марки ЦП;
  - 64-битный может быть перенесен только между 64-битными хостами, 32-битный и 64-битный хосты могут быть перенесены;
  - Имя виртуальной машины на хосте не может конфликтовать;
  - Конфигурация программного обеспечения целевого хоста и исходного хоста должна быть одинаковой, насколько это возможно, например, одна и та же сетевая карта с мостовым подключением, пул ресурсов и т. Д .;
  - Настройки двух перенесенных хостов cat / proc / cpuinfo | grep nx совпадают с NX, полное имя - «No eXecute», что означает «запрещено запускать». Это технология, применяемая к ЦП для разделения области памяти. в Только для хранения набора команд процессора или только для использования данных. Любая память, в которой используется технология NX, означает, что она используется только для данных, поэтому набор команд процессора не может храниться в этих областях. Эта технология может предотвратить большинство случаев переполнения буфера, то есть некоторые вредоносные программы помещают свой собственный набор вредоносных инструкций в область хранения данных других программ и запускаются, тем самым контролируя весь компьютер.
  резюме:
  - Копировать файлы изображений и файлы конфигурации виртуальной машины;
  - Измените определение этой виртуальной машины.
    2. Живая миграция
  - Создать общее хранилище;
  - Смонтировать общее хранилище на двух машинах (смонтировать вручную; использовать пул ресурсов);
  - Начать живую миграцию;
  - После миграции создайте файл конфигурации виртуальной машины;
  - Измените определение виртуальной машины.
  Два, пример конфигурации горячей миграции виртуальной машины kvm
  
  1. Экологическая подготовка:
  - Три сервера Linux, два из которых являются KVM-серверами, с IP-адресами 192.168.20.2 и 192.168.20.3. Один из них - это NFS-сервер с IP-адресом 192.168.20.4, который используется для общего хранилища (три сервера должны иметь возможность пинговать друг друга);
  - Обе виртуальные машины KVM должны иметь среду KVM.
  2. Настройте общее хранилище NFS.
  
  Конфигурация nfs-сервера 192.168.20.4 следующая:
  
  Теперь сервер NFS настроен! ! !
  
  Моя операция миграции здесь зависит от графической среды рабочего стола, если вам нужно использовать команду миграции, вы можетескачатьЭтот документ предназначен для справки, я не изучал использование переноса команд.
  
  Два сервера KVM настроены следующим образом (оба узла KVM необходимо настроить следующим образом):
  
  1. Установите программный пакет rpcbind и запустите службу rpcbind. Чтобы использовать инструмент запросов showmount, установите nfs-utils вместе:
  
  На этом этапе гарантируется, что каталоги, используемые двумя серверами kvm, хранятся на одном диске.(Примечание. Путь к каталогу файловой системы nfs, смонтированной на двух виртуальных машинах kvm, должен быть одинаковым. В моем случае две виртуальные машины kvm смонтированы в каталог / kvm / disk /, в противном случае в последующие операции)。
  
  3. Создайте тома хранения на двух серверах kvm:
  
  В следующем диалоговом окне целевой путь - «/ kvm / disk» KVM-машины, имя хоста - это IP-адрес сервера nfs, а исходный путь - это каталог, совместно используемый сервером nfs.
  
  Вышеупомянутые операции также необходимо выполнить на втором KVM, и лучше всего определить то же имя пула хранения. Чтобы избежать лишних хлопот.
  
  3. Создайте новую виртуальную машину на kvm1 для тестирования миграции.
  
  ：
  
  Загрузите файл системы centos iso самостоятельно, здесь вам нужно указать файл iso для установки:
  
  На этом этапе вы можете самостоятельно установить виртуальную машину.
  
  4. Настройте только что созданную сеть виртуальной машины в режим моста, и вы можете проверить связь с внешней сетью.
  
  Следующие ниже операции предназначены в основном для моделирования виртуальной машины для выполнения горячей миграции при предоставлении услуг пользователям общедоступной сети.
  
  1) Работа kvm1 следующая:
  
  После включения виртуальной машины настройте файл конфигурации сетевой карты виртуальной машины. Файл сетевой карты по умолчанию - ifcfg-eth0:
  
  Перезапустите сетевой сервис и подтвердите IP-адрес:
  
  5. Начните подготовку к горячей миграции недавно построенных centos 7.
  
  1) Выполните следующие операции на сервере kvm1:
  
  Заполните следующее, после заполнения нажмите «Подключиться»:
  
  Вам будет предложено установить следующие пакеты:
  
  В ответ на запрос всплывающего диалогового окна введите «да»:
  
  Введите пароль root целевого хоста:
  
  6. Начать тепловую миграцию.
  
  Дождитесь завершения миграции, этот процесс выполняется быстро:
  
  Перенос завершен:
  
  Теперь перейдите к целевому серверу kvm и откройте только что перенесенную виртуальную машину (вы обнаружите, что команда ping все еще продолжается, и прерывания нет вообще):
  
  Вы можете использовать команду «virsh list --all» для подтверждения на двух серверах kvm по отдельности, действительно ли эта виртуальная машина перенесена на второй сервер kvm.
  
  Глава 12. Живая миграция KVM
  
  В этой главе будет рассмотрен процесс живой миграции гостевых систем с гипервизора KVM на другой узел KVM.
  
  Под миграцией понимается процесс переноса виртуализированной гостевой системы с одного узла на другой. Миграция является основополагающим аспектом виртуализации, так как на этом уровне программное обеспечение совершенно не зависит от оборудования. Основное назначение миграции:
  
  Load balancing - guests can be moved to hosts with lower usage when a host becomes overloaded.
  
  Hardware failover - when hardware devices on the host start to fail, guests can be safely relocated so the host can be powered down and repaired.
  
  Energy saving - guests can be redistributed to other hosts and host systems powered off to save energy and cut costs in low usage periods.
  
  Geographic migration - guests can be moved to another location for lower latency or in serious circumstances.
  
  Миграция может быть выполнена в автономном режиме или подключенном режиме (так называемая «живая» миграция). В процессе миграции память гостевой системы передается на целевой узел; при этом файловая система гостя будет сохранена в общем хранилище (она не будет передаваться целевому узлу по сети).
  
  An offline migration suspends the guest then moves an image of the guests memory to the destination host. The guest is resumed on the destination host and the memory the guest used on the source host is freed.
  
  Длительность автономной миграции зависит от полосы пропускания и сетевой задержки. Так, перенос гостевой системы с 2 Гбайт памяти по 1 гигабит Ethernet займет около 10 секунд.
  
  Живая миграция характеризуется тем, что работа виртуальных машин не останавливается при переносе. Все изменяемые за это время страницы памяти отслеживаются и передаются целевому узлу после завершения передачи образа. Процесс продолжается до тех пор, пока не будут скопированы все страницы или пока не истечет заданный гипервизором KVM период времени. Если страницы источника изменяются слишком быстро, то работа гостя на исходном узле будет приостановлена и будет выполнена передача регистров и буферов. Регистры будут загружены на новом узле и гость возобновит работу на целевом узле. Если же синхронизация невозможна, что вероятно в случае большой нагрузки, то виртуальная машина будет приостановлена для выполнения миграции в автономном режиме.
  
  Длительность такой миграции зависит от полосы пропускания, сетевой задержки и активности гостевой системы. Нагрузка на процессор и большие объемы операций ввода-вывода также могут сказаться на длительности процесса.
  
  Система виртуализации на базе Proxmox все больше набирает популярность при создании IT инфраструктуры в последнее время. Данное решение объединяет в себе черты профессиональной системы виртуализации с возможностью создания кластеров и централизованного управления с одной стороны. А также все свойства Open Source продукта с другой стороны. При миграции на данную систему управления виртуализации Вам скорее всего придется столкнуться с задачами импортирования виртуальных машин как из среды VMware, так и работающих под управлением гипервизора kvm. Как это сделать легко и просто со вторым типом виртуальных машин, используемых в open source среде хочется рассказать поподробнее.
  
  Последовательность действий
  
  Для начала миграции kvm виртуальной машины ее необходимо выключить на хосте источнике. После этого найти образ жесткого диска, который используется в виртуальной машине. Данный образ копируется на хост назначения с Proxmox, на котором мы будем проводить импорт. Допустим, образ нашего диска называется kvm_virtual_disk.qcow2.
  
  После этого проведем непосредственно импорт .qcow2 диска в гипервизор. Для этого также воспользуемся возможностями утилиты qm с параметром importdisk. Образец команды приведен ниже. В качестве датастора для хранения импортируемого диска мы в данном примере указываем local-lvm, в реальной жизни он может быть совершенно другим. Подразумевается, что образ диска .qcow2 находится в директории, из которой происходит выполнение команды.
  
  Когда операция успешно завершится, проводим заключительную операцию по привязке диска к виртуальной машине с помощью все той же утилиты qm. Это делается следующим образом.
  
  После этого донастраиваем параметры CPU, Memory, если надо сетевых интерфейсов в веб панели Proxmox. Теперь наша виртуалка полностью импортирована и готова к работе в среде Proxmox. Осталось запустить ее и дождаться отклика в консоли.
  
  Заключение
  
  Небольшая статья показывает основные моменты для импорта виртуальных машин kvm в гипервизор Proxmox. Хотя, в гипервизоре есть удобный веб интерфейс для управления, однако, все основные действия в данном случае приходится делать с помощью утилит командной строки. С учетом того, как хорошо развивается проект Proxmox VE в целом, можно предположить, что в скором будущем данный функционал будет доступен и в веб интерфейсе.
  
  Читайте также:

Запуск миграции

Состояние миграции

Приступим к переносу VM:

Установка:

Подготовка удаленного сервера (server2):

Подготовка локального сервера и перенос VM.

Подготовка и запуск виртуальной машины на новом сервере:

Виртуальная машина KVM осуществляет горячую миграцию онлайн

1. Метод миграции виртуальной машины KVM и вопросы, требующие внимания.

1. Холодная миграция

2. Термическая миграция

3. Меры предосторожности при миграции

Два, пример конфигурации горячей миграции виртуальной машины kvm

1. Экологическая подготовка:

2. Настройте общее хранилище NFS.

3. Создайте тома хранения на двух серверах kvm:

3. Создайте новую виртуальную машину на kvm1 для тестирования миграции.

4. Настройте только что созданную сеть виртуальной машины в режим моста, и вы можете проверить связь с внешней сетью.

5. Начните подготовку к горячей миграции недавно построенных centos 7.

6. Начать тепловую миграцию.

Глава 12. Живая миграция KVM

Последовательность действий

Заключение