Интересно (после очередной неудачной живой миграции):
Какие атрибуты (свойства) ВМ копируются из источника в место назначения при выполнении динамической миграции PVM?
В нашем случае фреймворк libvirt используется в кластере кардиостимуляторов.
В частности, меня интересует:
- назначения блочных устройств
- размер памяти
- количество виртуальных ЦП
- сети (вет)
- Модель процессора
Недавний сбой, который я видел, был следующим:
Устройство подкачки виртуальной машины было изменено с LVM LV на отдельный диск, поэтому новый диск был добавлен через заблокировать-прикрепить в то время как устаревший LV был удален в VM.
Конфигурации ВМ, которые использует кластер кардиостимуляторов, обновлялись на каждом узле (но у libvirt, похоже, есть свои копии в ОЗУ).
Виртуальная машина работала нормально, пока не была перенесена в реальном времени:
Были некоторые сообщения об ошибках, но виртуальная машина продолжала работать еще 40 минут, пока не перестала писать в журнал systemd.
На консоли я видел повторяющиеся сообщения вроде этих:
[94124.120477] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 232 с!
[94154.815980] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 263 с!
[94185.599474] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 293 с!
[94216.278977] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 324 с!
[94247.062530] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 355 с!
[94277.682031] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 386 с!
[94308.401531] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 416 с!
[94339.157047] ОШИБКА: блокировка рабочей очереди - пул ЦП = 0-1 флаги = 0x5 nice = 0 зависает на 447 с!
На самом деле в новой ВМ отсутствовал отдельный диск подкачки.
Но вместо паники (и перезагрузки) виртуальная машина, казалось, ждала чего-то, чего не произойдет.
После перезагрузки я нашел эти сообщения в журнале:
23 марта 20:02:19 v04 ядро: зависание процессов пользовательского пространства... (прошло 0,008 секунды) выполнено.
23 марта 20:02:19 Ядро v04: убийца OOM отключен.
23 марта 20:02:19 Ядро v04: замораживание оставшихся замораживаемых задач ... (прошло 0,001 секунды) выполнено.
23 марта 20:02:19 ядро v04: PM: зависание устройств завершается через 0,562 мс
23 марта 20:02:19 Ядро v04: приостановка xenstore...
23 марта 20:02:19 ядро v04: PM: позднее зависание устройств завершается через 0,104 мс
23 марта 20:02:19 ядро v04: PM: noirq зависание устройств завершено через 13,428 мс
23 марта 20:02:19 ядро v04: xen:grant_table: предоставить таблицы с использованием макета версии 1
23 марта 20:02:19 Ядро v04: приостановлено на 1,170 секунды
23 марта 20:02:19 ядро v04: PM: noirq восстановление устройств завершено через 0,166 мс
23 марта 20:02:19 ядро v04: PM: раннее восстановление устройств завершается через 0,085 мс
23 марта 20:02:19 ядро v04: vbd vbd-51744: 2 чтение других сведений о конце из устройства / vbd / 51744
23 марта 20:02:19 Ядро v04: xenbus: возобновить (поговорить_с_другим) vbd-51744 не удалось: -2
23 марта 20:02:19 Ядро v04: dpm_run_callback(): xenbus_dev_resume+0x0/0x130 возвращает -2
23 марта 20:02:19 ядро v04: PM: устройство vbd-51744 не удалось восстановить: ошибка -2
23 марта 20:02:19 ядро v04: PM: восстановление устройств завершено через 9,374 мс
23 марта 20:02:19 Ядро v04: включен убийца OOM.
23 марта 20:02:19 ядро v04: перезапуск задач ... сделано.
...
23 марта 20:40:26 v04 systemd-logind[1034]: не удалось запустить область сеанса session-117.scope: время ожидания подключения истекло
-- Перезагрузить --
Таким же образом предположим, что я расширил оперативную память виртуальной машины во время ее работы.
Исчезнет ли ОЗУ после живой миграции или настройки ОЗУ будут «скопированы»?
