Миграция виртуальной машины kvm
Миграция виртуальных машин
При миграции виртуальной машины с локальным хранилищем копируется память и копируется диск. Форматы хранилища-источника и хранилища-приемника должны совпадать (RAW или Qcow2).
При миграции виртуальной машины с сетевым хранилищем копируется только память, а диск подключается к узлу кластера, на который осуществляется миграция. Виртуальная машина с сетевым диском при обычной миграции или миграции со статусом «остановлена» переносится, как правило, за несколько минут.
Типы миграции
Существует два типа миграции:
Алгоритм живой миграции виртуальной машины:
Алгоритм миграции остановленной виртуальной машины:
В случае живой миграции активно используемой виртуальной машины, процесс переноса может занимать продолжительное время и приводить к потере данных.
Живая миграция может быть прервана, если во время выполнения процесса переноса произойдет перезагрузка виртуальной машины. В таком случае миграция завершится, а виртуальная машина останется на исходном узле кластера.
Если ВМ находится в сетевом хранилище, при миграции её снапшоты будут удалены.
Запуск миграции
Нажмите Управление → Виртуальные машины → Миграция, чтобы мигрировать виртуальную машину.
Состояние миграции
После подтверждения указанных данных начинается процесс миграции. В статусе виртуальной машины появится иконка:
Отмена миграции виртуальной машины осуществляется по нажатию данной иконки.
Migration
Introduction
KVM currently supports savevm/loadvm and offline or live migration Migration commands are given when in qemu-monitor (Alt-Ctrl-2). Upon successful completion, the migrated VM continues to run on the destination host.
You can migrate a guest between an AMD host to an Intel host and back. Naturally, a 64-bit guest can only be migrated to a 64-bit host, but a 32-bit guest can be migrated at will.
Requirements
highlights / merits
1 These features are unique to KVM Live Migration as far as I know. If you know of other hypervisor that support any of them please update this page or let me (Uri) know.
User Interface
The user interface is through the qemu monitor (alt-ctrl-2 on the SDL window)
Management
The ‘-d’ will let you query the status of the migration.
With no ‘-d’ the monitor prompt returns when the migration completes. URI can be one of ‘exec: ‘ or tcp:
Status
Migration Parameters
Example / HOWTO
A is the source host, B is the destination host:
TCP example:
1. Start the VM on B with the exact same parameters as the VM on A, in migration-listen mode:
2. Start the migration (always on the source host):
3. Check the status (on A only):
Offline example:
1. unlimit bandwidth used for migration:
3. continue with either TCP or exec migration as described above.
Problems / Todo
savevm/loadvm to an external state file (using pseudo-migration)
more exec: options
Algorithm (the short version)
5. Continue the guest
Instructions for kvm-13 and below: MigrationQemu0.8.2.
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 для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Перенос виртуальной машины в 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. После установки всех устройств, систему лучше перезагрузить.
С виртуалками разобрались, но как быть с реальными машинами? Честно говоря не пробовал, но есть мнение что данный способ годиться и для реальных машин.
Перенос виртуальной машины VirtualBox в KVM
Сегодня рассмотрим пример переноса виртуальной машины с VirtualBox в KVM виртуализацию. Возможно, у вас есть несколько важных гостевых машин на VirtualBox. Вместо создания новых гостей KVM с такой же конфигурацией, вы можете легко перенести существующие виртуалки Virtualbox на KVM, как описано в это мануале.
Перенос виртуальных машин Virtualbox на виртуальные машины KVM на Linux
Отключите все виртуальные машины, размещенные на KVM и VirtualBox.
Далее необходимо зайти на VirtualBox и посмотреть какой диск использовался для хранения нашей виртуальной машины. Если динамический, то надо сделать его копию в статический vdi (я использую этот формат). Это можно сделать либо в графической морде VirtualBox, либо в командной строке:
Формат образа диска по умолчанию у виртуальной машины Virtualbox — VDI.
Мы можем найти список образов виртуальных дисков и их расположение с помощью команды:
Пример вывода:
Как видно из вывода у меня она виртуальная машина Virtualbox, расположенная по пути /home/user/VirtualBox VMs/ubnsrv_20.04/ubnsrv_20.04.vdi.
Теперь можно пойти двумя путями. Первый путь актуален для Windows виртуальных машин. Второй в большей степени для Linux:
Готовим систему Windows к переносу.
Выше я описывал как преобразовать диск из динамического в статический, назовем его static.vdi. Примонтируем его вместо динамического и удаляем VirtualBox Guest Tools.
Для успешной работы Windows необходимо иметь в наличии драйвера VirtIO для KVM. Скачиваем нужные с офф. сайта вот ссылка.
Рекомендуется сначала установить драйверы в гостевой системе, а уже после этого подключать или изменять устройства с целью использования паравиртуализированных драйверов. Для блочных устройств, на которых расположены корневые файловые системы или другие блочные устройства, необходимые для загрузки гостя, потребуется установить драйверы, прежде чем приступить к изменению настроек устройства.
Готовим систему Linux к переносу.
Преобразуем образа ubnsrv 20.04.vdi в формат необработанного диска с помощью команды «vboxmanage»:
Т.к. образ RAW является необработанным форматом диска (не сжатым), то он занимает много свободного пространства на вашем HDD/SSD.
Можете попробовать преобразовать формат VDI сразу в формат qcow2
Мы конвертировали нашу виртуальную машину из формата VDI, т.е. образа диска Virtualbox в формат образа KVM — qcow2.
Теперь вы можете импортировать образ диска на существующий компьютер KVM или создать новый экземпляр с этим вновь преобразованным образом диска KVM из командной строки или с помощью любых графических приложений управления KVM, таких как Virt-manager или веб-консоль Cockpit.
Если есть вопросы, то пишем в комментариях.
Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.