Когда машина выходит из строя, восстановление требует нескольких хитростей как минимум 50% времени. Я использую Proxmox VE 5.4-13, и у меня произошел сбой машины, она была изолирована и т.д. Некоторые машины правильно мигрировали, но 3 находятся в "трудном" состоянии. Два экземпляра переместились на машину, которая даже не входит в определенный для них кластер HA. Один использует необработанное изображение (не синхронизировано), а другой — ceph (недоступен на этой машине). Один экземпляр на правильной машине, но не стартует (systemctl status pve-container@130.service): Код: 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: lxccontainer.c: wait_on_daemonized_start: 856 Нет такого файла или каталога — Не удалось получить состояние контейнера 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 330 Контейнер не удалось запустить 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 333 Чтобы получить больше деталей, запустите контейнер в фоновом режиме 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 336 Дополнительную информацию можно получить, установив параметры --logfile и --logpriority 19 мая 04:42:11 p3 systemd[1]: pve-container@130.service: Управляющий процесс завершился, код=выход, статус=1. Я хотел бы вернуть эти машины на машину, которая перезагрузилась, без синхронизации/перемещения образа диска (недоступен на одной машине и, возможно, не синхронизирован для машины номер 130 выше). 1. Есть идеи, как это сделать? [ИСПРВЛЕНО: Мне удалось переместить машину на основе CEPH без проблем, и мне удалось переместить машину на основе необработанного изображения, используя мою процедуру ниже. Я исправил машину на ZFS, запустив ее на сервере, на котором она находилась, после отключения HA. Любой ответ на этот вопрос все равно будет полезен для будущих сбоев]. 2. Есть идеи, почему машины переместились на сервер, не входящий в конфигурацию кластера HA (или как узнать, почему)? Вот процедура, которую я собрал в прошлом для машины с необработанным изображением в похожей ситуации, но я не могу применить её в этот раз, поскольку мне нужно исправить машины на ZFS, а не необработанную машину, которая совсем не синхронизирована: Процедура для перемещения ВМ с необработанным изображением обратно на оригинальный сервер без "синхронизации" изображения: ВМ107 была найдена на p1 или копия ее необработанного изображения была на /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw. Этот образ был меньше, чем изображение в том же месте на p5. Миграция на p1 не была настроена, неясно, как машина 107 была назначена на p1 (это произошло снова только что). Желательно было работать с ВМ107 на p5 с изображением, которое было на p5. Проблема заключалась в двух аспектах: миграция была невозможна, поскольку изображение на p5 блокировало, и в то же время это было желаемое изображение. Решение: - Переименовать /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw на обеих машинах (в /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw.org). - Создать /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw на p1, чтобы получить изображение размера 0, которое не начнется. - Через интерфейс Proxmox запросить миграцию на p5, что успешно, поскольку изображение больше не блокировало. - Имея изображение размера 0, миграция происходит почти мгновенно. - Машина не стартовала, на p5, переместить /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw.org на /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw. - Затем запросить успешный старт ВМ107 на p5.
"Миграция" без синхронизации диска (после изоляции узла), Proxmox Виртуальная Среда
|
19.05.2020 15:23:00
|
|
|
|
|
Читают тему
