Kvm перенос виртуальной машины на другой сервер
Перенос установленной на LVM разделе виртуальной машины KVM на другой сервер с помощью lvmsync
В данном небольшом how-to хотел бы поделиться с вами своим опытом использования утилиты lvmsync.
Данная утилита позволяет решить задачу переноса виртуальной машины с одного сервера KVM на другой, с минимальным простоем виртуальной машины, без использования общего хранилища (non-shared storadge).
Передавать мы будем весь раздел LVM, на который установлена виртуальная машина. Ну а уменьшить время простоя нам поможет магия работы LVM snapshot, информацию о которой вы с легкостью можете найти в интернете.
Вот как выглядит перенос виртуальной машины в кратком виде:
Подробнее о работе 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) Делаем снимок раздела:
3) Не останавливая VM, переносим основной раздел с помощью dd:
Здесь добавлено сжатие передаваемых данных гзипом, и отображение хода передачи данных с помощью pv.
4) Когда перенос будет закончен, останавливаем виртуальную машину:
5) И после полной остановки машины запускаем lvmsync для переноса снимка:
Эта операция не только перенесет снимок на новый сервер, но и смержит его сразу с основным разделом LVM.
6) Копируем definition xml на удаленный сервер:
Подготовка и запуск виртуальной машины на новом сервере:
1) Изменяем definition xml, если необходимо.
2) Создаем виртуальную машину на основе xml:
3) Запускаем нашу виртуальную машину, и прописываем ее в автостарт:
Вот и все, перенос виртуальной машины закончен!
Русские Блоги
Виртуальная машина KVM осуществляет горячую миграцию онлайн
1. Метод миграции виртуальной машины KVM и вопросы, требующие внимания.
1. Холодная миграция
2. Термическая миграция
Если исходный хост и целевой хост совместно используют систему хранения, по сети необходимо отправлять только статус выполнения vCPU клиента.
Состояние, содержимое памяти и состояние устройства виртуальной машины на целевом хосте. В противном случае вам также необходимо отправить дисковое хранилище клиента на целевой хост
на борту. Под общей системой хранения подразумевается, что каталоги зеркальных файлов исходных и целевых виртуальных машин находятся в общем хранилище.
При использовании общей системы хранения конкретный процесс динамической миграции KVM:
1. В начале миграции клиент все еще работает на хосте, и в то же время страницы памяти клиента передаются на хост назначения.
2. QEMU / KVM будет отслеживать и записывать любые изменения всех внутренних страниц, которые были переданы во время процесса миграции, и начинать передачу измененного содержимого страниц памяти в предыдущем процессе после того, как все страницы памяти были перенесены.
3. QEMU / KVM оценит скорость передачи в процессе миграции. Когда оставшиеся данные памяти могут быть переданы в течение установленного периода времени (30 миллисекунд по умолчанию), QEMU / KVM завершит работу клиента на исходном хосте. оставшиеся данные для хоста назначения, и окончательно переданное содержимое памяти восстанавливает рабочее состояние клиента на хосте назначения.
4. На этом операция динамической миграции KVM завершена. Мигрированный клиент должен быть максимально согласованным перед миграцией, если на целевом узле не отсутствует какая-либо конфигурация, например сетевой мост. Обратите внимание, что когда использование памяти в клиенте очень велико и часто изменяется, а скорость, с которой данные в памяти постоянно изменяются, превышает скорость памяти, которую может передавать KVM, процесс динамической миграции не может быть завершен, и только статическая миграция может быть выполнена в это время.
3. Меры предосторожности при миграции
Независимо от того, холодная это миграция или горячая, меры предосторожности в основном одинаковы.
Требования к целевому серверу перед миграцией следующие:
резюме:
Два, пример конфигурации горячей миграции виртуальной машины kvm
1. Экологическая подготовка:
Моя среда выглядит следующим образом:
Моя среда KVM уже готова, поэтому я не буду показывать ее здесь. Если у вас нет среды KVM, вы можете обратиться к сообщению в блоге:Базовое управление виртуализацией KVMНастроить (очень просто, yum устанавливает некоторые пакеты и запускает службу «libvirtd», возможно, вам потребуется перезагрузить сервер).
2. Настройте общее хранилище NFS.
Конфигурация nfs-сервера 192.168.20.4 следующая:
Моя операция миграции здесь зависит от графической среды рабочего стола, если вам нужно использовать команду миграции, вы можетескачатьЭтот документ предназначен для справки, я не изучал использование переноса команд.
Два сервера KVM настроены следующим образом (оба узла KVM необходимо настроить следующим образом):
1. Установите программный пакет rpcbind и запустите службу rpcbind. Чтобы использовать инструмент запросов showmount, установите nfs-utils вместе:
На этом этапе гарантируется, что каталоги, используемые двумя серверами kvm, хранятся на одном диске.(Примечание. Путь к каталогу файловой системы nfs, смонтированной на двух виртуальных машинах kvm, должен быть одинаковым. В моем случае две виртуальные машины kvm смонтированы в каталог / kvm / disk /, в противном случае в последующие операции)。
3. Создайте тома хранения на двух серверах kvm:
Вышеупомянутые операции также необходимо выполнить на втором KVM, и лучше всего определить то же имя пула хранения. Чтобы избежать лишних хлопот.
3. Создайте новую виртуальную машину на kvm1 для тестирования миграции.
：
Загрузите файл системы centos iso самостоятельно, здесь вам нужно указать файл iso для установки:
На этом этапе вы можете самостоятельно установить виртуальную машину.
4. Настройте только что созданную сеть виртуальной машины в режим моста, и вы можете проверить связь с внешней сетью.
Следующие ниже операции предназначены в основном для моделирования виртуальной машины для выполнения горячей миграции при предоставлении услуг пользователям общедоступной сети.
1) Работа kvm1 следующая:
Теперь вы можете выполнить команду «ping www.baidu.com» на виртуальной машине, чтобы она продолжала проверять связь с общедоступной сетью.
2) КВМ2 работает следующим образом:
5. Начните подготовку к горячей миграции недавно построенных centos 7.
1) Выполните следующие операции на сервере kvm1:
Заполните следующее, после заполнения нажмите «Подключиться»:
Вам будет предложено установить следующие пакеты:
В ответ на запрос всплывающего диалогового окна введите «да»:
Введите пароль root целевого хоста:
6. Начать тепловую миграцию.
Дождитесь завершения миграции, этот процесс выполняется быстро:
Перенос завершен:
Теперь перейдите к целевому серверу kvm и откройте только что перенесенную виртуальную машину (вы обнаружите, что команда ping все еще продолжается, и прерывания нет вообще):
———————— На этом статья завершается, спасибо за чтение ————————
Интеллектуальная рекомендация
Генерация аудио PCM-данных в файлы WAV и MP3 с использованием FFMpeg
Справочник статей 1. Получить кодировщик и создать контекст декодера 2. Создайте аудио поток и выведите контекст обертки 3. Записать необработанные данные в файл Формат упаковки аудио WAV может хранит.
3. Wu Weida Machine Учебное примечание Полные сухие товары (глава 3: Линейный регрессионный обзор)
1053 Путь равного веса (30 очков)
1053 Путь равного веса (30 очков) Given a non-empty tree with root R, and with weight Wi assigned to each tree node Ti. The weight of a path from R to L&n.
1020 Tree Traversals
Главная мысль: Укажите количество узлов двоичного дерева, а также пост-порядок, результат прохождения среднего порядка и результат прохождения уровня. Идеи решения проблем: Подзадача о бинарном древе.
[OpenStack] Neenron Добавить ICMP и SSH правила (веб-интерфейс)
Вам нужно подготовить правила группы безопасности перед конфигурацией. Поскольку группа безопасности по умолчанию не позволяет Ping ICMP-пакеты и SSH удаленного входа в систему. Вам необходимо вручную.
Перенос виртуальной машины в KVM
По мотивам последних событий с моей работы решил написать этот пост, ибо ничего похожего в рунете к сожалению не обнаружил, а очень жаль, ибо перетаскивать виртуалки с VirtualBox и VMWare в благородный KVM все таки приходится. Один из популярных способов сводиться в сливу образа диска в KVM, а затем загрузка с установочного диска и востановление системы (а фактически новая установка поверх старых настроек). Лично меня подобная схема не устроила, потому что образ присланной виртуалки не содержал установочного диска с которого его можно было бы восстановить, а искать похожий образ муторно. Итак.
Мы имеем следующий набор. Виртуалка на VirtualBox или VMWare, гостевая система Windows (с linux такой свистопляски нет), и сервер с KVM на котором и будем размещать нашу виртуалку. В моем случае это сервер KVM который работает в связке с LVM, но я постараюсь затронуть и вариант когда KVM работает с файловыми образами диска.
1. Готовим систему к переносу.
После того как файлик был создан и сохранен, запускаем его и вносим изменения в реестр. Теперь осталось проверить что все необходимые файлы для запуска в KVM есть, для этого идем в C:\Windows\system32\drivers\ и ищем там файлы:
На этом мы закончили приготовления системы, и можем ее без проблем выключить.
2. Готовим образ диска
Тут есть варианты. Все зависит от того какая у вас система виртуализации щас, и где KVM будет хранить свои образы дисков.
Нам необходимо сконвертировать vmdk файл нашей виртуалки в формат SGF. Этот формат фактически сырой RAW нашего диска, и имеет расширение VMDK. Для VMWare он делается так
Если в этом месте возникают какие либо грабли, то попробуйте параметр «-t 0» заменить на «-t 2». Хотя в большинстве случаев все должно пройти без проблем.
После того как копирование завершиться вы увидете два образа, с одинаковым именем, но второй будет иметь после имени «-flat», например «windows.vmdk» и «windows-flat.vmdk». Как раз второй образ с flat и будет нашим SGF диском.
Для того что бы избежать ошибок можно проверить полученный образ. Для этого в linux есть команда file. Вывод нормального образа должен иметь примерно следующий вид
4. Устанавливаем образ в KVM
Тут все зависит от настроек KVM. Используете ли вы файлы, либо используете LVM. Оба варианта приведены ниже
Тут особой писать нечего. dd он и в Африке dd.
После этого можно кормить KVM этот раздел LVM
В качестве файлового стораджа я люблю использовать формат qcom2, хотя это больше вопрос религии. Тем не менее сконвертировать этот образ можно следующей командой
Я думаю что объяснять не нужно что меняя параметр «-О» можно выбрать другой формат хранения. После чего данный диск можно кормить KVM.
Стоит так же отметить, что qemu-img позволяет конвертировать не только SGF но и простые vmdk, хотя с менее предсказуемым результатом. Поэтому лучше конвертировать. Если при конвертации выпадает ошибка, попробуйте не использовать ключ «-f vmdk», и дайте утилите самостоятельно определить формат образа. Говорят что помогает.
Я не буду расписывать как настраивать KVM, вы уже большие и сами знаете как это сделать, отмечу только тот факт, что Windows ни под каким соусом не поддерживает virtio, поэтому даже не пытайтесь.
После первого запуска система должна определить все новое железо, и установить на все драйвера. Тут будте внимательны. У меня был случай когда Windows не смогла найти драйвера на ACPI процессора, и мне пришлось его отключить в диспетчере устройств, что бы система не падала в BSOD. После установки всех устройств, систему лучше перезагрузить.
С виртуалками разобрались, но как быть с реальными машинами? Честно говоря не пробовал, но есть мнение что данный способ годиться и для реальных машин.
Миграция виртуальных машин
При миграции виртуальной машины с локальным хранилищем копируется память и копируется диск. Форматы хранилища-источника и хранилища-приемника должны совпадать (RAW или Qcow2).
При миграции виртуальной машины с сетевым хранилищем копируется только память, а диск подключается к узлу кластера, на который осуществляется миграция. Виртуальная машина с сетевым диском при обычной миграции или миграции со статусом «остановлена» переносится, как правило, за несколько минут.
Типы миграции
Существует два типа миграции:
Алгоритм живой миграции виртуальной машины:
Алгоритм миграции остановленной виртуальной машины:
В случае живой миграции активно используемой виртуальной машины, процесс переноса может занимать продолжительное время и приводить к потере данных.
Живая миграция может быть прервана, если во время выполнения процесса переноса произойдет перезагрузка виртуальной машины. В таком случае миграция завершится, а виртуальная машина останется на исходном узле кластера.
Если ВМ находится в сетевом хранилище, при миграции её снапшоты будут удалены.
Запуск миграции
Нажмите Управление → Виртуальные машины → Миграция, чтобы мигрировать виртуальную машину.
Состояние миграции
После подтверждения указанных данных начинается процесс миграции. В статусе виртуальной машины появится иконка:
Отмена миграции виртуальной машины осуществляется по нажатию данной иконки.
KVM Live Migration без общего хранилища
Я решил написать эту статью, потому что так и не сумел найти ничего более менее внятного на эту тему в интернет, а уж тем более на великом и могучем. Итак задача: настроить систему миграции виртуальной машины с одного сервера KVM на другой, без выключения виртуального сервера (тоесть live migration), и без общего хранилища (non-shared storage), это значит, что вместе с виртуальной машиной будет передан и образ ее жесткого диска с одного сервера на другой. Звучит здорово, поэтому приступаем. Мы имеем 2 сервера с Ubuntu 10.04 LTS (установка minimal), ибо LTS, а всякий мусор на сервере нам ни к чему. В качестве жестких дисков для виртуальных машин будут выступать LVM разделы, это обеспечивает лучшую скорость работы и большую гибкость. Наверняка в качестве дисков можно использовать и файлы, разница я думаю не велика, но у меня под рукой именно LVM. Для удобства именования, первый сервер назовем vm1 второй соответственно vm2, LVM на обоих серверах имеет Volume Group с именем «vg», и это важно, что бы имя было одинаковым. Итак приступим. Сразу скажу что миграция виртуальной машины в qemu-kvm доступна с версии 0.12.1, а libvirt поддерживает миграцию без общего хранилища с версии 0.8.3, тем не менее до сих пор такая востребованная функция как живая миграция без общего хранилища kvm с машины на машину нигде толком не описана, поэтому исправляю эту ошибку. Так как Ubuntu у нас имеет версию 10.04, то сооствественно она имеет старые версии и qemu-kvm и libvirt, которые не позволят нам сделать все что нужно, но не отчаивайтесь. Просто подключаем вот этот репозиторий https://launchpad.net/
nutznboltz/+archive/kvm-libvirt-lts после чего устанавливаем свежие версии libvirt и kvm
# echo «deb http://ppa.launchpad.net/nutznboltz/kvm-libvirt-lts/ubuntu lucid main» >> /etc/apt/sources.list.d/libvirt.list # echo «deb-src http://ppa.launchpad.net/nutznboltz/kvm-libvirt-lts/ubuntu» >> /etc/apt/sources.list.d/libvirt.list # aptitude update # aptitude install kvm libvirt-bin
Теперь мы имеем все необходимое что бы побаловать себя живой миграцией. Я не буду тут описывать как создается и настраивается виртуальная машина. Лучше сразу предположим, что она у нас есть. Пусть это будет Debian 6.0.1a, размещенный на Logical Volume с именем «debian», соответственно путь до данного раздела у нас /dev/vg/debian, хотя это итак понятно. Итак на vm1 у нас виртуальная машина с именем «debian6» и мы ее сейчас будет мигрировать. Живая миграция требовательна к нюансам. Окружение вирутальной машины должно полностью совпадать у источника и приемника данной машины. Например, если виртуалкой используется раздел /dev/vg/debian, но на целевой системе этот раздел должен присутствовать. Если к машине подключены ISO образы, то и на целевой машине они так же должны быть, и по тому же самому пути, а лучше ISO образы вообще отключить на время миграции. Тоже самое и с сетевыми настройками: названия бриджа в который подключена виртуалка должны совпадать на источнике и приемнике. Вообщем капризная эта KVM, но если вы хотите живую миграцию — будьте так любезны. Допустим мы отключили все ISO и бридж приемника у нас имеет тоже самое название, теперь сделаем так, что бы root одной машины мог безприпятственно заходить по SSH в качестве root другой машины. Это вообщем то не обязательно, тем не менее желательно. По умолчанию пароль root в Ubuntu отсутствует, поэтому будем использовать ключи SSH. Для этого делаем следующее.
Обращаю пристальное внимание на то, что команды выполняются НА РАЗНЫХ машинах vm1 и vm2, если объяснить по простому, то мы просто генерируем SSH RSA ключ для пользователя root на машине vm1, после чего инсталируем его пользователю «user» машины vm2, а дальше на машине vm2 переносим последний добавленный ключ пользователя user, пользователю root. После этой процедуры пользователь root с vm1 будет входить по SSH как root@vm2 без запроса пароля. Такую же операцию проделываем и в обратную сторону. Теперь смотрим на нашу запущенную виртуалку на vm1
[vm1]# virsh list ID Имя Статус ———————————- 1 Debian6 выполнение
Значит машина запущена и работает, создаем на vm2 раздел того же размера что ни на vm1 и называем его так же, тоесть «debian», пусть у нас образ будет 8 Gb, на обеих хостах vm1 и vm2. Важно что бы раздел в который мигрирует виртаульная машина не был МЕНЬШЕ исходного.
После чего можно начать миграцию
[vm1]# virsh migrate —live Debian6 qemu+ssh://root@vm2/system —copy-storage-all
Сразу скажу что переносимая виртуалка в процессе миграции резко теряет свою отзывчивость, и сеть между двумя хостами серьезно загружается. Так что имейте это в виду. Данная команда говорит о том что необходимо мигрировать, причем в живую (ключь —live), виртуалку с именем Debian6, и скопировать хранилище на удаленную машину (—copy-storage-all), если хранилище уже есть на хосте и достаточно свежо, то вместо копирования всего раздела, можно указать команду (—copy-storage-inc) и копирование будет инкиментальное, тоесть будет передана только измененная часть хранилища, что может существенно сэкономить время. Очень важно, так же не забыть ключь —live, потому как без него, система будет приостановлена, и запущена после миграции на другой системе. Вот собственно и вся наука.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.