Сборник грабелек ovirt 3.2

В ходе тестов, экспериментов и эксплуатации ovirt собрал уже множество мелких грабелек или просто неясностей и путей их обхода. Этим небольшим знанием и хочу поделиться.

1. Power Management / Fence

В ovirt 3.1 engine не передает параметры fence-скрипту, в результате power-management нормально не работает (покрайней мере для методов, требующих передачи опций, drac5 с его cmd_prompt, например). Детали можно посмотреть тут.
Пофиксить можно патчем:
diff --git a/vdsm/BindingXMLRPC.py b/vdsm/BindingXMLRPC.py
index cc5300f..8b548e4 100644
--- a/vdsm/BindingXMLRPC.py
+++ b/vdsm/BindingXMLRPC.py
@@ -357,7 +357,7 @@ class BindingXMLRPC(object):
secure=False, options=''):
api = API.Global()
return api.fenceNode(addr, port, agent, username, password,
- action, secure)
+ action, secure, options)

def setLogLevel(self, level):
api = API.Global()

В ovirt 3.2 эта проблема уже пофикшена.

2. Dell power management

Не совсем очевидна настройка управления питанием для делловского оборудования (drac5-агент). Подробное описание настройки fence_drac5 можно почитать тут.
В кратце, в реалиях ovirt, это сводится к следующему:

• заходим по telnet/ssh (смотря что включено в drac) под юзером, имеющим права на управление питанием, смотрим и копируем приглашение коммандной строки (для дефолтного рута это "admin1->")
• в ovirt-e на странице power management-а для хоста выбираем drac5, вводим логин/пароль, в option - вставляем "cmd_prompt=admin1->" (без кавычек, admin1-> заменяем на приглашение из предыдущего пункта)
• если в drac включен ssh, ставим галку "secure"

3. Multipath

При добавлении хоста в ovirt скрипт установки переписывает конфиг мультипасинга своим, что может быть нежелательным (в частности, делловский схд md3400fc требует своих секций в конфиге мультипасинга, иначе используется неправильный path checker и все пути объединяются в один пул, в результате пути до второго контроллера помечаются активными, но в реальности они не работают).

Решение - добавить "# RHEV PRIVATE" второй строкой в multipath.conf, тогда инсталл-скрипт полностью сохранит существующий конфиг.

4. Neworking

Добавление сети в конфигурацию хоста проваливается с ошибкой «specified netmask or gateway but not ip» (только для ovirt-а под centos из репозитория dreyou, в fedora-вском или RHEV такого бага нет)

 Решение: post-install скрипт в kickstart-е, который устанавливает vdsm, а затем reverse-patch-ит configNetwork.py (или ручками откатывать тот патч).

Добавление бонда обламывается с "There are no available Bonds":
сделать echo "+bondN" > /sys/class/net/bonding_masters , перезапустить vdsmd.

Сеть guest-систем не работает с bonding mode=6 (тыц), пофикшено только в ядре 3.8 - т.е. очень и очень нескоро в rhel/centos.
При выборе из списка bonding mode=5 (balance-tlb) передается только параметр mode=5, без установки miimon/arpmon, в результате получившийся bond не фиксирует падение линка на slave-интерфейсах (и нафига он тогда такой нужен). Обходное решение - выбирать custom mode, в параметры писать 'mode=5 miimon=80'.

5. Storage

Для расширения уже добавленного fc-стораджа:

• увеличить размер луна на схд
• вывести один из серваков в maintenance, ребутнуть его (чтобы определил новый размер луна, rescan_dm_devs, в частности для dell md3400 недостаточно)
• как только он станет "up" - необходимо перевести все остальные хосты в maintenance, дождаться перехода роли SPM на этот хост
• в консоли этого хоста сделать pvresize нужного multipath-устройства
• ребутнуть остальные хосты

Как видно из процедуры - фактически нереально увеличить сторедж без даунтайма, если только все виртуалки не влезут на один хост.

Возможности увеличить уже созданный диск виртуалки нет даже в планах на ovirt 3.3. Поэтому не забываем про lvm на linux-гестах.

6. Импорт vm

Для импорта виртуалок в ovirt используется утилита virt-v2v, понимает практически все форматы виртуалок (qemu, hyper-v, vmware, virtualbox), подробная документация есть на сайте redhat-а
В кратце (для импорта с kvm-хоста) процедура такая. Запустить на хосте virt-v2v. Виртуалка должна быть выключена
virt-v2v -o rhev -os 192.168.160.9:/opt/export/exportdomain --network vlan50 infr.teampass
-os - созданный export-domain в ovirt
--network - сеть, куда виртуалку включить
После завершения операции эта виртуалка появится в "vm import" закладке export-domain-а. Нужно выбрать и нажать import. При этом уже будет производится импорт в непосредственный сторадж.
Очень долгая операция, по-сути двойное полное копирование всего диска виртуалки, сначала в экспорт домен, затем в рабочий сторадж; и все это время виртуалка должна быть выключена.
В документации есть пример использования rest-api в ovirt-е, которым можно автоматизировать этот процесс и импортнуть, скажем, все виртуалки с хоста.

7. iSCSI

Если для iscsi используется multipath, то дефолтные таймауты при падении пути слишком большие, больше 2х минут - в результате, при падении одного из путей, пул отваливается, spm-хост принудительно ребутится и весь кластер нафиг заваливается.
Для решения проблемы нужно править аттрибуты в /etc/iscsi/iscsid.conf:
node.session.timeo.replacement_timeout
node.conn[0].timeo.noop_out_interval
node.conn[0].timeo.noop_out_timeout

8. Backup/Restore

Бэкап базы - скриптом /usr/share/ovirt-engine/dbscripts/backup.sh
Восстановление базы - сначала дропнуть существующую (если есть, флага -r в скрипте не достаточно), затем скриптом /usr/share/ovirt-engine/dbscripts/restore.sh
Бэкап файлов/конфигов - список есть тут: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Backing_up_and_restoring_Manager_configuration_files.html

Полная процедура восстановления:
- поставить ovirt-engine
- сделать engine-setup, ответы на вопросы давать такие же, как и при начальной установке
- остановить engine, service ovirt-engine stop
- распаковать конфиги из бэкапа
- залить базу из бэкапа: dropdb engine -U postgres -W; createdb -O engine -U postgres -W engine; /usr/share/ovirt-engine/dbscripts/restore.sh -r -u engine -d engine -f <filename.sql>