oVirt self-hosted engine workaround

В текущих версиях oVirt нет self-hosted engine (фича запланированна на v3.4), но можно сделать некое подобие, реализующие те же функции: ovirt-engine крутится в качестве виртуалки на тех же нодах, что предназначены для самого ovirt-а, при падении ноды - engine перезапускается на другой ноде и восстанавливает нормальную работу кластера.
Пример use-case: блейд-шасси с одинаковыми мощными блейдами и общим схд, других серверов или даже ПК нет. В подобной ситуации несколько стремно отдавать целый блейд только под ovirt-engine, а если учесть необходимую отказоустойчивость - то и все два. Поэтому нужно чтобы engine был виртуальной машиной, которая крутится на тех же блейдах-нодах, что выделены в кластер в самом ovirt-e.
Решение построено на использовании pacemaker-кластера для хостинга виртуалки с ovirt-engine и адаптацию его работы вместе с vdsm-ом, который необходим для работы нод ovirt-а.

Вышел oVirt 3.3

Кто еще не в курсе, 16.09.2013 вышел oVirt 3.3. Пофикшено множество багов, добавлено много вкусных фич.
Особо радует следующее:

• noVNC-консоль. Огромный плюс - больше не нужно ставить что-либо для подключения к консоли виртуалок (особенно на винде, где нет простого spice-xpi расширения к FF)
• Migration network. Тоже решает одну из серьезных проблем - теперь при массовой миграции с нагруженного хоста (например, при выводе хоста в maintenance) можно не опасаться "отвала" хоста от engine с последующим ребутом и крахом всего и всея. Естественно, польза от этого есть только при наличии отдельного физического сетевого интерфейса (благо на современных блейдах/серваках уже пихают по 4+ интерфейсов).
• Virtual Disk resize. Правда это не "resize", а только "extend", но работает как заявленно - можно увеличить диск виртуалки "на лету", не останавливая ее. До 3.3 менять размер уже созданного виртуального диска вообще нельзя было.

Есть правда и косяки (куда же без них), например заявленная фича Manage Storage Connections по-факту в релиз не вошла.
Upgrade с 3.2.2 до 3.3 весьма прост - добавить новый репозиторий с релизом, заапдейтить через yum пакет ovirt-engine-setup и запустить engine-setup. Установщик сам обнаружит работающий овирт, проведет бэкап БД и произведет апдейт.

Кластер postgresql с pgpool

Небольшая хаутушечка по настройке pgpool-кластера с steaming replication postgres.

Виртуалки из шаблонов и DDNS

Практически в любой полноценной системе виртуализации есть весьма удобная фича - шаблоны, которые позволяют развертывать большое количество виртуалок с минимальными телодвижениями. Но, как правило, после запуска подобных "клонированных"  виртуалок требуется их донастройка - имя хоста, пароли, настройки сети и т.п. (механизм sysprep для винды и /.unconfigured для rhel/centos/fedora и подобные).
А как развернуть 100500 linux-based виртуалок, которые различаются только именем хоста и сетевыми настройками, быстро да без пользовательского участия? Решение для oVirt под катом.

Импорт виртуалок в oVirt и timezone

При импорте виртуалок в oVirt 3.2.2 (stable) через virt-v2v+export domain, у них устанавливается timezone=«GMT-12», причем поменять ее из веб-интерфейса нельзя. Это связано с багом в engine (тыц, фикс будет в 3.3.0), что приводит к ругани на даты в будущем от fsck в guest-системе и прочим проблемам с датой.
Обойти можно, если напрямую в БД изменить time_zone на желаемую:

update vm_static set time_zone='Etc/GMT' where vm_name='VMNAME';
commit;

VM в pacemaker-кластере

Виртуалка в кластере - один из простых способов обеспечить отказоустойчивость сервиса, когда полноценные среды HA-виртуализации еще overkill, а отдельные хосты/скрипты/ручная работа уже не годится. В частности, если разворачивать oVirt, то его engine должен быть вне датацентра, а по-хорошему его тоже необходимо сделать высокодоступным, чтобы не лешиться управления средой виртуализации в критический момент.
Я опишу связку cman+pacemaker, т.к. она практически нигде не освещена, но только она под centos/rhel6 со стандартными rpm-ками позволяет использовать gfs2 и кучу ресурсов из heartbear/pacemaker (ocf:heartbeat:Route, в частности), которых нет в redhat cluster suite.

Запуск VM в EL6-based ovirt 3.2.1

21 марта команда oVirt объявила о выпуске беты ovirt 3.2.1 под EL6 платформу, т.е. rhel/centos будет официально поддерживаться ovirt-ом и можно потихоньку отказываться от репозиториия dreyou (что, однако, не умоляет всех его заслуг перед сообществом).
Однако, во всем есть своя ложка дегтя: если engine поставлен из этого репозитория (или федоровского), а так же хост-система на базе EL6 - "из коробки" в такой связке ни одна виртуалка запуститься не сможет, запуск фейлится с ошибкой "libvirtError: internal error process exited while connecting to monitor: Supported machines are:". Детали этой проблемы можно посмотреть в багзилле, а пока есть довольно простой workaround: запустить на машине-engine "engine-config -s EmulatedMachine=pc --cver=3.2 && service ovirt-engine restart".

spice-консоль в ovirt 3.2

В целом документация на сайте ovirt-а содержит инструкции использованию spice-консоли, но там не освещена одна важная деталь, а так же есть несколько абсолютно лишних (на мой взгляд) действий. Кому интересно, прошу под кат.

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

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

spacewalk 1.9

5 марта вышел spacewalk 1.9 . Ура-ура и т.п.
Только не спешите обновляться, т.к. функционал кикстарта поломан: gpg-ключи не добавляются в kickstart-профиль, в результате в новые системы не ставится софт из-за "nosig key not installed". Бага зафиксирована, даже есть фикс, но в основном репозитории 1.9 еще рпмки без фикса.

Админский тестовый стенд

Началось все с того,  что захотелось мне получить сертификат RHCDS, благо RHCE уже есть, а с большинством из требуемых технологий имел знакомство или даже опыт использования в продакшне. Из требований к этой сертификации можно увидеть, что необходимо разбираться в Sattelite/Spacewalk-е, RHDS, GFS, Cluster, RHEV/oVirt. И если с первыми тремя вполне можно играться на виртуалках, то с кластером/виртуализацией на обычном "домашнем" железе особо не поковыряться.
Поскольку начальство жмется за каждую копейку, то вопрос о покупке какого-либо оборудования просто на "поиграться" "изучение новых технологий" для админского отдела даже не стоит. Имеющееся оборудование уже используется в боевом режиме и лишнего нет, а из неиспользованого старья нет ничего с поддержкой аппаратной виртуализации и/или ipmi.
Посему - в жопу всех, будем строить свой лунапарк у себя дома. Конечно, раз это домашнее предприятие - производительность оборудования будет на последнем месте, а на первых - поддержка необходимых технологий, минимальная цена и уровень шума.