Удаляем виртуальную машину в proxmox

Использование

Proxmox

Полученный iSCSI-таргет можно сразу-же подключить в Proxmox, не забыв снять галочку с Use LUN Directly.

Сразу после этого станет возможным создание LVM поверх него, не забудьте поставить галочку напротив shared:

Другие среды

Если вы планируете использовать это решение в другой среде возможно вам потребуется установить кластерное расширение для LVM на данный момент из существует две реализации. CLVM и lvmlockd.

Настройка CLVM не совесм тривиальна и требует работающего кластер менеджера.
Куда как второй метод lvmlockd — еще не до конца протестирован и только-только начинает появляться в стабильных репозиториях.

Рекомендую к прочтению отличную статью о блокировах в LVM

Proxmox VE. Полноценная платформа виртуализации

если у вас проблема типа:

Знайте, это из-за демократии. Но выход все же есть, и его пришлось искать долго.. Оказывается есть такая не документированная (лично я не нашел) команда:

После этого демократия превращается в монархию.И после этого можно спокойно удалять недоступную ноду.

a.dmin.pro/?p=3698Вывести список узлов кластера.

Если в ходе работы с резервным копирование или миграцией машина заблокирована и при старте отображается уведомление: Status Stop TASK ERROR: VM is locked (backup)Необходимо разблокировать VDS командой:

1191 номер вашего виртуального сервера, который разблокируем.

Восстановление конфигурации хранилища

После перезагрузки копируем из резервной копии файл storage.cfg:

cp -r /root/pve-backup/storage.cfg /etc/pve/

Открываем файл при помощи консольного редактора:

nano -w /etc/pve/storage.cfg

Если эта нода не являлась мастером, тогда удаляем все хранилища которые не содержать nodes , после чего на каждом хранилище удаляем эту строку.

Если нода являлась мастером, тогда удаляем все хранилища которы содержать nodes .

Копируем файлы файлы виртуальных машин, если Вы не собираетесь добавлять ноду в кластер:

cp -r /root/pve-backup/nodes//qemu-server/* /etc/pve/qemu-server/
cp -r /root/pve-backup/nodes//lxc/* /etc/pve/lxc/
cp -r /root/pve-backup/nodes//openvz/* /etc/pve/openvz/

Если вы собрались добавить ноду в кластер, тогда добавляем и в случае успешного добавления копируем виртуальные машины:

cp -r /root/pve-backup/nodes//qemu-server/* /etc/pve/nodes//qemu-server/
cp -r /root/pve-backup/nodes//lxc/* /etc/pve/nodes//lxc/
cp -r /root/pve-backup/nodes//openvz/* /etc/pve/nodes//openvz/

Открываем WEB-интерфейс, проверям наличие хранилища и виртуальных машин. 

Kernel panic — not syncing: Watchdog detected hard LOCKUP on cpu

Имитировали отказ одной ноды и выход её из «строя». Хотели увидеть как при вводе новой ноды с новым железом виртуальные машины KVM корректно работают на новой ноде.

При мощной нагрузке во время restore нода выдала Kernel panic — not syncing: Watchdog detected hard LOCKUP on cpu и сдохла. Единственное, что вменяемо описывало проблему это ресурс Red Hat access.redhat.com/knowledge/solutions/133803, что печалит. Проблема, которая задевает Red Hat Enterprise Linux 6.2 и, судя по постам в Интернете, даже ядра linux 3.

Кратко суть проблемы в том, что если на процессорах Интел с поддержкой «PAUSE-loop exiting» количество виртуальных процессоров больше реальных, то возможна эта напасть. В нашем случае MS Windows 2008 c 2 процессорами в своей виртуальной машине заставляла паниковать ядро ноды с 1 реальным процессором.

10.07.2012