ovirt машины не мигрируют при падении одной из нод

Вручную миграция работает?
Что в логах?

Да да, вручную миграция работает. Более того если одну из нод перевести Maintenance все проходит гладко хосты без проблем переезжают.
В логах что то вроде этого
Host NODE-1 is responsive VM GIT-1 was set to the Unknown status VM test2 was set to the Unknown status VM 3W-1 was set to the Unknown status VM test1 was set to the Unknown status

Engine проксирует fence через один из доступных хостов. В логах и даже в эвентах в гуе должно быть написано о попытке это сделать и о результатах. В логе vdsm на живом хосте можно найти запущенную команду ipmi и ее результат

Спасибо, dyasny
Логи я почистила сейчас. Смогу продолжить эксперименты сегодня вечером...
Выходные проводила испытания на отказ, не знаю на сколько это значимо, хочу поделиться результатами.
Есть два хранилища, GlusterFS и DATA\NFS.

1. Если выключить ноду, то VM на DATA\NFS тут же перезапускаются, в логах GUI видно, как ipmi поймал статус DOWN для ноды, потом посылал ее сообщения на POWER ON. Тоже и с REBOOT, логи пишут, что машина в ребуте VM'ы со знаком вопроса и статусом «VM test2 was set to the Unknown status» после ребута снова все работает.Во время ребута, перезапуск машин не происходит как при poweroff
2. VM на GlusterFS ведут себя по другому:( есть два кирпича в реплике один на одной ноде другой на другой. Так вот, что reboot, что poweroff вешает виртуалки на паузу и все попытки run ничего не даеют. В логах GUI ничего. Остается только выключить и включить VM. Но включить можно только когда вторая нода вернется, т.к. Storage DATA GlusterFS тоже падает, но не всегда.
3. Если отключить сеть (на каждой ноде три интерфейса один выделенный ipmi, два обычных собранные в bond). Так вот если потушить bond, то не зависимо от хранилища все виртуалки висят со статусом «VM test2 was set to the Unknown status» и каждые две минуты «Host node-1 is not respinding. It will stay in Connecting state for a grace period of 122 seconds and after that an attempt to fence the host will be issued»

Буду рада любым вашим комментариям. По логам отпишусь чуть позже

Скажите пожалуйста, а как отключить DEBUG в логах vdsm.log там такой срач, каждую минуту по 100 строк

P.S. Еще раз спасибо, dyasny, за подсказку

1. При reboot, скорее всего считается что быстрее дождаться возвращения хоста чем грузить другие хосты лишними VM.

2. GlusterFS, Ceph и прочие такие системы плохо работают когда хостов менее трех. VM уходит в паузу в двух случаях - ENOSPACE и EIO, т.е. если qemu ловит нехватку места или i/o ошибку. Скорее всего доступ к gluster отваливается при падении одного из двух кирпичей

3. С т.з. системы, когда хост перестает отвечать, он мог остаться живым и с включенными VM, но без сетевого доступа к engine. В таком случае система ждет что хост вернется (особенно если IPMI говорит что он включен), потому что убивать его через IPMI, слишком быстро не есть хорошо - а вдруг просто свич ребутнулся и виртуалки могут обойтись без даунтайма, т.к. хост вот вот появится в сети. Через определенное время «122 seconds» хост получит контрольный в голову через IPMI и все HA виртуалки будут перезапущены.

debug в vdsm не стоит отключать, а то отследить потоки будет невозможно. Да их сложно ковырять, но ничего невозможного в этом нет. Особенно если использовать event ID и Thread number

1. Я тоже так подумала, но решила уточнить у специалистов)
2. А как же быть? Может быть я сделаю еще одну машину с кирпичем? Но это придется делать из консоли gluster, т.к. ovirt позволяет делать это только на нодах, а третью ноду, у меня серверного железа не хватит
3. Да, я тоже так подумала и ждала почти час пока он все таки что то предпримет... Он ничего не запустил не перезапустил, только валил сообщения каждые 2 минуты «Host node-1 is not respinding. It will stay in Connecting state for a grace period of 122 seconds and after that an attempt to fence the host will be issued»

debug не буду, спасибо

2. Для начала, gluster и vdsm на одном и том же хосте вроде как не поддерживаются, и делать так нельзя. Можно наделать много глупостей. Так что гластер надо вынести на как минимум 3 отдельных хоста, или не использовать вообще

3. а вот это уже похоже на баг, он должен был выслать ему fence через две минуты. багрепорт можно скинуть на users@ovirt.org

Мне кажется я делаю много глупостей из-за отсутствия фундаментальных знаний. Если не затруднит, можно ссылку на rtfm? Мой первый гайд серия роликов на youtube.com «Евгений Деревянкин oVirt» ну и офф.сайт конечно. Кстати, в этом выпуске Евгений как раз запускает gluster на нодах с машинами и у него все чудесно работает :(

я больше ориентируюсь на RHEV, а там это пока что не поддерживается официально, что обычно означает нестабильность такого подхода, даже если это технически возможно.

когда используешь такие системы как RHEV/oVirt, все таки ориентируешься на серьезную работу, где даунтайм на ровном месте недопустим. Поэтому использовать неподдерживаемое решение == поиск приключений на известное место