Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе RELS 6.6

Большая часть наших статей в «Точке Росы» была посвящена нашим десктопным системам. Однако в последнее время мы более активно стараемся развивать и серверное направление. В связи с чем в августе нами была обучена группа специалистов одного очень известного и уважаемого системного интегратора.

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

И мы были рады, когда один из наших слушателей, Черятников Виталий, написал цикл статей «Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6» ([5], [6], [7], [8]).

C некоторыми правками, перепубликуем их и тут, одной статьей.

Материал в изложении Виталия преподнесен крайне интересно и правильно. Нам практически нечего к этому материалу добавить, настолько все толково изложено. Спасибо Виталию большое, за то, что он нашел время, написал и опубликовал данный цикл статей.

Содержание

1 Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6
2 Отказоустойчивая виртуализация на базе Ovirt 3.5
3 Интеграция oVirt 3.5 с Microsoft Active Directory

Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6

В рамках работ по одному проекту столкнулся с интересной вещью под названием Ovirt 3.5.3 — это некий аналог Virtual Machine Manager, но на мой взгляд он ближе по идеологии к vSphere, так как реализует механизмы failover и cluster на уровне продукта управления виртуализацией, а не ОС гипервизора (как HYPER-V Failover Cluster).

Базировалось всё на отечественной ROSA Enterprise Linux Server 6.6.

Сайт продукта
Документация
Архитектура
Инструкция администратора
Документ Инструкция администратора больше напоминает смесь из step-by-step guide и описания внутренних механизмов работы продукта.

Опыт интересен тем, что даёт некий аналог тяжёлым решениям VMWare и Microsoft в рамках импортозамещения. Ниже я коротко расскажу о установке продукта Ovirt в среде RELS с реализацией механизма аутентификации и авторизации на базе IPA, но хочу оговориться, что для меня данная реализация проекта на *nix — скорее экзотика, чем каждодневная реальность :), ибо Microsoft — наше всё, посему заранее прошу прощения за огрехи, если таковые допущу.

Коротко о выборе

Во-первых, почему IPA:

по информации от архитектора RELS, с которым мы работали, IPA — это основное направление для Red Hat Community в части аутентификации и авторизации. То есть продукт можно использовать в длительном периоде времени с расчётом на поддержку. Мне, как человеку, привыкшего работать с Active Directory понравился предлагаемый функционал и интерфейс (конечно везде есть отличия, но всё же);
IPA — полноценное продуктивное решение с очень неплохим уровнем документированности; Лично я, для прояснения многих аспектов использовал официальную документацию Red Hat
IPA позволяет использовать динамический DNS сервер и формировать SSO окружение клиент-сервер — легко;
Это рекомендованное решение для интеграции с Ovirt 3.5;
А, и конечно, фраза, которую любят говорить *nix’оводы: оно уже входит в дистрибутив RELS и поддерживается командой ROSA.

Во-вторых, выбор платформы реализации серверной инфраструктуры:

Выбор производился между сертифицированными ФСТЭК отечественными ОС (для справки, существуют: МСВС Линукс, Astra Linux — крайне закрытые платформы, на мой субъективный взгляд; ALT Linux — известен многим и достаточно неплох);
RELS понравился дружелюбием к системам в окружающем мире при интеграции;
Активная жизненная позиция команды разработчиков :), в частности Константина Калмыкова;
RELS использует KVM для виртуализации.

В-третьих, управление виртуализацией, и да, опять — Ovirt 3.5 входит в состав ROSA Linux и так же, как и сам RELS, поддерживается командой разработчиков.

Установка IPA

Выполняем обновление пакетов

# yum update

Поскольку мы планируем использование Kerberos рекомендую предварительно поднять NTP сервер в сети и настроить иерархию получения точного времени (либо следить за часами).

Установим BIND (в моей конфигурации я использую службу имен там же, где и служба каталогов), плюс плагин к нему, который реализует запись содержимого зон в службу каталога.

