LINUX.ORG.RU
ФорумAdmin

Проблема live миграции виртуальной машины в KVM

 , ,


1

2

пытаюсь мигрировать виртуальную машину и на 99% вываливается ошибка: Migration: [ 99 %]error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: 2023-12-15T23:50:33.462543Z qemu-system-x86_64: Size mismatch: 0000:00:02.0:00.0/e1000e.rom: 0x80000 != 0x40000: Invalid argument 2023-12-15T23:50:33.462630Z qemu-system-x86_64: error while loading state for instance 0x0 of device ‘ram’ 2023-12-15T23:50:33.463580Z qemu-system-x86_64: load of migration failed: Invalid argument пробовал несколько раз - одно и то же… пробовал пересоздавать виртуалку… гугление результатов не дало… с гипервизоров на debian виртуалки туда сюда хорошо летают, а вот понадобилось с mint виртуалку мигрировать на debian и ни в какую, виртуалка весит много, поэтому нет возможности перенести оффлайн, т.к. время простоя будет большое

На правах телепата:
Сеть у виртуалки e1000e? Смени на virtio.

find / -type f -name e1000e.rom на целевом хосте скорее всего ничего не найдет, а оно должно там быть для запуска твоей виртуалки после миграции. Пакеты ipxe-qemu тоже крайне желательны одинаковых версий (что маловероятно соблюсти при миграции с mint на debian ).

BOOBLIK ★★★
()
Последнее исправление: BOOBLIK (всего исправлений: 2)

Для Live migration тебе всё равно нужно общее хранилище, а раз так, то какая разница, сколько весит виртуалка.

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

Короче, раз у тебя всё равно общее хранилище, то в чём проблема сделать миграцию через выключение на одном хосте и тут же включения на другом?

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

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

вариант перетащить внешний винт и подключить к серваку тоже не катит - там юзб 2.0

нужна миграция

holenet
() автор топика
Ответ на: комментарий от holenet

Смотри.

У тебя есть сервер 1. На нём крутится виртуалка. Она лежит в /mnt/где-то-тут.

У тебя есть сервер 2. На нём минт и ничего нет. Создаёшь /где-то-там каталог. Экспортируешь его по NFS.

На сервере 1 монтируешь server2:/где-то-там в /remote/где-то-там. Используя virsh, запускаешь живую миграцию хранилища из локального каталога /mnt/где-то-тут в локальный каталог /remote/где-то-там. На самом деле миграция будет производиться по сети, но виртуалке об этом знать не обязательно.

Некоторое время виртуалка будет работать в режиме — память и процессор на сервере 1, диск на сервере 2. С гигабитной сетью это не должно стать проблемой.

Потом, на сервере 2 создаешь виртуалку с такими же параметрами, что и на сервере 1, можно просто XML скопировать, даже маки не менять. И после выключения виртуалки на сервере 1 запускать её на сервере 2.

Если же сеть не позволяет таких фокусов, тогда ой.

Aceler ★★★★★
()
Ответ на: комментарий от holenet

Как это сделать через virsh я не знаю. Через PVE это делается в интерфейсе виртуалки, следовательно KVM это поддерживает, следовательно virsh это тоже должен уметь. Поищи в документации.

Я нагуглил, что у virsh есть команда blockcopy, которая делает это, но тебе лучше сначала потренироваться на кошках.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

в итоге:

нашёл комп с юзб 3.0, накатил debian, поставил kvm, подрубил к нему винт быстро стартанул виртуалку и запустил лайв миграцию

за ночь улетела

получается разные системы не совместимы при лайв миграции, видимо из-за разных пакетов

holenet
() автор топика