# yum install bind-dyndb-ldap bind

если столкнётесь с Warning на скриншоте ниже — не обращайте внимания (насколько я понял — стандартное предупреждение).

Затем установим сам IPA сервер:

# yum install ipa-server

После установки пакетов я проверяю содержимое /etc/hosts (это необходимое условие для работы IPA сервера).

В моем случае это выглядит так:

127.0.0.1     localhost localhost.localdomain localhost4 localhost4.localdomain4
::1           localhost localhost.localdomain localhost6 localhost6.localdomain6 
10.5.102.167  ipa01.rosa.demo ipa01

Перед установкой IPA сервера убедитесь, что hostname сервера у Вас задано строчными буквами, см. скриншот ниже — иначе система ругается.

Если Вы устанавливаете IPA сервер первый раз, то используйте команду:

# sudo ipa-server-install --setup-dns

Далее вы получите следующий вывод с интерактивным диалогом:

The log file for this installation can be found in /var/log/ipaserver-install.log ==============================================================================

This program will set up the IPA Server.

 This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)
  * Configure DNS (bind)
 
To accept the default shown in brackets, press the Enter key.
Existing BIND configuration detected, overwrite? [no]: yes
Enter the fully qualified domain name of the computer on which you’re setting up server software. Using the form <hostname>.<domainname>
Example: master.example.com.
Server host name [ipa01.rosa.demo]:
Warning: skipping DNS resolution of host ipa01.rosa.demo The domain name has been determined based on the host name.
Please confirm the domain name [rosa.demo]:
The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.
Please provide a realm name [ROSA.DEMO]:
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access to the Directory for system management tasks and will be added to the instance of directory server created for IPA.
The password must be at least 8 characters long.
Directory Manager password:
Password (confirm):
The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.
IPA admin password:
Password (confirm):
Do you want to configure DNS forwarders? [yes]:
Enter the IP address of DNS forwarder to use, or press Enter to finish.
Enter IP address for a DNS forwarder: 10.5.102.2 DNS forwarder 10.5.102.2 added
Enter IP address for a DNS forwarder:
Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [102.5.10.in-addr.arpa.]:
Using reverse zone 102.5.10.in-addr.arpa.
The IPA Master Server will be configured with:
Hostname: ipa01.rosa.demo
IP address: 10.5.102.167
Domain name: rosa.demo
Realm name: ROSA.DEMO
BIND DNS server will be configured to serve IPA domain with:
Forwarders: 10.5.102.2
Reverse zone: 102.5.10.in-addr.arpa.
Continue to configure the system with these values? [no]: yes
The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
  [1/21]: creating certificate server user
  [2/21]: creating pki-ca instance
  [3/21]: configuring certificate server instance
  [4/21]: disabling nonces
  [5/21]: creating CA agent PKCS#12 file in /root
  [6/21]: creating RA agent certificate database
  [7/21]: importing CA chain to RA certificate database
  [8/21]: fixing RA database permissions
  [9/21]: setting up signing cert profile
  [10/21]: set up CRL publishing
  [11/21]: set certificate subject base
  [12/21]: enabling Subject Key Identifier
  [13/21]: setting audit signing renewal to 2 years
  [14/21]: configuring certificate server to start on boot
  [15/21]: restarting certificate server
  [16/21]: requesting RA certificate from CA
  [17/21]: issuing RA agent certificate
  [18/21]: adding RA agent as a trusted user
  [19/21]: configure certificate renewals
  [20/21]: configure Server-Cert certificate renewal
  [21/21]: Configure HTTP to proxy connections Done configuring certificate server (pki-cad).
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/38]: creating directory server user
  [2/38]: creating directory server instance
  [3/38]: adding default schema
  [4/38]: enabling memberof plugin
  [5/38]: enabling winsync plugin
  [6/38]: configuring replication version plugin
  [7/38]: enabling IPA enrollment plugin
  [8/38]: enabling ldapi
  [9/38]: disabling betxn plugins
  [10/38]: configuring uniqueness plugin
  [11/38]: configuring uuid plugin
  [12/38]: configuring modrdn plugin
  [13/38]: enabling entryUSN plugin
  [14/38]: configuring lockout plugin
  [15/38]: creating indices
  [16/38]: enabling referential integrity plugin
  [17/38]: configuring ssl for ds instance
  [18/38]: configuring certmap.conf
  [19/38]: configure autobind for root
  [20/38]: configure new location for managed entries
  [21/38]: restarting directory server
  [22/38]: adding default layout
  [23/38]: adding delegation layout
  [24/38]: adding replication acis
  [25/38]: creating container for managed entries
  [26/38]: configuring user private groups
  [27/38]: configuring netgroups from hostgroups
  [28/38]: creating default Sudo bind user
  [29/38]: creating default Auto Member layout
  [30/38]: adding range check plugin
  [31/38]: creating default HBAC rule allow_all
  [32/38]: Upload CA cert to the directory
  [33/38]: initializing group membership
  [34/38]: adding master entry
  [35/38]: configuring Posix uid/gid generation
  [36/38]: enabling compatibility plugin
  [37/38]: tuning directory server
  [38/38]: configuring directory to start on boot Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
  [1/10]: adding sasl mappings to the directory
  [2/10]: adding kerberos container to the directory
  [3/10]: configuring KDC
  [4/10]: initialize kerberos container
  [5/10]: adding default ACIs
  [6/10]: creating a keytab for the directory
  [7/10]: creating a keytab for the machine
  [8/10]: adding the password extension to the directory
  [9/10]: starting the KDC
  [10/10]: configuring KDC to start on boot Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
  [1/2]: starting kadmin
  [2/2]: configuring kadmin to start on boot Done configuring kadmin.
Configuring ipa_memcached
  [1/2]: starting ipa_memcached
  [2/2]: configuring ipa_memcached to start on boot Done configuring ipa_memcached.
Configuring the web interface (httpd): Estimated time 1 minute
  [1/13]: setting mod_nss port to 443
  [2/13]: setting mod_nss password file
  [3/13]: enabling mod_nss renegotiate
  [4/13]: adding URL rewriting rules
  [5/13]: configuring httpd
  [6/13]: setting up ssl
  [7/13]: setting up browser autoconfig
  [8/13]: publish CA cert
  [9/13]: creating a keytab for httpd
  [10/13]: clean up any existing httpd ccache
  [11/13]: configuring SELinux for httpd
  [12/13]: restarting httpd
  [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Configuring DNS (named)
  [1/9]: adding DNS container
  [2/9]: setting up our zone
  [3/9]: setting up reverse zone
  [4/9]: setting up our own record
  [5/9]: setting up kerberos principal
  [6/9]: setting up named.conf
  [7/9]: restarting named
  [8/9]: configuring named to start on boot
  [9/9]: changing resolv.conf to point to ourselves Done configuring DNS (named).
 
Global DNS configuration in LDAP server is empty You can use 'dnsconfig-mod' command to set global DNS options that would override settings in local named.conf files
 
Restarting the web server

=============================================================================  =============================================================================
Setup complete
 
Next steps:
                1. You must make sure these network ports are open:
                               TCP Ports:
                                 * 80, 443: HTTP/HTTPS
                                 * 389, 636: LDAP/LDAPS
                                 * 88, 464: kerberos
                                 * 53: bind
                               UDP Ports:
                                 * 88, 464: kerberos
                                 * 53: bind
                                 * 123: ntp
 
                2. You can now obtain a kerberos ticket using the command: 'kinit admin'
                   This ticket will allow you to use the IPA tools (e.g., ipa user-add)
                   and the web user interface.
 
Be sure to back up the CA certificate stored in /root/cacert.p12 This file is required to create replicas. The password for this file is the Directory Manager password

Затем откройте браузер и соединитесь с узлом, на котором развернут IPA сервер по HTTP или HTTPS. Теперь можно работать со службой каталогов.

Как видите, DNS сервер в IPA самостоятельно и корректно делает записи типа SRV (аналогично А, PTR).

Добавляем рядовой сервер в домен:

# ipa-client-install --no-nisdomain --enable-dns-updates --server ipa01.rosa.demo --domain rosa.demo --realm ROSA.DEMO

ПРИМЕЧАНИЕ!: Поскольку данный пример делался на стенде с одним сервером IPA строка не имела значения — я предпочёл настроить на конкретный сервер; однако для обеспечения failover клиента ipa на резервный сервер службы, в случае выхода из строя мастер-сервера службы каталогов, требуется другая конфигурация (о чём говорит сообщение на скриншоте).

После добавления рядового сервера в домен, командой ниже, необходимые записи так же появились в службе каталога. На скриншоте выше см. IPv4 10.5.102.168 и FQDN в зоне прямого просмотра ovi01.rosa.demo

Установка Ovirt 3.5

Перед развёртыванием Ovirt на сервере RELS 6.6 запустите

# yum update

Далее выполните команду загрузки из репозитария

# yum install ovirt-engine -y

После выполните команду настройки и пройдите все пункты мастера #engine-setup

Перед подтверждением конфигурации к установке Вы увидите следующий диалог:

Подтверждаем и ожидаем окончания установки

Интеграция Ovirt 3.5 с IPA Server

Теперь необходимо выполнить команду интеграции Ovirt 3.5 со службой каталога IPA.

ПРИМЕЧАНИЕ!: Данная версия Ovirt имеет только одного локального пользователя — admin (создание других локальных пользователей не предусмотрено).

Всех остальных пользователей она получает из службы каталога (кстати есть возможность интеграции и с Microsoft Active Directory — расскажу о нюансах в другой статье цикла).

В ситуации по-умолчанию Вы получите ошибку ниже:

Дело в том, что, по-умолчанию, OVirt 3.5 требует значение равное 1 параметра minssf сервера IPA, собственно сервер IPA, после установки, имеет значение параметра равное 0.

Останавливаем службу IPA

# service ipa stop

Меняем это значение на сервере IPA в файле /etc/dirsrv/slapd-ROSA-DEMO/dse.ldif и перезапускаем службы, используя команду

# service ipa start

После этого повторяем попытку интеграции.

Как Вы видите, на предыдущем скриншоте, повторная попытка добавления прошла вполне успешно и нам надо будет перезапустить службу ovirt-engine. Далее выполняем вход в систему с учётной записью администратора Ovirt имеет достаточно развитую внутреннюю RBAC модель, а так же возможность создания новых ролей.

Теперь мы можем добавить пользователя в роль в Ovirt и выполнить вход в систему управления виртуализацией, используя портал пользователя.

Вводим учётные данные пользователя, который входит в группу [mailto: virtualization_admins@rosa.demo virtualization_admins@rosa.demo]

Добро пожаловать на портал само-обслуживания пользователя Ovirt, с правами по-умолчанию для роли UserRole.

Дальше будет, как добавить сервера виртуализации в Ovirt, а так же пройдёмся по механизмам реализации отказоустойчивости кластеров и виртуальным сетям.

Отказоустойчивая виртуализация на базе Ovirt 3.5

Рассмотрим вопрос построения отказоустойчивой виртуализации на базе Ovirt 3.5, рассмотрим основные механизмы отработки отказа узла кластера.

Многие из нас знакомы с понятием High Availability в разрезе Microsoft Failover Cluster Services или VMWare HA — в Ovirt данный механизм так же существует.

Думаю, он понимаем достаточно легко, так же как и балансировка виртуальных машин, в зависимости от нагрузки (DRS в терминах VMWare и Dynamic Optimization в терминах Microsoft), существуют и Affinity Groups. Детально с реализацией механизмов можно ознакомиться в Admin Guide продукта, поэтому мы не будем детально обсуждать этот вопрос.

Отдельного упоминания заслуживают способы отработки отказа сервера-узла кластера виртуализации. Таких механизмов всего три:

Fencing^[1]: Данный термин используется в отношении физических узлов виртуализации с поддержкой удалённого управления;
Soft fencing over SSH: для сервиса агента VDSM;
Sanlock Fencing: с использованием общего хранилища.

Кластеры Ovirt, которые мы создаем в системе управления, так же используют единое и разделяемое хранилище данных (NFS, iSCSI, FC и прочие), так же должны иметь выделенные сети для производственной нагрузки и управления, а вот дальше начинаются нюансы.

Примечание редактора:

Возьмем на себя смелость немного уточнить изложенный ниже материал.

Для развертывания отказоустойчивого кластера oVirt использует ПО низкоуровневой поддержки оборудования (ipmitool). При установке хоста и добавлении его в кластер, система виртуализации сообщает о необходимости установить и настроить IPMI или его аналог.

При этом, нами отмечен забавный баг, а именно:

- при установке хоста в кластер, пакеты поддержки интерфейса IPMI устанавливаюся, но нужные модули ядра не подгружаются.
- следовательно, попытка сразу же настроить IPMI провалится при нажатии кнопочки "Test".

По этому мы рекомендуем:

- либо настраивайте управление питанием ПОСЛЕ добавления узла в кластер, а во время добавления узла в кластер от настройки Power Management откажитесь вовсе.

Для этого, естественно, требуется сперва перезагрузить хост (не забудьте сперва перевести хост кластера в режим обслуживания (Maintenance)).

- либо перед добавлением узла в кластер, самостоятельно произведите установку ipmitool (yum install ipmitool) и произведите загрузку необходимых модулей (modprobe ipmi_devintf и modprobe ipmi_si).

После этого спокойно устанавливаете ПО хоста, и добавляйте его в кластер. И тогда на конечном этапе добавления нового хоста в кластер, сработает настройка IPMI и его проверка кнопочкой "Test".

Конец примечания редактора

Host High Availability или Fencing

Основной механизм, который используется для реагирования кластера на сбой узла, в случае выхода его из строя (аппаратный или программный сбой) и корректного запуска VM на другом узле кластера реализован с помощью интерфейсов управления аппаратной платформой.

Ovirt 3.5.x поддерживает только ограниченный набор интерфейсов управления серверной платформой, которые могут быть использованы для реализации функционала:

Power Management и управление энергосбережением (аналог Power Optimization в SCVMM 2012);
Динамического распределения нагрузки в кластере (DRS в терминах VMWare или PROTips и Dynamic Optimization в терминах Microsoft);
Политики высокой доступности виртуальных машин (Microsoft High Available VMs или vSphere HA).

Поддерживаемые интерфейсы:

apc: APC MasterSwitch network power switch. Not for use with APC 5.x power switch devices.
apc_snmp: Use with APC 5.x power switch devices.
bladecenter: IBM Bladecentre Remote Supervisor Adapter.
cisco_ucs: Cisco Unified Computing System.
drac5: Dell Remote Access Controller for Dell computers.
drac7: Dell Remote Access Controller for Dell computers.
eps: ePowerSwitch 8M+ network power switch.
hpblade: HP BladeSystem.
ilo, ilo2, ilo3, ilo4: HP Integrated Lights-Out.
ipmilan: Intelligent Platform Management Interface and Sun Integrated Lights Out Management devices.
rsa: IBM Remote Supervisor Adaptor.
rsb: Fujitsu-Siemens RSB management interface.
wti: WTI Network PowerSwitch.

Это налагает определённые ограничения на выбор аппаратной платформы виртуализации.

oVirt использует механизм Fencing для поддержки узлов кластера в активном работающем состоянии. Узел кластера, который находится в статусе Non Responsive отличается от узла в статусе Non Operational тем, что узел со статусом Non Operational доступен для oVirt по сети управления, но к примеру имеет неверную конфигурацию логических сетей.

Non Responsive: -это узел с которым oVirt не может коммуницировать. Если oVirt теряет коммуникацию с узлом, то он может быть перезагружен (fenced) с портала администратора, либо автоматически в зависимости от состояния параметров управления питанием. В этом случае все виртуальные машины на сбойном узле будут остановлены, а высокодоступные виртуальные машины запущены на другом узле кластера.

Если сбойный узел кластера не вернулся к статусу активный, после команды перезагрузки, то он остаётся в положении Non-Responsive до устранения проблемы.

Все операции управления питанием выполняются через проксирующий узел, в отличии от операций, которые выполняются напрямую oVirt. Требуется минимум 2 узла в кластере для поддержки функционала fencing и работающего Power Management.

Soft-Fencing Hosts

Иногда узел кластера переходит в статус Non Responsive в виду внезапной проблемы и агент VDSM не будет отвечать на запросы, хотя виртуальные машины, зависимые от VDSM, будут продолжать работать и быть доступными.

В этом случае, перезагрузка VDSM агента может решить проблему. В oVirt 3.3 появился дополнительный механизм, называемый Soft-Fencing. Идея в том, что сервер управления oVirt будет пытаться перезагрузить агент VDSM узла кластера, подключившись по SSH. Данную операцию будет выполнять внешний fencing-агент, если он сконфигурирован.

Эта операция так же требует наличие прокси-узла в датацентре.

Запуск процедуры Soft-Fencing происходит по тайм-ауту соединения между сервером управления и хостом виртуализации.

Работает это следующим образом:

При первом сетевом сбое устанавливается статус «Connecting».
oVirt предпринимает 3 попытки подключения к VDSM для получения статуса и ожидает ответ интервал времени, который определяется загрузкой узла. Формула следующая:

  TimeoutToResetVdsInSeconds (the default is 60 seconds)
+ [DelayResetPerVmInSeconds (the default is 0.5 seconds)]*(the count of running vms on host)
+ [DelayResetForSpmInSeconds (the default is 20 seconds)] * 1 (if host runs as SPM) or 0 (if the host does not run as SPM).

ПРИМЕЧАНИЕ!: The Storage Pool Manager или SPM — это роль, которая выдаётся oVirt конкретному узлу в Datacenter для управления хранилищами. SPM контролирует доступ к хранилищам, координируя метаданные для Storage Domains. Это включает операции: создания, удаления, манипулирования виртуальными дисками, снапшотами и шаблонами, выделением хранилищ SAN и отвечает за целостность данных.

Для того, чтобы дать VDSM максимальное кол-во времени на ответ, oVirt выбирает самое длинное значение, полученное с помощью формулы, приведённой выше.
Если узел не ответил за отведённое время вызывается процедура vdsm restart по SSH
Если vdsm restart не привёл к установлению соединения между узлом и сервером управления oVirt, то узел переходит в состояние Non Responsive.
Далее, если сконфигурировано управления питанием управление будет передано внешнему fencing-агенту.

ПРИМЕЧАНИЕ!: Soft-fencing over SSH может быть выполнено на узле, которые не имеет функционала Power Management.

Sanlock Fencing

Данный механизм — Sanlock Daemon, включен в продукт с Ovirt 3.1 для получение хостами аренды области с данными на общем хранилище. Sanlock Fencing использует возможности shared storage (NFS, Glusterfs, FCP и т. д.) и эффективен в тех случаях, когда хост стал недоступен через обычные средства коммуникации: Power Management или сетевые интерфейсы. В этом случае узел-прокси пошлет команду на демон недоступного узла, а тот отправит узел кластера в перезагрузку.

Основной проблемой данного механизма является то, что при сбое аппаратного обеспечения, потере электропитания или kernel panics, недоступности общего хранилища, узел перестаёт обновлять свою аренду. Так как мы не имеет данных о состоянии узла, мы предполагаем, что узел может начать писать на СХД в любой момент. Как следствие, мы не можем перезапустить узел используя sanlock, чтобы предотвратить запись в одни и те же области СХД, получив потерю данных. Нам потребуется в ручную перезагрузить узел.

Детально о Sanlock Fencing можно прочитать тут

Интеграция oVirt 3.5 с Microsoft Active Directory

Рассмотрим процедуру интеграции oVirt 3.5 c Microsoft Active Directory.

Делается это достаточно просто, но требует некоторых подготовительных мероприятий:

Необходимо обеспечить возможность разрешения DNS имён (A, PTR, SRV записей) сервером oVirt 3.5 и контроллером домена;
Сервер oVirt и контроллер домена должны иметь одинаковое время (так как используется Kerberos);
необходимо выполнить предварительные требования для сервисной учётной записи oVirt;

Разрешение имён

У меня в лаборатории существуют два отдельных домена DNS: ROSA.DEMO на BIND и TARGET.COM на MS-DNS. Для разрешения имён я настроил Conditional Forwarding и Stub-zone на BIND (не совсем рекомендованный способ, но было интересно);

ПРИМЕЧAНИЕ!: При настройке лаборатории я не придерживался какого-то формального Best Practice по Linux (лучше ограничивать доступ к внутренним DNS серверам доверенными сетями).

Узлы должны успешно разрешать помимо А-записей:

pointer record (PTR) for the directory server’s reverse look-up address.
service record (SRV) for LDAP over TCP port 389
service record (SRV) for Kerberos over TCP port 88
service record (SRV) for Kerberos over UDP port 88

Требование к синхронизации времени

Вопрос легко решаются с помощью централизованного NTP сервера. От себя добавлю, что первые попытки интеграции провалились по причине разницы во времени и часового пояса. Необходимо обращать внимание:

на формат данных времени и часового пояса;
часовой пояс;
функционал автоматической смены летнего/зимнего времени (может добавить +\- 1 час к текущему времени) .

Так же, рекомендую отключать компонент синхронизации времени виртуальных машин с хостом и для контроллера домена, и для виртуального сервера oVirt 3.5

ПРИМЕЧАНИЕ!: Кстати, мой стенд, в виртуальной его части (3 сервера RELS с ролями BIND, IPA, OVIRT и 1 контроллер домена на MS Windows Server) собран полностью на Hyper-V 2012 R2, плюс несколько физических серверов под RELS 6.6

Требования к сервисной учётной записи следующие:

Read Access to Directory Services
Join a computer to the domain
Modify the membership of a group

Интеграция

Собственно, сабж. выполняем интеграцию с помощью команды engine-manage-domains add, как на скриншоте ниже.

Затем перезапускаем сервис ovirt-engine.

Собственно, результат смотрим ниже.

Ошибка Ovirt 3.5 при подключении iso образа в виртуальной машины ACTION_TYPE_FAILED_INVALID_CDROM_DISK_FORMAT

Натолкнулся на фичу oVirt 3.5, о которой производитель успешно молчит. При попытке смонтировать в виртуальную машину диск ISO, к примеру со следующим названием SW_DVD9_SQL_Svr_Standard_Edtn_2012w_SP2_64Bit_English_-2_MLF_X19-75010.ISO получаем следующую ошибку:

md5sum показывала полное совпадение хэшей, ну и размер образов совпадал.

Дело в том, что oVirt 3.5 не понимает расширение файла iso, если оно написано заглавными буквами. После переименования образа командой mv, файл-образ успешно был подключен к виртуальной машины.