Обслуживание виртуализированного ЦУ

Режимы обслуживания виртуализированного ЦУ

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

Существует три режима обслуживания:

Глобальный ‒ Мониторинг состояния СУСВ со стороны всех агентов высокой доступности в кластере отключается. Глобальный режим должен применяться для любых операций по настройке или обновлению, требующих остановки службы ovirt-engine.
Локальный ‒ Мониторинг состояния СУСВ со стороны агента высокой доступности на узле, отдающем команду, отключается. В локальном режиме обслуживания узел исключается из числа узлов, на которых может размещаться СУСВ; если во время перевода в этот режим на узле размещается СУСВ, то она мигрирует на другой узел при условии доступности такого узла. Локальный режим рекомендуется во время применения изменений системных параметров узла виртуализированного ЦУ.
Нет ‒ Режим обслуживания отключается, обеспечивая работу агентов высокой доступности.

Активация локального режима обслуживания

Включение локального режима обслуживания останавливает работу агента высокой доступности на отдельном узле виртуализированного ЦУ.

Для активации локального режима обслуживания с Портала администрирования:

Перевести узел виртуализированного ЦУ в локальный режим обслуживания:

На Портале администрирования нажмите "Ресурсы → Хосты" и выберите узел виртуализированного ЦУ.
Выберите "Управление → Обслуживание" (рисунок 169) и в открывшемся окне нажмите OK. Опционально укажите причину перевода хоста в режим обслуживания (рисунок 170). Выбранный узел будет автоматически помещён в локальный режим обслуживания.

Рисунок 169 ‒ Активация локального режима обслуживания хоста

Укажите причины перевода в режим обслуживания (рисунок 170).

Рисунок 170 ‒ Форма подтверждения перевода хоста в режим обслуживания

Выполнив необходимые задачи по обслуживанию, отключите режим обслуживания:

На Портале администрирования нажмите "Ресурсы → Хосты" и выберите узел виртуализированного ЦУ.
Нажмите "Управление → Активировать" для активации хоста, находящегося в режиме обслуживания (рисунок 171).

Рисунок 171 ‒ Активация хоста, находящегося в режиме обслуживания

Для активации локального режима обслуживания из командной строки:

Войдите в систему на узле виртуализированного ЦУ и переведите его в локальный режим обслуживания:

hosted-engine --set-maintenance --mode=local

Выполнив необходимые задачи по обслуживанию, отключите режим обслуживания:

hosted-engine --set-maintenance --mode=none

Активация глобального режима обслуживания

Включение глобального режима обслуживания останавливает работу агентов высокой доступности на всех узлах виртуализированного ЦУ в кластере.

Для активации глобального режима обслуживания через интерфейс Портала администрирования:

Переведите все узлы виртуализированного ЦУ в глобальный режим обслуживания:

На Портале администрирования нажмите "Ресурсы → Хосты" и выберите любой узел виртуализированного ЦУ.
Нажмите пиктограмму (больше действий), затем нажмите Включить глобальное обслуживание высокой доступности (рисунок 172).

Рисунок 172 ‒ Меню "Больше действий" в форме для управления хостами

Выполнив необходимые задачи по обслуживанию, отключите режим обслуживания:

На Портале администрирования нажмите "Ресурсы → Хосты" и выберите любой узел виртуализированного ЦУ.
Нажмите пиктограмму (больше действий), затем нажмите Отключить глобальное обслуживание высокой доступности.

Для активации глобального режима обслуживания из командной строки:

Войдите в систему на узле виртуализированного ЦУ и переведите его в глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=global

Выполнив необходимые задачи по обслуживанию, отключите режим обслуживания:

hosted-engine --set-maintenance --mode=none

Администрирование СУСВ

Утилита hosted-engine предоставляет в помощь администраторам множество команд для работы с СУСВ. Утилиту можно запускать на любом узле виртуализированного ЦУ. Для просмотра всех доступных команд выполните:

hosted-engine —help

Дополнительные сведения по отдельной команде можно просмотреть, выполнив:

hosted-engine --<команда> --help

Обновление конфигурации виртуализированного ЦУ

Для обновления конфигурации виртуализированного ЦУ используйте команду:

hosted-engine --set-shared-config.

Эта команда обновляет конфигурацию виртуализированного ЦУ в домене разделяемого хранилища после выполнения начального развёртывания.

Для просмотра значений текущей конфигурации используйте команду:

hosted-engine --get-shared-config.

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

hosted-engine --set-shared-config key --type=type --help

где параметр type будет одним из указанных в таблице 68.

Настройка почтовых уведомлений

Для каждого изменения состояния высокой доступности на узлах виртуализированного ЦУ можно настроить почтовые уведомления с помощью SMTP. Обновляемые ключи включают в себя: smtp-server, smtp-port, source-email, destination-emails и state_transition.

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

На узле виртуализированного ЦУ настройте желаемый адрес сервера SMTP для ключа smtp-server:

hosted-engine --set-shared-config smtp-server smtp.example.com \
--type=broker

Примечание — Для проверки обновлённых значений в конфигурации виртуализированного ЦУ выполните:

hosted-engine --get-shared-config smtp-server --type=broker \
broker : smtp.example.com, type : broker

Проверьте конфигурация порта SMTP по умолчанию (порт 25):

hosted-engine --get-shared-config smtp-port –type=broker
broker : 25, type : broker

Укажите почтовый адрес, с которого сервер SMTP будет отправлять уведомления. Можно указать только один адрес:

hosted-engine --set-shared-config source-email source@example.com \
--type=broker

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

hosted-engine --set-shared-config destination-emails \
destination1@example.com,destination2@example.com  --type=broker

Для проверки корректности параметров SMTP, настроенных для окружения виртуализированного ЦУ, измените состояние высокой доступности на узле виртуализированного ЦУ и проверьте, пришло ли почтовое уведомление. Изменить состояние можно, например, переведя агента высокой доступности в режим обслуживания. Дополнительные сведения см. в разделе Режимы обслуживания виртуализированного ЦУ.

Настройка резервирования слотов памяти для виртуализированного ЦУ на дополнительных хостах

В случае если СУСВ необходимо выключить или выполнить её миграцию, объём памяти на узле виртуализированного ЦУ должен быть достаточным для перезапуска или миграции на этот узел СУСВ. Эту память можно зарезервировать на нескольких узлах виртуализированного ЦУ с помощью политики планирования. Перед выполнением запуска или миграции любых ВМ эта политика проверяет, останется ли достаточно памяти для запуска ВМ на указанном числе дополнительных узлов виртуализированного ЦУ.

Сведения о том, как добавить дополнительные узлы виртуализированного ЦУ в СУСВ см. в п. Режимы обслуживания виртуализированного ЦУ.

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

Нажмите "Ресурсы → Кластеры" и выберите кластер, в котором располагаются узлы виртуализированного ЦУ.
Нажмите Изменить.
Перейдите на вкладку "Политика планирования".
Нажмите + и выберите "HeSparesCount".
Введите число дополнительных узлов виртуализированного ЦУ, на которых будет зарезервирован объём памяти, достаточный для запуска ВМ виртуализированного ЦУ.
Нажмите OK.

Добавление узлов виртуализированного ЦУ для СУСВ

Узлы виртуализированного ЦУ добавляются точно так же, как добавляются стандартные хосты с дополнительным шагом по развёртыванию хоста как узла виртуализированного ЦУ. Домен разделяемого хранилища обнаруживается автоматически, и узел можно использовать как запасной хост для размещения СУСВ при необходимости. Также стандартный хост можно прикрепить к окружению виртуализированного ЦУ, но на этих хостах невозможно размещать СУСВ. Для обеспечения высокой доступности машине диспетчера необходимо иметь минимум два узла виртуализированного ЦУ.

Предварительные условия для добавления узлов виртуализированного ЦУ для СУСВ:

Все узлы виртуализированного ЦУ должны располагаться в одном и том же кластере.
Если узел виртуализированного ЦУ будет использоваться повторно, удалите существующую конфигурацию его виртуализированного ЦУ.

Порядок действий по добавлению узлов виртуализированного ЦУ для СУСВ:

На портале администрирования нажмите "Ресурсы → Хосты".
Нажмите Добавить.
Сведения по настройке параметров дополнительных хостов см. в п. Хосты.
В выпадающем списке выберите дата-центр и кластер хоста для нового хоста.
Введите "Имя" и "Адрес" нового хоста. Стандартный порт SSH ‒ 22 ‒ будет автоматически введён в соответствующем поле.
Выберите метод аутентификации, который диспетчер будет использовать при доступе к хосту:

Для аутентификации по паролю введите пароль пользователя root.
Для аутентификации по открытому ключу, скопируйте ключ из поля "Открытый ключ SSH" в файл /root/.ssh/authorized_keys на хосте.

Перейдите на вкладку "Виртуализированный ЦУ".
Выберите "Развернуть".
Нажмите OK.

Перенастройка существующего хоста в качестве узла виртуализированного ЦУ

Существующий стандартный хост в окружении виртуализированного ЦУ можно превратить в узел виртуализированного ЦУ, пригодного для размещения ВМ диспетчера.

Примечание — Во время установки или переустановки ОС хоста настоятельно рекомендуется предварительно открепить любые не относящиеся к ОС хранилища, прикреплённые к хосту, во избежание случайной инициализации дисков хранилища и возможной потери данных на них.

Последовательность действий по перенастройке существующего хоста в качестве узла виртуализированного ЦУ:

Нажмите "Ресурсы → Хосты" и выберите хост.
Нажмите "Управление → Обслуживание" и нажмите OK для подтверждения перевода хоста в режим обслуживания (170).
Нажмите "Установка → Переустановить".
Перейдите на вкладку "Виртуализированный ЦУ" и в выпадающем списке выберите "Развернуть".
Нажмите OK.

Хост будет переустановлен с конфигурацией виртуализированного ЦУ и затем будет помечен пиктограммой "корона" на портале администрирования.

Загрузка СУСВ в режиме восстановления

В данном разделе описывается способ загрузки СУСВ в режим аварийного восстановления в случаях, когда ВМ не запускается:

Подключитесь к одному из узлов виртуализированного ЦУ (host_address — адрес хоста):

$ ssh root@host_address

Переведите виртуализированный ЦУ в глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=global

Проверьте наличие уже выполняющегося экземпляра ВМ диспетчера:

hosted-engine --vm-status

Если экземпляр ВМ диспетчера уже выполняется, подключитесь к её хосту:

ssh root@host_address

Выключите ВМ, выполнив в консоли команду:

hosted-engine --vm-shutdown

Если ВМ не выключается, выполните следующую команду:

hosted-engine --vm-poweroff

Запустите ВМ диспетчера в режиме паузы:

hosted-engine --vm-start-paused

Настройте временный пароль VNC:

hosted-engine --add-console-password

Данная команда выводит сведения, необходимые для выполнения входа на ВМ диспетчера с помощью консоли VNC.

Войдите в систему ВМ диспетчера с помощью VNC. ВМ диспетчера по-прежнему на паузе, поэтому кажется зависшей.
Возобновите работу ВМ диспетчера с помощью следующей команды, выполняемой на её хосте:

/usr/bin/virsh -c \
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf \
resume HostedEngine

Примечание — После выполнения данной команды будет показано меню загрузчика. Войти в режим восстановления необходимо до того, как загрузчик продолжит процесс обычной загрузки. Перед тем как выполнять данную команду, прочтите описание следующего шага по переходу в режим восстановления.

Загрузите ВМ диспетчера в режиме восстановления.
Отключите глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=none

Теперь на СУСВ можно выполнять работы по её восстановлению.

Удаление хоста из окружения виртуализированного ЦУ

Чтобы удалить узел виртуализированного ЦУ из окружения, переведите узел в режим обслуживания, сверните установку узла, и (опционально) удалите её. После остановки служб высокой доступности и удаления файлов конфигурации виртуализированного ЦУ узлом можно управлять как обычным хостом.

Последовательность действий по удалению хоста из окружения виртуализированного ЦУ

На портале администрирования нажмите "Ресурсы → Хосты" и выберите узел виртуализированного ЦУ.
Нажмите "Управление → Обслуживание" и далее нажмите OK.
Нажмите "Установка → Переустановить".
Перейдите на вкладку "Виртуализированный ЦУ" и в выпадающем списке выберите "Свернуть установку". Данное действие останавливает работу служб ovirt-ha-agent и ovirt-ha-broker и удаляет файл конфигурации виртуализированного ЦУ.
Нажмите OK.
Опционально нажмите Удалить: будет запущено окно с подтверждением удаления хостов.
Нажмите OK.

Изменение полного доменного имени СУСВ в виртуализированном ЦУ

С помощью команды ovirt-engine-rename можно обновлять записи полного доменного имени (FQDN) диспетчера.

Резервные копии и миграция

В данной главе рассмотрен процесс создания резервных копий СУСВ и восстановление СУСВ из резервных копий.

Обзор создания резервных копий СУСВ

Для регулярного резервного копирования СУСВ используйте утилиту engine-backup. Утилита создаёт резервные копии БД СУСВ и файлов конфигурации в одном файле, и утилиту можно запускать без прерывания работы службы ovirt-engine.

Синтаксис команды engine-backup

Команда engine-backup работает в одном из двух базовых режимов:

engine-backup --mode=backup
engine-backup --mode=restore

Эти два режима можно расширить набором параметров, позволяющих уточнить область данных для резервного копирования, а также указать различные учётные данные для БД СУСВ. Полный список параметров и их назначение можно просмотреть, выполнив команду:

engine-backup --help

Базовые параметры команды engine-backup:

--mode ‒ Указывает, что выполняет команда: операция создания резервной копии или операция восстановления из резервной копии. Доступные параметры: backup (по умолчанию), restore и verify. Для операций verify или restore необходимо также указать параметр mode.

--file ‒ Указывает путь и имя файла (например, file_name.backup), в котором будет сохранена резервная копия в режиме создания резервных копий, и из которого будут читаться данные в режиме восстановления. По умолчанию путь равен /var/lib/ovirt-engine-backup/.

--log ‒ Указывает путь и имя файла (например, log_file_name), в который будет записываться журнал операции создания или восстановления резервной копии. По умолчанию путь равен /var/log/ovirt-engine-backup/.

--scope ‒ Указывает область данных, включаемых в создание или восстановление резервной копии. Есть четыре параметра: all (по умолчанию) — для создания резервной копии или восстановления всех баз данных и данных конфигураций; files — для создания резервной копии или восстановления только файлов системы; db — для создания резервной копии или восстановления только БД СУСВ; dwhdb — для создания резервной копии или восстановления только БД хранилища данных.

В одной и той же команде engine-backup параметр --scope можно указывать несколько раз.

Параметры БД СУСВ

Следующие параметры доступны только при использовании команды engine-backup в режиме restore. Синтаксис параметров, описанный ниже, применяется при восстановлении БД СУСВ. Те же параметры существуют для восстановления БД хранилища данных. Синтаксис параметров для хранилища данных см. в выводе команды:

engine-backup –help

--provision-db ‒ Создаёт БД PostgreSQL, в которую будет восстанавливаться резервная копия БД СУСВ. Этот параметр является обязательным при восстановлении из резервной копии на удалённом хосте или в свежей установке, не имеющей уже настроенной БД PostgreSQL. При использовании в режиме восстановления к этому параметру по умолчанию добавляется параметр --restore-permissions.

--provision-all-databases ‒ Создаёт БД для всех дампов памяти, включённых в архив. Если параметр включён, это является значением по умолчанию.

--change-db-credentials ‒ Даёт возможность указать другие учётные данные при восстановлении БД СУСВ с учётными данными, отличными от сохранённых непосредственно в архиве. Дополнительные параметры, необходимые данному параметру, см. в выводе backup –help.

--restore-permissions или —no-restore-permissions ‒ Восстанавливает или не восстанавливает полномочия пользователей БД. Один из этих параметров является требуемым при восстановлении из резервной копии. При использовании параметра --provision-* в режиме восстановления --restore-permissions применяется по умолчанию.

Примечание — Если в резервной копии содержатся предоставления полномочий дополнительным пользователям БД, то при восстановлении с использованием параметров --restore-permissions и --provision-db (или --provision-dwh-db) создаются дополнительные пользователи со случайно созданными паролями. Если дополнительным пользователям требуется доступ к восстановленной системе, то эти пароли необходимо сменить вручную. См. дополнительную информацию по ссылке.

Создание резервных копий с помощью команды engine-backup

Резервные копии СУСВ при активной СУСВ можно создавать с помощью команды engine-backup.

Добавьте один из следующих аргументов к параметру --scope для указания, что именно требуется поместить в архив:

all ‒ Полная резервная копия всех БД и файлов конфигурации СУСВ. Это является значением по умолчанию для параметра --scope.
files ‒ Резервная копия только файлов в системе.
db ‒ Резервная копия только БД СУСВ.
dwhdb ‒ Резервная копия только БД хранилища данных.
cinderlibdb ‒ Резервная копия только БД Cinderlib.
grafanadb ‒ Резервная копия только БД Grafana.

Указывать параметр --scope можно несколько раз.

Команду engine-backup можно настроить на создание резервной копии для дополнительных файлов. При восстановлении эта команда восстанавливает все файлы из архива.

Примечание — Для восстановления из резервной копии в свежей установке СУСВ недостаточно только архива с БД. СУСВ также нужен доступ к файлам конфигурации. При указании области действия, отличной от all, необходимо также указать --scope=files, либо создать резервную копию файловой системы.

Примечание — Полные сведения о команде engine-backup можно получить в выводе команды:

engine-backup —help

на машине диспетчера.

Последовательность действий для создания резервных копий с помощью команды engine-backup:

Войдите в систему на машине СУСВ.
Создайте резервную копию:

engine-backup

Следующие параметры применяются по умолчанию:

--scope=all;
--mode=backup.

Эта команда создаёт резервную копию в /var/lib/ovirt-engine-backup/file_name.backup и файл журнала /var/log/ovirt-engine-backup/log_file_name.

Для сохранения окружения используйте file_name.tar.

В примерах ниже показываются несколько разных сценариев создания резервных копий.

Пример 1. Создание полной резервной копии:

engine-backup

Пример 2. Резервная копия БД СУСВ:

engine-backup --scope=files --scope=db

Пример 3. Резервная копия БД хранилища данных:

engine-backup --scope=files --scope=dwhdb

Пример 4. Добавление в архив конкретных файлов:

Создайте каталог для хранения специальных параметров конфигурации команды engine-backup:

mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d

Создайте в новом каталоге текстовый файл с именем ntp-chrony.sh и следующим содержимым:

BACKUP_PATHS="${BACKUP_PATHS}
/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"

При запуске команды engine-backup используйте --scope=files. В создание и восстановление из резервной копии входят /etc/chrony.conf, /etc/ntp.conf и /etc/ovirt-engine-backup.

Восстановление из резервной копии с помощью команды engine-backup

Восстановление из резервной копии при помощи команды engine-backup требует большего числа шагов, чем создание резервной копии, в зависимости от места назначения восстановления. Например, команду engine-backup можно использовать для восстановления резервных копий в свежую установку ROSA Virtualization, поверх уже имеющейся установки ROSA Virtualization, а также использовать локальные или удалённые БД.

Восстановление из резервной копии в свежую установку

Команду engine-backup можно использовать для восстановления из резервной копии в свежую установку диспетчера ROSA Virtualization. Нижеописанная процедура должна выполняться на машине с установленной хост-системой, но где ещё не запускалась команда engine-setup. Данная процедура предполагает, что с машины, на которой будет восстановлена резервная копия, есть доступ к файлам с резервной копией.

Последовательность действий для восстановления из резервной копии:

Выполните вход в систему на машине диспетчера. Если восстанавливается БД СУСВ на удалённый хост, то необходимо также войти в систему на этом хосте и выполнить там требуемые действия. Аналогичным образом при восстановлении БД хранилища данных на удалённый хост на этом хосте необходимо войти в систему и выполнить требуемые действия.
Выполните полное восстановление либо только восстановление резервной копии БД.

Полное восстановление:

engine-backup --mode=restore --file=file_name \
--log=log_file_name --provision-db

При использовании параметра --provision-* в режиме восстановления параметр --restore-permissions применяется по умолчанию.

Если во время полного восстановления также восстанавливается и хранилище данных, укажите дополнительную БД:

engine-backup --mode=restore --file=file_name \
--log=log_file_name --provision-db -- provision-dwh-db

При восстановлении резервной копии только БД восстановите файлы конфигурации и архив БД:

engine-backup --mode=restore --scope=files --scope=db \
--file=file_name -- log=log_file_name --provision-db

В примере ниже восстанавливается резервная копия БД диспетчера.

engine-backup --mode=restore --scope=files --scope=dwhdb \
--file=file_name -- log=log_file_name --provision-dwh-db

В примере ниже восстанавливается резервная копия БД хранилища данных. В случае успеха показывается следующее сообщение:

You should now run engine-setup. Done.

Для создания конфигурации восстановленного диспетчера запустите команду и следуйте подсказкам:

engine-setup

В результате СУСВ будет восстановлен в версии, сохранённой в резервной копии.

Восстановление из резервной копии с перезаписью существующей установки

Команда engine-backup может восстановить резервную копию на машину, где уже была установлена и настроена СУСВ. Это удобно в ситуациях, когда сначала была создана резервная копия окружения, затем в окружение были внесены изменения, а далее необходимо эти изменения отменить с восстановлением окружения.

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

Последовательность действий для выполнения восстановления из резервной копии с перезаписью существующей установки:

Войдите в систему на машине СУСВ.
Удалите файлы конфигурации и очистите БД, связанную с диспетчером, выполнив команду:

engine-cleanup

Примечание — Команда engine-cleanup только очищает БД СУСВ; БД не будет удалена из системы, а также не будут удалены пользователи, владеющие этой БД.

Восстановление полной резервной копии или резервной копии только БД. Нет необходимости создавать новую БД или указывать учётные записи, т.к. пользователи и БД уже существуют.

Восстановление из полной резервной копии:

engine-backup --mode=restore --file=file_name \
--log=log_file_name --restore- permissions

Восстановление только БД с помощью восстановления файлов конфигурации и архива БД:

engine-backup --mode=restore --scope=files --scope=db \
--scope=dwhdb -- file=file_name --log=log_file_name --restore-permissions

Примечание — Чтобы восстановить только БД диспетчера (если, например, БД хранилища данных расположена на другой машине), можно опустить параметр --scope=dwhdb.

В случае успеха будет показано следующее сообщение:

You should now run engine-setup.
Done.

Повторная настройка диспетчера:

engine-setup

Восстановление из резервной копии с использованием других учётных данных

Команда engine-backup может восстановить резервную копию на машину, где СУСВ уже ранее была установлена и настроена, в ситуации, когда данные учётных записей БД в резервной копии отличаются от данных, используемых на машине, где будет восстановлена эта резервная копия. Это удобно, если в одной системе нужно развернуть из резервной копии установку, созданную и настроенную в другой системе.

Примечание — При восстановлении из резервной копии с перезаписью существующей установки перед запуском команды engine-backup необходимо выполнить команду engine-cleanup для очистки существующей установки. Команда engine-cleanup только очищает БД СУСВ, но не удаляет её из системы и не удаляет пользователей-владельцев этой БД, поэтому нет необходимости создавать новую БД или указывать данные учётных записей. Тем не менее если данные учётной записи владельца БД неизвестны, их нужно изменить до того, как выполнять восстановление из резервной копии.

Последовательность действий по восстановлению из резервной копии с использованием других учётных данных:

Выполните вход в систему на машине СУСВ.
Для удаления файлов конфигурации диспетчера и очистки БД СУСВ запустите следующую команду и следуйте подсказкам:

engine-cleanup

Смените пароль владельца БД engine, если данные его учётной записи неизвестны:

Войдите в командную строку postgresql:

su ‒ postgres -c 'psql'

Смените пароль пользователя-владельца БД engine:

postgres=# alter role user_name encrypted password 'new_password';

В случае необходимости повторите эти действия для пользователя-владельца БД ovirt_engine_history.

Восстановите полный архив или архив только с БД с параметром --change-db-credentials для передачи учётных данных новой БД. Значение параметра database_location для БД, локальной относительно диспетчера, равно localhost.

Примечание — В следующем примере параметр --*password используется для каждой БД без указания пароля, в результате этого для каждого пароля БД выводится запрос командной строки.

Как вариант, для каждой БД можно использовать параметр --*passfile=password_file для защищённой передачи паролей утилите engine-backup без необходимости вводить пароли в интерактивном запросе командной строки.

Восстановите полную резервную копию:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--change-db- credentials --db-host=database_location –db \
name=database_name --db-user=engine --db-password --no-restore-permissions

Если в составе полного восстановления также восстанавливается БД хранилища данных, то необходимо включить данные учётных записей для дополнительной БД:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--change-db-credentials --db-host=database_location \
--dbname=database_name --db-user=engine --db-password \
--change-dwh-db-credentials --dwh-db-host=database_location \
--dwh-db- name=database_name --dwh-db-user=ovirt_engine_history \
--dwh-db-password --no-restore-permissions

Восстановление только резервной копии БД с помощью восстановления файлов конфигурации и архива БД:

engine-backup --mode=restore --scope=files --scope=db \
--file=file_name --log=log_file_name --change-db-credentials \
--db-host=database_location --db- name=database_name \
--db-user=engine --db-password --no-restore-permissions

В примере ниже восстанавливается резервная копия БД диспетчера.

engine-backup --mode=restore --scope=files --scope=dwhdb \
--file=file_name --log=log_file_name --change-dwh-db-credentials \
--dwh-db-host=database_location --dwh-db-name=database_name  \
--dwh-db-user=ovirt_engine_history –dwh-db-password \
--no-restore-permissions

You should now run engine-setup.
Done.

Для повторной настройки межсетевого экрана и проверки корректности настройки службы ovirt-engine выполните следующую команду:

engine-setup

Создание резервной копии и восстановление из резервной копии виртуализированного ЦУ

Для виртуализированного ЦУ также можно создавать резервные копии и восстанавливать на их базе виртуализированный ЦУ в новом окружении. Выполняйте эти действия для таких задач, как миграция окружений в новые домены хранилищ виртуализированного ЦУ с другими типами хранилищ.

При указании файла резервной копии во время развёртывания архив восстанавливается на новой СУСВ с новым доменом хранилища виртуализированного ЦУ. Старый диспетчер удаляется, а старый домен хранилища переименовывается и может быть удалён вручную после проверки корректности работы нового окружения. Настоятельно рекомендуется выполнять развёртывание на свежем хосте; если в архиве резервной копии окружения присутствовал хост, использованный для развёртывания, он будет удалён из восстановленной БД для избегания конфликтов в новом окружении. При развёртывании на новом хосте новому хосту нужно присвоить новое имя. Повторное использование имени существующего хоста, включённого в резервную копию, может привести к конфликтам в новом окружении.

Создание резервной копии виртуализированного ЦУ

Последовательность действий по созданию и восстановлению резервной копии включает в себя следующие ключевые шаги:

Создайте резервную копию исходной СУСВ с помощью утилиты engine-backup.
Разверните новый виртуализированный ЦУ и восстановите СУСВ из резервной копии.
Подключите репозитории СУСВ на новой СУСВ.
Переустановите узлы виртуализированного ЦУ для обновления их конфигурации.
Удалите домен хранилищ старого виртуализированного ЦУ.

Данная процедура предполагает, что у администратора есть доступ к исходному диспетчера и права на внесение изменений.

Предварительные требования для создания резервной копии виртуализированного ЦУ

Предварительные требования для создания резервной копии виртуализированного ЦУ:

Полное доменное имя, подготовленное для СУСВ и хоста. В DNS должны быть настроены записи для прямого и обратного поиска. Полное доменное имя новой СУСВ должно совпадать с именем исходной СУСВ.
Уровень совместимости ЦОД должен быть настроен на последнюю версию для обеспечения совместимости с обновлённой версией хранилища.
В окружении должен присутствовать минимум один обычный хост. Этот хост (а также любые другие обычные хосты) будет оставаться активным для выполнения роли диспетчера пула хранилища (SPM) и размещения любых выполняющихся ВМ. Если обычный хост ещё не является диспетчером пула хранилища, передайте эту роль до начала создания резервной копии, выбрав обычный хост и нажав "Управление → Выбрать как диспетчер пула хранилища (SPM)".

В случае отсутствия доступных обычных хостов есть два способа их добавить:

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

Создание резервной копии исходной СУСВ

Создайте резервную копию исходной СУСВ с помощью команды engine-backup и скопируйте файл архива резервной копии в отдельное местоположение, чтобы к нему сохранялся доступ в любой момент работы.

Дополнительные сведения о параметрах engine-backup --mode=backup смотрите в п. Режимы обслуживания виртуализированного ЦУ.

Последовательность действий по созданию резервной копии исходной СУСВ

Выполните вход в систему на одном из узлов виртуализированного ЦУ и поместите окружение в глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=global

Выполните вход в систему на исходной СУСВ и остановите службу ovirt-engine:

systemctl stop ovirt-engine
systemctl disable ovirt-engine

Примечание — Хотя остановка работы исходной СУСВ не является обязательной, это рекомендуется сделать, т.к. это обеспечивает защиту окружения от внесения изменений после создания резервной копии. Кроме того, это предотвращает возможность одновременного управления существующими ресурсами со стороны и исходной и новой СУСВ.

Выполните команду engine-backup, указав имя создаваемого файла резервной копии и имя файла создаваемого журнала процесса создания резервной копии:

engine-backup --mode=backup --file=file_name --log=log_file_name

Скопируйте файлы на внешний сервер. В примере ниже storage.example.com является полным доменным именем сервера сетевого хранилища, на котором будет храниться резервная копия до того момента, когда она понадобится, а /backup/ — это любая предназначенная папка или путь:

scp -p file_name log_file_name storage.example.com:/backup/

Выполните вход в систему на одном из узлов виртуализированного ЦУ и выключите исходную СУСВ:

hosted-engine --vm-shutdown

После создания резервной копии СУСВ разверните новый виртуализированный ЦУ и восстановите резервную копию на новой ВМ.

Восстановление резервной копии в новом виртуализированном ЦУ

Запустите сценарий hosted-engine на новом хосте и используйте параметр --restore-from-file=path/to/file_name для восстановления резервной копии диспетчера во время развёртывания.

Примечание — Если используется хранилище iSCSI, и цель iSCSI фильтрует подключения согласно списку управления доступом (ACL) инициатора, то развёртывание может закончиться неудачно с ошибкой STORAGE_DOMAIN_UNREACHABLE. Для предотвращения этой ошибки необходимо обновить конфигурацию iSCSI до начала развёртывания виртуализированного ЦУ:

Если выполняется повторное развёртывание на уже существующем хосте, то необходимо обновить параметры инициатора iSCSI хоста в файле /etc/iscsi/initiatorname.iscsi. Типизированное имя (IQN) инициатора должно совпадать с именем, ранее отображённым на цель iSCSI, либо необходимо его обновить до нового IQN, если это применимо.
При развёртывании на свежем хосте необходимо обновить конфигурацию цели iSCSI для принятия подключений с этого хоста.

Обратите внимание, что IQN можно обновлять либо на стороне хоста (инициатор iSCSI), либо на стороне хранилища (цель iSCSI).

Последовательность действий по восстановлению резервной копии в новом виртуализированном ЦУ:

Скопируйте файл резервной копии на новый хост. В примере ниже host.example.com является полным доменным именем хоста, а /backup/ — это любая предназначенная папка или путь.

scp -p file_name host.example.com:/backup/

Войдите в систему на новом хосте.
Чтобы избежать обрыва сеанса в случае неполадок с сетью или терминалом, для запуска сценария используйте оконный менеджер tmux.

Запустите tmux, используя следующую команду в консоли:

tmux

Запустите сценарий hosted-engine, указав путь до файла с резервной копией:

hosted-engine --deploy –restore-from-file=/backup/file_name

Чтобы остановить работу сценария и прервать развёртывание в любой момент, используйте клавиши CTRL+D.

Чтобы начать развёртывание, выберите "Yes".
Настройте сеть. Сценарий обнаружит сетевые контроллеры, пригодные для использования в качестве моста управления окружением.
При необходимости использования настраиваемого программно-аппаратного устройства для установки ВМ укажите путь к архиву OVA. В противном случае оставьте поле пустым.
Введите пароль root для СУСВ.
Введите открытый ключ SSH, с помощью которого можно будет выполнить вход в систему диспетчера в качестве пользователя root, и укажите, нужно ли разрешать доступ с использованием SSH для root.
Введите конфигурацию памяти и ЦП для ВМ.
Укажите MAC-адрес для ВМ диспетчера или примите случайно созданный адрес. Если ВМ должна получать адрес IP с помощью DHCP, убедитесь в наличии действительного зарезервированного DHCP для этого MAC-адреса. Сценарий развёртывания не настраивает сервер DHCP.
Укажите сетевые параметры ВМ. При указании статического IP укажите IP диспетчера.

Примечание — Статический IP должен принадлежать к той же самой подсети, что и хост. Если, например, хост располагается в 10.1.1.0/24, то IP ВМ СУСВ должен располагаться в том же диапазоне подсети (10.1.1.1-254/24).

Укажите, нужно ли добавлять запись ВМ диспетчера и запись базового хоста в файл /etc/hosts на ВМ. Убедитесь в разрешаемости имён хостов.
Укажите имя и номер порта TCP сервера SMTP, почтовый адрес для отсылки уведомлений и список адресов-получателей этих сообщений через запятую.
Укажите пароль пользователя admin@internal для доступа к порталу администрирования. Сценарий создаст ВМ.

Примечание — Если в связи с отсутствующей требуемой сетью или аналогичной проблемой хост перейдёт в нерабочее состояние, процесс развёртывания приостановится и будет выведено сообщение, аналогичное следующему:

[ INFO ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until
/tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса даёт возможность администратору:

Подключиться к порталу администрирования с помощью предоставленного URL.
Оценить ситуацию, понять, почему хост в нерабочем состоянии, и исправить всё, что необходимо исправить. Если, например, данное развёртывание было восстановлено из резервной копии, и в архив были включены сети, требуемые для кластера хоста, то нужно настроить сети, прикрепив необходимые сетевые контроллеры хоста к этим сетям.
Как только всё будет починено, и хост получит статус "работоспособен", удалите временный файл блокировки, указанный в системном сообщении, приведённом выше.

Настройте тип используемого хранилища:

Для NFS укажите версию, полный адрес и путь до хранилища, а также любые параметры монтирования.

Примечание — Не используйте точку монтирования старого домена хранилища виртуализированного ЦУ для нового домена хранилища, т.к. присутствует риск потери данных.

Укажите сведения о портале для iSCSI и выберите цель и LUN из списка автоматически обнаруженных. Во время развёртывания можно выбрать только одну цель iSCSI, но для подключения всех порталов из одной группы поддерживается механизм доступа по нескольким путям.

Примечание — Для возможности указания более одной цели iSCSI необходимо включить использования механизма доступа по нескольким путям до начала развёртывания виртуализированного ЦУ.

Для хранилища Gluster укажите полный адрес и путь до хранилища вместе с любыми параметрами монтирования.

Примечание — Не используйте точку монтирования строго домена хранилища виртуализированного ЦУ для нового домена хранилища, т.к. присутствует риск потери данных ВМ.

Примечание — Поддерживаются только хранилища Gluster с типом replica 1 и replica 3. Убедитесь, что том настроен следующим образом:

gluster volume set VOLUME_NAME group virt
gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36
gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30

Для Fibre Channel выберите LUN из списка автоматически обнаруженных. Адаптеры шины хоста должны быть заранее настроены и подключены, а LUN не должен содержать никаких существующих данных. Сведения о том, как повторно использовать уже существующий LUN, см. в п. Повторное использование LUN.

Укажите размер диска диспетчера.

Сценарий продолжит своё выполнение до завершения развёртывания.

В процессе развёртывания будут изменены ключи SSH диспетчера. Чтобы разрешить клиентским машинам доступ к новому диспетчеру без ошибок, связанных с SSH, удалите запись исходного диспетчера из файла .ssh/known_hosts на любой из клиентских машин, ранее имевших доступ к исходному диспетчеру.
После завершения развёртывания выполните вход в систему на ВМ новой СУСВ и подключите необходимые репозитории.

Повторная установка хостов

Переустановите хосты ROSA Virtualization на портале администрирования. Эти действия включают в себя остановку и перезапуск работы хостов.

Примечание — Настоятельно рекомендуется перед началом установки или переустановки ОС хостов отсоединить любые существующие, не относящиеся к ОС хранилища, прикреплённые к хостам. Это позволит избежать случайной инициализации этих дисков и связанной с этим возможной потери данных.

Предварительные требования для повторной установки хостов:

Если в кластере включена возможность миграции, ВМ могут автоматически мигрировать на любой другой хост в кластере. Соответственно, переустанавливайте хост в момент его относительно низкой нагрузки.
Убедитесь в том, что объём памяти в кластере достаточен для выполнения обслуживания хостов кластера. При нехватке памяти в кластере миграция ВМ зависнет и затем завершится сбоем. Для снижения потребления памяти перед помещением хоста в режим обслуживания выключите некоторые или все ВМ.
Перед началом переустановки убедитесь в том, что в кластере находится более одного хоста. Не пытайтесь начать переустановку всех хостов одновременно. Один хост всегда должен быть доступен для выполнения задач диспетчера пула хранилища (SPM).

Последовательность действий по повторной установка хостов:

Нажмите "Ресурсы → Хосты" и выберите хосты.
Выберите "Управление → Обслуживание" и нажмите OK.
Выберите "Установка → Переустановить". Будет открыто окно "Установить хост".
Перейдите на вкладку "Виртуализированный ЦУ" и в выпадающем списке выберите "Развернуть".
Для переустановки хоста нажмите OK.

После окончания процесса переустановки хоста, когда статус хоста снова будет "Работоспособен", можно выполнить миграцию ВМ обратно на хост.

Примечание — После выполнения регистрации хоста ROSA Virtualization в СУСВ статус этого хоста на портале администрирования может ошибочно показывать "Сбой установки". Нажмите "Управление→Активировать", и статус хоста сменится на "Работоспособен", а хост будет готов к использованию.

После переустановки узлов виртуализированного ЦУ статус нового окружения можно проверить, выполнив на одном из узлов следующую команду:

hosted-engine —vm-status

Во время восстановления старый домен хранилища виртуализированного ЦУ был переименован, но не был удалён на случай, если при восстановлении случится сбой. После подтверждения того, что окружение работает нормально, старый домен можно удалить.

Удаление домена хранилища

В ЦОД имеется домен хранилища, который необходимо удалить из виртуализированного окружения.

Последовательность действий по удалению домена хранилища

Нажмите "Хранилище → Домены".
Переведите домен хранилища в режим обслуживания и отсоедините его:

Нажмите на имя домена хранилища. Будет открыт подробный просмотр.
Перейдите на вкладку "Дата-центр".
Нажмите Обслуживание, затем нажмите OK.
Нажмите Отсоединить, затем нажмите OK.

Нажмите Удалить.
Опционально выберите "Форматировать домен", т.е. содержимое хранилища будет потеряно и поставьте флажок для удаления содержимого домена.
Нажмите OK.

Домен хранилища будет навсегда удалён из окружения.

Восстановление виртуализированного ЦУ из существующей резервной копии

Если виртуализированный ЦУ становится недоступен в связи с неустранимыми проблемами, его можно восстановить в новом окружении с помощью резервной копии, созданной до того, как начались проблемы, если такая резервная копия доступна.

При указании файла резервной копии во время развёртывания этот архив восстанавливается на новой ВМ и с новым доменом хранилища виртуализированного ЦУ. Старый диспетчер удаляется, а старый домен хранилища виртуализированного ЦУ переименовывается и удаляется вручную после проверки корректности работы нового окружения.

Настоятельно рекомендуется выполнять развёртывание на свежем хосте; если хост, используемый для развёртывания, существовал в окружении, для которого создавалась резервная копия, то он будет удалён из восстановленной БД во избежание конфликтов в новом окружении. Если развёртывание выполняется на новом хосте, этому хосту необходимо присвоить уникальное имя. Повторное использование имени хоста, включённого в резервную копию, может привести к конфликтам в новом окружении.

Последовательность восстановления виртуализированного ЦУ состоит из следующих ключевых действий:

Развёртывание нового виртуализированного ЦУ и восстановление резервной копии.
Подключение репозиториев СУСВ на новой ВМ СУСВ.
Переустановка узлов виртуализированного ЦУ для обновления их конфигурации.
Удаление старого домена хранилища виртуализированного ЦУ.

Данная процедура подразумевает, что у администратора нет доступа к исходному диспетчеру, и что у нового хоста есть доступ к файл резервной копии.

Предварительные требования для восстановления виртуализированного ЦУ:

Полное доменное имя, подготовленное для СУСВ и хоста. В DNS должны быть настроены записи для прямого и обратного поиска.
Полное доменное имя нового диспетчера должно совпадать с именем исходного диспетчера.

Восстановление из резервной копии на новом виртуализированном ЦУ

Запустите на новом хосте сценарий hosted-engine и с помощью параметра --restore-from-file=path/to/file_name восстановите диспетчер из резервной копии во время развёртывания.

Примечание — Если используется хранилище iSCSI, и цель iSCSI фильтрует подключения согласно списку управления доступом (ACL) инициатора, то развёртывание может закончиться неудачно с ошибкой STORAGE_DOMAIN_UNREACHABLE. Для предотвращения этой ошибки необходимо обновить конфигурацию iSCSI до начала развёртывания виртуализированного ЦУ:

Если выполняется повторное развёртывание на уже существующем хосте, то необходимо обновить параметры инициатора iSCSI хоста в файле /etc/iscsi/initiatorname.iscsi. Типизированное имя (IQN) инициатора должно совпадать с именем, ранее отображённым на цель iSCSI, либо необходимо его обновить до нового IQN, если это применимо.
При развёртывании на свежем хосте необходимо обновить конфигурацию цели iSCSI для принятия подключений с этого хоста.

Последовательность действий по восстановлению из резервной копии на новом виртуализированном ЦУ:

Скопируйте файл резервной копии на новый хост. В примере ниже host.example.com — это полное доменное имя хоста, а /backup/ — любая назначенная папка или путь:

scp -p file_name host.example.com:/backup/

Выполните вход в систему на новом хосте.
Чтобы избежать обрыва сеанса в случае неполадок с сетью или терминалом, для запуска сценария используйте оконный менеджер tmux. Запустите tmux командой:

tmux

Запустите сценарий hosted-engine, указав путь до файла с резервной копии:

hosted-engine --deploy --restore-from-file=backup/file_name

Чтобы остановить работу сценария и прервать развёртывание в любой момент, используйте CTRL+D.

Чтобы начать развёртывание, выберите "Yes".
Настройте сеть. Сценарий обнаруживает сетевые контроллеры, пригодные к использованию в качестве моста для управления окружением.
При необходимости использования настраиваемого программно-аппаратного устройствв для установки ВМ, укажите путь к архиву OVA. В противном случае оставьте поле пустым.
Введите пароль root для диспетчера.
Введите открытый ключ SSH, с помощью которого можно будет выполнить вход в систему диспетчера в качестве пользователя root, и укажите, нужно ли разрешать доступ с использованием SSH для root.
Введите конфигурацию памяти и ЦП для ВМ.
Укажите MAC-адрес для ВМ диспетчера или примите случайно созданный адрес. Если ВМ должна получать адрес IP с помощью DHCP, убедитесь в наличии действительного зарезервированного DHCP для этого MAC-адреса. Сценарий развёртывания не настраивает сервер DHCP.
Укажите сетевые параметры ВМ. При указании статического IP укажите IP СУСВ.

Примечание — Статический IP должен принадлежать к той же самой подсети, что и хост. Если, например, хост располагается в 10.1.1.0/24, то IP ВМ СУСВ должен располагаться в том же диапазоне подсети (10.1.1.1-254/24).

Укажите, нужно ли добавлять запись ВМ диспетчера и запись базового хоста в файл /etc/hosts на ВМ. Убедитесь в разрешаемости имён хостов.
Укажите имя и номер порта TCP сервера SMTP, почтовый адрес для отсылки уведомлений и список адресов-получателей этих сообщений через запятую.
Укажите пароль пользователя admin@internal для доступа к порталу администрирования. Сценарий создаст ВМ.

Примечание — Если в связи с отсутствующей требуемой сетью или аналогичной проблемой хост перейдёт в нерабочее состояние, процесс развёртывания приостановится и будет выведено сообщение, аналогичное следующему:

[ INFO ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until
/tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса даёт возможность администратору:

Подключиться к порталу администрирования с помощью предоставленного URL.
Оценить ситуацию, понять, почему хост в нерабочем состоянии, и исправить всё, что необходимо исправить. Если, например, данное развёртывание было восстановлено из резервной копии, и в архив были включены сети, требуемые для кластера хоста, то нужно настроить сети, прикрепив необходимые сетевые контроллеры хоста к этим сетям.
Как только всё будет починено, и хост получит статус "работоспособен", удалите временный файл блокировки, указанный в системном сообщении, приведённом выше. Процесс развёртывания продолжается.

Выберите тип используемого хранилища:

Для NFS укажите версию, полный адрес и путь до хранилища, а также любые параметры монтирования.

Примечание — Не используйте точку монтирования старого домена хранилища виртуализированного ЦУ для нового домена, т.к. существует риск потери данных ВМ.

Укажите сведения о портале для iSCSI и выберите цель и LUN из списка автоматически обнаруженных. Во время развёртывания можно выбрать только одну цель iSCSI, но для подключения всех порталов из одной группы поддерживается механизм доступа по нескольким путям.

Примечание — Для возможности указания более одной цели iSCSI необходимо включить использования механизма доступа по нескольким путям до начала развёртывания виртуализированного ЦУ.

Для хранилища Gluster укажите полный адрес и путь до хранилища, вместе с любыми параметрами монтирования.

Примечание — Не используйте точку монтирования старого домена хранилища виртуализированного ЦУ для нового домена, т.к. существует риск потери данных ВМ

Примечание — Поддерживаются только хранилища Gluster с типом replica 1 и replica 3. Убедитесь, что том настроен следующим образом:

gluster volume set VOLUME_NAME group virt
luster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36
gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30

Для Fibre Channel выберите LUN из списка автоматически обнаруженных. Адаптеры шины хоста должны быть заранее настроены и подключены, а LUN не должен содержать никаких существующих данных.

Укажите размер диска диспетчера. Сценарий продолжит своё выполнение до завершения развёртывания.
В процессе развёртывания будут изменены ключи SSH диспетчера. Чтобы разрешить клиентским машинам доступ к новому диспетчеру без ошибок, связанных с SSH, удалите запись исходного диспетчера из файла .ssh/known_hosts на любой из клиентских машин, ранее имевших доступ к исходному диспетчеру.
После завершения развёртывания выполните вход в систему на ВМ новой СУСВ и подключите необходимые репозитории.

Переустановка хостов

Примечание — При установке или переустановке хоста настоятельно рекомендуется предварительно отсоединить любые хранилища, не относящиеся к ОС. Это поможет избежать риска случайной инициализации дисков и связанной с этим потери данных.

Предварительные требования для переустановки хостов:

Если в кластере включена возможность миграции, ВМ могут автоматически мигрировать на любой другой хост в кластере. Соответственно, переустанавливайте хост в момент его относительно низкой нагрузки.
Убедитесь в том, что объём памяти в кластере достаточен для выполнения обслуживания хостов кластера. При нехватке памяти в кластере миграция ВМ зависнет и затем завершится сбоем. Для снижения потребления памяти перед помещением хоста в режим обслуживания выключите некоторые или все ВМ.
Перед началом переустановки убедитесь в том, что в кластере находится более одного хоста. Не пытайтесь начать переустановку всех хостов одновременно. Один хост всегда должен быть доступен для выполнения задач диспетчера пула хранилища (SPM).

Последовательность действий по переустановке хостов:

Нажмите "Ресурсы → Хосты" и выберите хосты.
Выберите "Управление → Обслуживание" и нажмите OK.
Выберите "Установка → Переустановить". Будет открыто окно "Установить хост".
Перейдите на вкладку "Виртуализированный ЦУ" и в выпадающем списке выберите "Развернуть".
Для переустановки хоста нажмите OK.

После переустановки хоста и после того, как хост снова получит статус "Работоспособен", можно выполнить миграцию ВМ назад на хост.

Примечание — После выполнения регистрации хоста ROSA Virtualization в СУСВ статус этого хоста на портале администрирования может ошибочно показывать "Сбой установки". Нажмите "Управление → Активировать", и статус хоста сменится на "Работоспособен", а хост будет готов к использованию.

hosted-engine --vm-status

Во время восстановления старый домен хранилища виртуализированного ЦУ будет переименован, но не будет удалён на случай, если при восстановлении случится сбой. После подтверждения того, что окружение работает нормально, старый домен можно удалить.

Удаление домена хранилища

В ЦОД имеется домен хранилища, который необходимо удалить из виртуализированного окружения.

Последовательность действий по удалению домена хранилища

Нажмите "Хранилище → Домены".
Переведите домен хранилища в режим обслуживания и отсоедините его:

Нажмите на имя домена хранилища. Будет открыт подробный просмотр.
Перейдите на вкладку "Дата-центр".
Нажмите Обслуживание, затем нажмите OK.
Нажмите Отсоединить, затем нажмите OK.

Нажмите Удалить.
Опционально выберите "Форматировать домен", т.е. содержимое хранилища будет потеряно, и поставьте флажок для удаления содержимого домена.
Нажмите OK.

Домен хранилища будет навсегда удалён из окружения.

Перезапись виртуализированного ЦУ существующей резервной копией

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

Процесс восстановления виртуализированного ЦУ до предыдущего состояния

Процесс восстановления виртуализированного ЦУ до предыдущего состояния состоит из следующих шагов:

Поместите окружение в глобальный режим обслуживания.
Восстановите резервную копию на ВМ СУСВ.
Отключите режим обслуживания.

Дополнительные сведения о параметрах engine-backup --mode=restore смотрите в п. Создание резервных копий с помощью команды engine-backup.

Активация глобального режима обслуживания

До начала выполнения любых задач по настройке или обновлению на ВМ СУСВ окружение виртуализированного ЦУ необходимо перевести в глобальный режим обслуживания.

Последовательность действий по активации глобального режима обслуживания:

Выполните вход в систему на одном из узлов виртуализированного ЦУ и поместите окружение в глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=global

Перед тем как продолжить, убедитесь, что окружение находится в глобальном режиме обслуживания:

hosted-engine --vm-status

В результате должно появиться сообщение, указывающее, что окружение находится в глобальном режиме обслуживания.

Восстановление из резервной копии для перезаписи существующей установки

С помощью команды engine-backup можно восстановить резервную копию на машине, где виртуализированный ЦУ уже ранее был установлен и настроен. Это удобно в тех ситуациях, когда сначала была сделана резервная копия окружения, затем в это окружение были внесены изменения, которые затем необходимо отменить с помощью восстановления окружения из резервной копии.

Изменения, внесённые в окружение после того, как была создана резервная копия, такие как добавление или удаление хостов, не будут присутствовать в восстановленном окружении. Это изменения нужно будет внести повторно.

Последовательность действий по восстановлению из резервной копии для перезаписи существующей установки:

Выполните вход в систему на ВМ СУСВ.
Удалите файлы конфигурации и очистите БД, связанную с диспетчером:

engine-cleanup

Примечание — Команда engine-cleanup только очищает БД диспетчера; БД не будет удалена из системы, а также не будут удалены пользователи, владеющие этой БД.

Восстановление полной резервной копии или резервной копии только БД. Нет необходимости создавать новую БД или указывать учётные записи, т.к. пользователи и БД уже существуют.

Восстановление из полной резервной копии:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--restore- permissions

Восстановление только БД с помощью восстановления файлов конфигурации и архива БД:

engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb \
-- file=file_name --log=log_file_name --restore-permissions

Примечание — Чтобы восстановить только БД СУСВ (если, например, БД хранилища данных расположена на другой машине), можно опустить параметр --scope=dwhdb.

В случае успеха будет показано следующее сообщение:

You should now run engine-setup.
Done.

Повторная настройка диспетчера:

engine-setup

Отключение глобального режима обслуживания

Последовательность действий по отключению глобального режима обслуживания:

Войдите в систему ВМ СУСВ и выключите её.
Войдите в систему на одном из узлов виртуализированного ЦУ и отключите глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=none

После выхода из глобального режима обслуживания ovirt-ha-agent запускает ВМ СУСВ, а затем автоматически запускается СУСВ.

Убедитесь в том, что окружение работает:

hosted-engine --vm-status

В выводимых сведениях присутствует статус виртуализированного ЦУ. Значение статуса должно быть одним из следующих: {"health": "good", "vm": "up", "detail": "Up"}.

Пока ВМ не начала работу и только загружается, ЦУ ещё не запущен и может иметь один из следующих статусов: {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}. В этом случае подождите несколько минут и повторите попытку.

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

Миграция хранилища данных на отдельную машину

В данном разделе описывается процесс миграции БД хранилища данных и службы с машины СУСВ на отдельную машину. Размещение службы Data Warehouse на отдельной машине снижает нагрузку на каждой отдельной машине, а также помогает избежать потенциальных конфликтов, возникающих при разделении ресурсов ЦП и памяти между различными процессами.

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

Существуют следующие возможности миграции:

Можно выполнить миграцию службы Data Warehouse с машины СУСВ и подключить её к существующей БД хранилища данных (ovirt_engine_history).
Можно выполнить миграцию БД хранилища данных с машины СУСВ, а затем перенести службу Data Warehouse.

Миграция БД хранилища данных на отдельную машину

До начала миграции службы Data Warehouse перенесите БД хранилища данных (ovirt_engine_history). Для создания резервной копии БД и восстановления её на машине новой БД используйте команду engine-backup. Дополнительные сведения об engine-backup смотрите в выводе команды:

engine-backup --help

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

На новом сервере БД должна быть установлена минимальная конфигурация.

Для миграции БД хранилища данных на отдельную машину выполните следующие действия:

Создайте резервную копию БД и файлов конфигурации хранилища данных на диспетчере:

engine-backup --mode=backup --scope=grafanadb --scope=dwhdb \
--scope=files -- file=file_name --log=log_file_name

Скопируйте файл резервной копии с диспетчера на новую машину:

scp /tmp/file_name root@new.dwh.server.com:/tmp

Установите engine-backup на новой машине:

dnf install ovirt-engine-tools-backup

Установите пакет сервера PostgreSQL:

dnf install postgresql-server postgresql-contrib

Инициализируйте БД PostgreSQL, запустите службу postgresql и настройте запуск этой службы при загрузке:

su ‒ postgres -c 'initdb'
systemctl enable postgresql
systemctl start postgresql

Восстановите БД хранилища данных на новой машине. Файл file_name — это файл резервной копии, скопированный с диспетчера.

engine-backup --mode=restore --scope=files --scope=grafanadb \
--scope=dwhdb -- file=file_name --log=log_file_name --provision-dwh-db

При использовании параметра --provision-* в режиме восстановления параметр --restore-permissions применяется по умолчанию.

БД хранилища данных теперь располагается на машине, отдельной от машины, на которой располагается диспетчер. После успешного восстановления БД хранилища данных подсказка командной строки указывает выполнить команду engine-setup. До запуска этой команды выполните миграцию службы Data Warehouse.

Миграция службы Data Warehouse на отдельную машину

Служба Data Warehouse, установленная и настроенная на СУСВ, может мигрировать на отдельную машину. Размещение службы Data Warehouse на отдельной машине помогает снизить нагрузку на машину СУСВ.

Обратите внимание, что в процессе данной процедуры выполняется миграция только службы Data Warehouse.

Сведения о том, как выполнить миграцию БД хранилища данных (ovirt_engine_history) до миграции службы Data Warehouse, приведены в п. Миграция БД хранилища данных на отдельную машину.

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

Предварительные требования для миграции службы Data Warehouse на отдельную машину:

СУСВ и хранилище данных должны быть ранее установлены на одну и ту же машину.
Для настройки новой машины хранилища данных необходимы следующие сведения:
Пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup - database.conf на диспетчере.
Возможность доступа с машины хранилища данных на машину диспетчера на порте TCP 5432.
Имя пользователя и пароль для БД хранилища данных из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf на диспетчере.

Если миграция БД ovirt_engine_history проводилась по инструкции, описанной в п. Миграция БД хранилища данных на отдельную машину, то файл резервной копии содержит эти данные, т.к. они были созданы во время настройки БД на этой машине.

Инструкция состоит из нескольких шагов:

Настройка новой машины хранилища данных.
Остановка службы Data Warehouse на машине диспетчера.
Создание конфигурации на новой машине хранилища данных.
Отключение пакета Data Warehouse на машине диспетчера.

Остановка службы Data Warehouse на машине диспетчера

Последовательность действий по остановке службы Data Warehouse на машине диспетчера:

Остановка службы Data Warehouse:

systemctl stop ovirt-engine-dwhd.service

Если БД размещается на удалённой машине, то необходимо предоставить доступ, вручную отредактировав файл postgres.conf. Измените строку listen_addresses в файле /var/lib/pgsql/data/postgresql.conf следующим образом:

listen_addresses = '*'

Если эта строка отсутствует или была закомментирована, добавьте её вручную.

Если БД размещается на машине диспетчера и была настроена во время чистой установки СУСВ, то доступ предоставляется по умолчанию.

Перезапустите службу postgresql:

systemctl restart postgresql

Настройка новой машины хранилища данных

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

Если на одну и ту же машину переносится и БД ovirt_engine_history и служба Data Warehouse, выполните команду, указанную ниже, иначе переходите к следующему шагу:

sed -i '/^ENGINE_DB_/d' \
/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
sed -i \
-e 's;^\(OVESETUP_ENGINE_CORE/enable=bool\):True;\1:False;' \
-e '/^OVESETUP_CONFIG\/fqdn/d' \
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Удалите файлы PKI apache/grafana, чтобы они могли быть созданы заново командой engine-setup с корректными значениями:

rm -f \
/etc/pki/ovirt-engine/certs/apache.cer \
/etc/pki/ovirt-engine/certs/apache-grafana.cer \
/etc/pki/ovirt-engine/keys/apache.key.nopass \
/etc/pki/ovirt-engine/keys/apache-grafana.key.nopass  \
/etc/pki/ovirt-engine/apache-ca.pem \
/etc/pki/ovirt-engine/apache-grafana-ca.pem

Для начала создания конфигурации хранилища данных на машине запустите команду:

engine-setup

Нажмите клавишу Enter для принятия автоматически определённого имени хоста либо введите своё имя хоста и нажмите Enter:

Host fully qualified DNS name of this server [autodetected host name]:

Для автоматической настройки межсетевого экрана нажмите Enter либо введите "No" и нажмите Enter для сохранения существующих параметров:

Setup can automatically configure the firewall on this system.
Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]:

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

Введите полное доменное имя и пароль диспетчера. Для принятия значений по умолчанию в каждом из других полей, нажмите Enter:

Host fully qualified DNS name of the engine server []: engine-fqdn
Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
Please choose one of the following:
- Access remote engine server using ssh as root
- Perform each action manually, use files to copy content around (1, 2) [1]:
ssh port on remote engine server [22]:
root password on remote engine server engine-fqdn: password

Укажите полное доменное имя и пароль машины БД диспетчера. Для принятия значений по умолчанию в каждом из других полей, нажмите Enter:

Engine database host []: manager-db-fqdn
Engine database port [5432]:
Engine database secured connection (Yes, No) [No]: Engine database name [engine]:
Engine database user [engine]: Engine database password: password

Подтвердите параметры установки:

Please confirm installation settings (OK, Cancel) [OK]:

Теперь служба Data Warehouse настроена на удалённой машине. Приступайте к отключению службы Data Warehouse на машине диспетчера.

Отключение службы Data Warehouse на диспетчере

Предварительные требования к машине:

Служба Grafana на машине должна быть отключена:

systemctl disable --now grafana-server.service

Последовательность действий по отключению службы Data Warehouse на диспетчере:

Перезапустите диспетчер на машине диспетчера:

service ovirt-engine restart

Для изменения файла /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf и указания параметра False выполните следующую команду:

sed -i \
-e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
-e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
sed -i \
-e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Отключите службу Data Warehouse:

systemctl disable ovirt-engine-dwhd.service

Удалите файлы Data Warehouse:

rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf \
/var/lib/ovirt-engine- dwh/backups/*

Служба Data Warehouse теперь размещается на машине, отдельной от машины диспетчера.

Создание и восстановление ВМ из резервных копий с использованием домена хранения резервных копий

Что такое домены хранения резервных копий

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

Доменом хранения резервных копий может стать любой домен хранения. Включить или отключить этот параметр можно, выставив или убрав флажок в диалоговом блоке "Управление доменом". Активировать этот параметр можно только после того, как работа всех ВМ в этом домене хранения будет завершена.

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

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

Некоторые причины для использования доменов хранения резервных копий вместо доменов экспорта:

В дата-центре может существовать несколько доменов хранения резервных копий, но только один домен экспорта. Домен хранения резервных копий можно выделить для создания резервных копий и восстановления в аварийных ситуациях.
В домен хранения резервных копий можно переместить резервные копии ВМ, шаблоны или снимки.
По сравнению с доменами экспорта, в доменах хранения резервных копий процессы миграции большого числа ВМ, шаблонов или файлов OVF проходят значительно быстрее.
По сравнению с доменами экспорта в доменах хранения резервных копий дисковое пространство используется более эффективно.
В отличие от доменов экспорта, которые поддерживают только хранение файлов, домены хранения резервных копий поддерживают как файловое (NFS, Gluster), так и блочное хранение (Fiber Channel и iSCSI).
Принимая во внимание ограничения, параметр хранения резервных копий для домена хранения можно включать и отключать динамически.

Ограничения использования:

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

Настройка домена хранения данных в качестве домена хранения резервных копий

Предварительные требования для настройки домена хранения данных:

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

Последовательность действий для настройки домена хранения данных в качестве домена хранения резервных копий:

На портале администрирования выберите "Хранилище → Домены".
Создайте новый домен хранения или выберите уже существующий и нажмите "Управление доменом". Откроется диалоговый блок "Управление доменами".
В "Дополнительных параметрах" отметьте флажком пункт "Хранение резервных копий".

В результате домен станет доменом хранения резервных копий.

Создание и восстановление резервной копии ВМ или снимка с помощью домена хранения резервных копий

Для выключенной ВМ или для снимка можно создать резервную копию. После этого резервную копию можно хранить в том же дата-центре, восстановить её при необходимости или же выполнить её миграцию в другой дата-центр.

Последовательность действий при создании резервной копии виртуальной машины

Создайте домен хранения резервных копий (см. п. Настройка домена хранения данных в качестве домена хранения резервных копий).
Создайте новую ВМ на основе ВМ, для которой нужно создать резервную копию:

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

Экспортируйте новую ВМ в домен хранения резервных копий.

Последовательность действий при восстановлении ВМ из резервной копии

Убедитесь в том, что домен хранения резервных копий, в котором хранится резервная копия ВМ, присоединён к дата-центру.
Импортируйте ВМ из домена хранения резервных копий.

Обновление сертификатов до истечения срока их действия

В системе ROSA Virtualization до версии 3.0 срок действия всех сертификатов равнялся 398 дням. Начиная с ROSA Virtualization версии 3.0, срок жизни самоподписанных внутренних сертификатов между гипервизорами и диспетчером будет равняться 10 годам.

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

Последовательность действий по обновлению сертификатов:

Обновление сертификатов хоста:

На портале администрирования нажмите "Ресурсы → Хосты".
Нажмите "Управление → Обслуживание" и OK. ВМ должны автоматически мигрировать с хоста. В случае прикреплённых ВМ или других причин для невозможности миграции машины необходимо выключить вручную.
После того, как на хосте не останется ВМ, и после помещения хоста в режим обслуживания нажмите "Установка → Регистрация сертификата".
После завершения регистрации нажмите "Управление → Активировать".

Обновите сертификаты диспетчера:

Только для виртуализированного ЦУ: войдите в систему на хосте и переведите его в глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=global

Виртуализированный ЦУ и отдельно размещённый диспетчер: войдите в систему на диспетчере и выполните:

engine-setup --offline

Сценарий engine-setup задаст вопросы по конфигурации. Отвечайте согласно вашей ситуации либо используйте файл с ответами.

Введите "Yes" после нижеследующего вопроса engine-setup:

Renew certificates? (Yes, No) [Yes]:

Только для виртуализированного ЦУ: войдите в систему на хосте и отключите глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=none

Автоматизация задач конфигурирования с помощью Ansible

Ansible — это средство автоматизации, используемое при настройке систем, развёртывании ПО и выполнении последовательных обновлений. В ROSA Virtualization включена ограниченная версия Ansible для автоматизации таких задач пост-установки, как установка и настройка дата-центров, управление пользователями или действия с виртуальными машинами.

Ansible, по сравнению с различными REST API и SDK, предоставляет более простой способ автоматизации конфигурирования системы ROSA Virtualization

Различные варианты установки Ansible, а также сведения по работе с Ansible смотрите в документации Ansible.

Пользователи и роли

Что такое пользователи

В системе ROSA Virtualization существует два типа доменов пользователей:

локальный домен;
внешний домен.

Во время процесса установки виртуализированного ЦУ создаётся домен по умолчанию с названием internal, а также пользователь по умолчанию admin.

Дополнительных пользователей в домене internal можно создавать с помощью утилиты ovirt-aaa-jdbc-tool. Учётные записи, создаваемые в локальных доменах, называются "локальными пользователями". Также к окружению ROSA Virtualization можно присоединять внешние серверы каталогов, такие как Active Directory, OpenLDAP и многие другие поддерживаемые серверы, и использовать их в качестве внешних доменов. Учётные записи, создаваемые во внешних доменах, называются "пользователями каталогов".

Как локальным пользователям, так и пользователям каталогов необходимо присваивать соответствующие роли и полномочия на Портале администрирования, для того чтобы эти пользователи могли функционировать в окружении. Существует два основных типа ролей пользователя: конечный пользователь и администратор. Роль конечного пользователя использует и управляет виртуальными ресурсами с Портала ВМ. Роль администратора поддерживает системную инфраструктуру с Портала администрирования. Эти роли можно присваивать пользователям как для работы с отдельными ресурсами, такими как виртуальные машины или хосты, так и для работы с иерархией объектов, например, с кластерами и дата-центрами.

Введение в серверы каталогов

Во время установки СУСВ создаёт пользователя admin в домене internal. Этот пользователь также называется admin@internal. Назначение этой учётной записи — использование во время создания начальной конфигурации окружения и для устранения неполадок в работе. После присоединения внешнего сервера каталогов, добавления пользователей каталога и присвоения им соответствующих ролей и полномочий учётную запись admin@internal можно отключить, если она больше не нужна.

Поддерживаемые серверы каталогов

Поддерживаются следующие серверы каталогов:

389ds;
389ds RFC-2307 Schema;
Active Directory;
IBM Security Directory Server;
IBM Security Directory Server RFC-2307 Schema;
FreeIPA;
iDM;
Novell eDirectory RFC-2307 Schema;
OpenLDAP RFC-2307 Schema;
OpenLDAP Standard Schema;
Oracle Unified Directory RFC-2307 Schema;
RFC-2307 Schema (Generic);
Red Hat Directory Server (RHDS);
Red Hat Directory Server (RHDS) RFC-2307 Schema;
iPlanet.

Примечание — Если в качестве сервера каталогов используется Active Directory, а в создании шаблонов и ВМ планируется использовать sysprep, то в этом случае пользователю-администратору системы ROSA Virtualization должен быть делегирован контроль над:

присоединением компьютеров к домену;
изменением членства в группах.

Настройка внешнего поставщика LDAP

Создание конфигурации внешнего поставщика LDAP (интерактивная установка)

Расширение ovirt-engine-extension-aaa-ldap даёт пользователям возможность легко настроить параметры их внешнего каталога. Расширение ovirt-engine-extension-aaa-ldap поддерживает множество различных типов серверов LDAP, а для помощи в настройке большинства типов LDAP предоставляется интерактивный сценарий установки.

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

Пример для Active Directory см. в п. Присоединение Active Directory.

Предварительные условия для настройка внешнего поставщика LDAP

Должно быть известно доменное имя сервера DNS или сервера LDAP.
Для настройки защищённого соединения между сервером LDAP и диспетчером убедитесь в том, что был подготовлен сертификат удостоверяющего центра в формате PEM.
Необходимо иметь как минимум одну пару "имя учётной записи ‒ пароль" для выполнения поисковых запросов и запросов по входам в систему в Active Directory.

Последовательность действий по созданию конфигурации внешнего поставщика LDAP:

Для начала интерактивной установки запустите команду:

ovirt-engine-extension-aaa-ldap-setup

Выберите тип LDAP, введя соответствующий номер. Если схема сервера LDAP неизвестна, выберите стандартную схему для имеющегося типа сервера LDAP. Для Active Directory следуйте последовательности действий для присоединения Active Directory.
Для принятия значений по умолчанию и конфигурации разрешения доменного имени для имени сервера LDAP нажмите Enter:

Available LDAP implementations:
- 389ds
- 389ds RFC-2307 Schema 3 ‒ Active Directory
- IBM Security Directory Server
IBM Security Directory Server RFC-2307 Schema 6 ‒ IPA
Novell eDirectory RFC-2307 Schema 8 ‒ OpenLDAP RFC-2307 Schema
- OpenLDAP Standard Schema
Oracle Unified Directory RFC-2307 Schema 11 ‒ RFC-2307 Schema (Generic)
- RHDS
- RHDS RFC-2307 Schema
- iPlanet Please select:

Выберите метод для политики DNS:

It is highly recommended to use DNS resolution for LDAP server.
If for some reason you intend to use hosts or plain address disable DNS usage. Use DNS (Yes, No) [Yes]:

Для варианта 1 серверы DNS, перечисленные в /etc/resolv.conf используются для разрешения адреса IP. Убедитесь в том, что файл /etc/resolv.conf обновлён до корректных значений серверов DNS.
Для варианта 2 введите полное доменное имя (FQDN) или IP-адрес сервера LDAP. Для обнаружения имени домена можно использовать команду dig и запись SRV. Запись SRV имеет следующий формат:

_service._protocol.domain_name

Пример:

dig _ldap._tcp.example.ru SRV.

Для варианта 3 введите список серверов LDAP, разделённых пробелами. Используйте либо полные доменные имена серверов, либо их IP-адреса. Данная политика предоставляет балансировку нагрузки между серверами LDAP. Запросы распределяются между всеми серверами LDWP согласно алгоритму циклического перебора.
Для варианта 4 укажите список серверов LDAP, разделённых пробелами. Используйте либо полное доменное имя серверов, либо их IP-адреса. Данная политика настраивает первый сервер LDAP в качестве сервера по умолчанию, отвечающего на запросы. Если первый сервер недоступен, запрос переходит следующему серверу в списке.

- Single server
- DNS domain LDAP SRV record
- Round-robin between multiple hosts
- Failover between multiple hosts Please select:

Выберите метод защищённого соединения, поддерживаемый имеющимся сервером LDAP, и укажите этот метод для получения сертификата ЦС в формате PEM:

File ‒ даёт возможность указать полный путь до сертификата.
URL ‒ даёт возможность указать адрес URL сертификата.
Inline ‒ даёт возможность вставить содержимое сертификата в терминал.
System ‒ даёт возможность указать местоположение по умолчанию для всех файлов ЦС.
Insecure ‒ пропускает проверку сертификата, но подключение по-прежнему шифруется с использованием TLS TLS.

NOTE:
It is highly recommended to use secure protocol to access the LDAP server. Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol.
Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: startTLS
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure):
Please enter the password:

Примечание — LDAPS — это защищённый протокол LDAP (Lightweight Directory Access Protocol Over Secure Socket Links). Для подключений SSL выбирайте параметр ldaps.

Введите отличительное имя (DN) пользователя поиска. Этот пользователь должен иметь полномочия для просмотра всех пользователей и групп на сервер каталогов и должен быть указан в примечаниях LDAP. Если разрешается анонимный поиск, просто нажмите клавишу Enter:

Enter search user DN (for example uid=username,dc=example,dc=com or leave empty for anonymous): uid=user1,ou=Users,ou=department-1,dc=example,dc=com
Enter search user password:

Введите отличительное имя базы:

Please enter base DN (dc=example,dc=ru) [dc=example,dc=ru]: ou=department- 1,dc=example,dc=ru

Если для ВМ планируется настроить единый вход, выберите Yes. Обратите внимание, что этот вариант не может быть использован параллельно с единым входом на Портал администрирования. Сценарий напомнит, что имя профиля должно совпадать с именем домена. И далее потребуется следовать инструкциям раздела "Настройка единого входа для ВМ" в Руководстве по управлению ВМ.

Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:

Укажите имя профиля. "Имя" профиля является видимым для пользователей на странице входа в систему. В данном примере используется example.ru.

Примечание — Чтобы переименовать профиль после завершения настройки домена, отредактируйте атрибут ovirt.engine.aaa.authn.profile.name в файле /etc/ovirt-engine/extensions.d/example.ru.-authn.properties. Для применения изменений перезапустите службу ovirt-engine.

Please specify profile name that will be visible to users: example.ru

Примечание — Пользователь, впервые выполняющий вход в систему, должен выбрать профиль в выпадающем списке "Профиль" (рисунок 173). Эта информация сохранится в файлах cookie браузера и будет автоматически указана в следующий раз.

Рисунок 173 ‒ Страница входа в систему на портале администрирования

Протестируйте возможность входа в систему, чтобы убедиться в том, что сервер LDAP корректно подключён к ROSA Virtualization. В запросе на вход укажите имя пользователя и пароль:

NOTE:
It is highly recommended to test drive the configuration before applying it into engine. Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Please provide credentials to test login flow: Enter user name:
Enter user password:
[ INFO ] Executing login sequence…
…
[ INFO ] Login sequence executed successfully

Проверьте корректность информации пользователя. Если она неверна, выберите "Abort":

Please make sure that user details are correct and group membership meets expectations (search for PrincipalRecord and GroupRecord titles).
Abort if output is incorrect.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]:

Рекомендуется вручную протестировать функционал поиска. Для создания запроса выберите "Principal" для учётных записей пользователей или "Group" ‒ для учётных записей групп. Если также должна выводиться информация об учётной записи группы пользователя, выберите значение "Yes" для пункта "Resolve Groups". Будет создано и выведено на экран три конфигурационных файла.

Select test sequence to execute (Done, Abort, Login, Search) [Search]: Search
Select entity to search (Principal, Group) [Principal]: Term to search, trailing '*' is allowed: testuser1 Resolve Groups (Yes, No) [No]:

Для завершения настройки выберите "Done":

Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Done
[ INFO ] Stage: Transaction setup [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up CONFIGURATION SUMMARY
Profile name is: example.ru
The following files were created:
/etc/ovirt-engine/aaa/example.ru.properties
/etc/ovirt-engine/extensions.d/example.ru.properties
/etc/ovirt-engine/extensions.d/example.ru-authn.properties  [ INFO ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20171004101225- mmneib.log:
[ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination

Перезапустите службу ovirt-engine. Созданный профиль теперь доступен на страницах входа в систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учётной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в систему на Портале ВМ, обратитесь к сведениям в п. Администрирование задач пользователей на Портале администрирования.

systemctl restart ovirt-engine.service

Примечание — Дополнительную информацию смотрите в файле README расширения для аутентификации и авторизации в LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Присоединение Active Directory

Предварительные условия для присоединения к Active Directory:

Администратору должно быть известно имя Active Directory

Примечание — Примеры часто встречающихся конфигураций Active Directory, которые нельзя создать с помощью утилиты ovirt-engine-extension-aaa-ldap-setup, можно найти в файле /usr/share/ovirt-engine-extension-aaa-ldap/examples/README.md.

Необходимо либо добавить сервер DNS, который может разрешать имя леса Active Directory в файл /etc/resolv.conf на машине диспетчера виртуализации, либо записать серверы DNS Active Directory и затем указать их по запросу сценария интерактивной установки.
Для настройки защищённого соединения между сервером LDAP и машиной диспетчера убедитесь в том, что был подготовлен сертификат ЦС в формате PEM. Подробности см. в разделе 4.2.6.6.
В случае если анонимный поиск не поддерживается, в Active Directory должен быть доступен пользователь с полномочиями на просмотр всех пользователей и групп для выполнения поиска. Запишите отличительное имя (DN) этого пользователя. Не используйте пользователя Active Directory с административными полномочиями.
Для выполнения поисковых запросов и запросов по входам в систему в Active Directory необходимо иметь как минимум одну пару "имя учётной записи ‒ пароль".
Если при развёртывании Active Directory охватывается несколько доменов, ознакомьтесь с ограничениями, указанными в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.

Последовательность действий по присоединению к серверу Active Directory:

Для начала интерактивной установки запустите команду:

ovirt-engine-extension-aaa-ldap-setup

Выберите тип LDAP, введя соответствующий номер. Вопросы, касающиеся LDAP и выводимые сценарием после этого шага, зависят от типа LDAP:

Available LDAP implementations:
- 389ds
- 389ds RFC-2307 Schema
- Active Directory
- IBM Security Directory Server
- IBM Security Directory Server RFC-2307 Schema
- IPA
- Novell eDirectory RFC-2307 Schema
- OpenLDAP RFC-2307 Schema
- OpenLDAP Standard Schema
- Oracle Unified Directory RFC-2307 Schema
- RFC-2307 Schema (Generic)
- RHDS
- RHDS RFC-2307 Schema
- iPlanet
Please select: 3

Укажите имя леса Active Directory. Если DNS диспетчера виртуализации не разрешает имя леса, сценарий предложит указать список имён серверов DNS для Active Directory через пробел:

Please enter Active Directory Forest name: ad-example.test.ru
[ INFO ] Resolving Global Catalog SRV record for ad-example.test.ru
[ INFO ] Resolving LDAP SRV record for ad-example.test.ru

Выберите метод защиты соединения, поддерживаемый сервером LDAP, а также укажите способ получения сертификата центра сертификации в формате PEM. Вариант File даёт возможность указать полный путь до сертификата. Вариант URL даёт возможность указать адрес URL сертификата. Вариант Inline используется для вставки содержимого сертификата в консольную строку. Вариант System даёт возможность указать путь до местоположения всех файлов центра сертификации. Вариант Insecure даёт возможность использовать startTLS в незащищённом режиме.

NOTE:
It is highly recommended to use secure protocol to access the LDAP server. Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol. Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: startTLS
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure): File
Please enter the password:

Примечание — LDAPS — это защищённый протокол LDAP (Lightweight Directory Access Protocol Over Secure Socket Links). Для подключений SSL выбирайте параметр ldaps.

Введите отличительное имя (DN) пользователя поиска. Этот пользователь должен иметь полномочия для просмотра всех пользователей и групп на сервер каталогов, и должен быть указан в примечаниях LDAP. Если разрешается анонимный поиск, просто нажмите клавишу Enter:

Enter search user DN (empty for anonymous): cn=user1,ou=Users,dc=test,dc=ru
Enter search user password:

Укажите, нужно ли использовать единый вход для ВМ. Эта возможность используется по умолчанию, но её невозможно использовать параллельно с настроенным единым входом на Портал администрирования. Сценарий напомнит, что имя профиля должно совпадать с именем домена. И далее потребуется следовать инструкциям раздела "Настройка единого входа для ВМ" в Руководстве по управлению ВМ:

Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:

Укажите имя профиля. "Имя" профиля является видимым для пользователей на странице входа в систему. В данном примере используется test.ru:

Please specify profile name that will be visible to users:test.ru

Примечание — Пользователь, впервые выполняющий вход в систему, должен выбрать профиль в выпадающем списке "Профиль" (рисунок 174). Эта информация сохранится в файлах cookie браузера и будет автоматически указана в следующий раз.

Рисунок 174 ‒ Страница входа в систему на Портале администрирования

Протестируйте возможность входа в систему и поиск, чтобы убедиться в том, что сервер LDAP корректно подключён к окружению ROSA Virtualization. В запросе на вход в систему укажите имя пользователя и пароль. Для создания запроса выберите "Principal" для учётных записей пользователей или "Group" ‒ для учётных записей групп. Если также должна выводиться информация об учётной записи группы пользователя, выберите значение "Yes" для пункта "Resolve Groups". Для завершения настройки выберите "Done". Будет создано и выведено на экран три конфигурационных файла:

NOTE:
It is highly recommended to test drive the configuration before applying it into engine. Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Login Enter search user name: testuser1
Enter search user password:
[ INFO ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Search Select entity to search (Principal, Group) [Principal]:
Term to search, trailing '*' is allowed: testuser1
Resolve Groups (Yes, No) [No]:
[ INFO ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Done [ INFO ] Stage: Transaction setup
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up CONFIGURATION SUMMARY
Profile name is: test.ru
The following files were created:
/etc/ovirt-engine/aaa/test.ru.properties
/etc/ovirt-engine/extensions.d/test.ru-authz.properties
/etc/ovirt-engine/extensions.d/test.ru-authn.properties  [ INFO ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20160114064955- 1yar9i.log:
[ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination

Созданный профиль теперь доступен на страницах входа в систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учётной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в систему на Портале ВМ, обратитесь к сведениям в п. Администрирование задач пользователей на Портале администрирования.

Примечание — Дополнительные сведения смотрите в файле README расширения аутентификации и авторизации LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Настройка внешнего поставщика LDAP (вручную)

Расширение ovirt-engine-extension-aaa-ldap использует протокол LDAP для получения доступа к серверам каталогов и является полностью настраиваемым. Если не планируется настройка одноразового входа на Портал ВМ или Портал администрирования, то аутентификация Kerberos не требуется.

Если интерактивный способ установки в предыдущем разделе не предоставляет всех нужных возможностей, то файлы конфигурации для присоединения сервера LDAP можно изменить вручную. В последовательности действий ниже используются базовые сведения. Конкретные значения зависят от исходных условий.

Последовательность действий по настройке внешнего поставщика LDAP:

Установите пакет расширения LDAP на диспетчере ROSA Virtualization:

dnf install ovirt-engine-extension-aaa-ldap

Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для Active Directory (ad) и других типов каталогов (simple). В данном примере используется шаблон simple:

cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. \
/etc/ovirt-engine

Переименуйте файлы конфигурации для соответствия имени профиля, который должен быть видимым для пользователей на страницах входа в систему Порталов ВМ и администрирования:

mv /etc/ovirt-engine/aaa/profile1.properties \
/etc/ovirt-engine/aaa/example.properties
mv /etc/ovirt-engine/extensions.d/profile1-authn.properties \
/etc/ovirt- engine/extensions.d/example-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties  \
/etc/ovirt- engine/extensions.d/example-authz.properties

Измените файл конфигурации LDAP property, раскомментировав строки с типом сервера LDAP и обновив информацию в полях домена и пароля:

vi /etc/ovirt-engine/aaa/example.properties

Пример профиля: раздел server LDAP:

Select one #
include = <openldap.properties> #include = <389ds.properties> #include = <rhds.properties> #include = <ipa.properties> #include = <iplanet.properties>
#include = <rfc2307-389ds.properties> #include = <rfc2307-rhds.properties> #include = <rfc2307-openldap.properties> #include = <rfc2307-edir.properties> #include = <rfc2307-generic.properties>
Server #
vars.server = ldap1.company.com
Search user and its password. #
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com vars.password = 123456
pool.default.serverset.single.server = ${global:vars.server} pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password}

При использовании протоколов TLS или SSL для обмена информацией с сервером LDAP получите сертификат ЦС для сервера LDAP и с его помощью создайте файл открытого ключа. Раскомментируйте строки, указанные ниже, и укажите полный путь к открытому ключу и паролю доступа к файлу.

Примечание — Дополнительные сведения о создании файла хранения открытого ключа смотрите в разделе "Настройка подключения SSL или TSL между диспетчером и сервером LDAP".

Пример профиля: раздел keystore:

Create keystore, import certificate chain and uncomment
if using tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
pool.default.ssl.truststore.password = password

Просмотрите файл параметров аутентификации. "Имя" профиля, видимое пользователям на страницах входа в систему на Портале администрирования и на Портале ВМ, определяется файлом ovirt.engine.aaa.authn.profile.name. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.

vi /etc/ovirt-engine/extensions.d/example-authn.properties

Пример файла конфигурации аутентификации:

ovirt.engine.extension.name = example-authn ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = example ovirt.engine.aaa.authn.authz.plugin = example-authz
config.profile.file.1 = ../aaa/example.properties

Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию:

vi /etc/ovirt-engine/extensions.d/example-authz.properties

Пример файла конфигурации авторизации:

ovirt.engine.extension.name = example-authz ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/example.properties

Установите соответствующие права доступа и укажите владельца файла профиля:

chown ovirt:ovirt /etc/ovirt-engine/aaa/example.properties
chmod 600 /etc/ovirt-engine/aaa/example.properties

Перезапустите службу engine:

systemctl restart ovirt-engine.service

Созданный профиль example теперь доступен на страницах входа в систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учётной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в систему на Портале ВМ, обратитесь к сведениям в разделе "Управление пользовательскими задачами на диспетчере".

Примечание — Дополнительную информацию смотрите в файле README расширения для аутентификации и авторизации в LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Удаление внешнего поставщика LDAP

В данной последовательности показывается процесс удаления настроенного внешнего поставщика LDAP и его пользователей.

Последовательность действий по удалению внешнего поставщика LDAP:

Удалите файлы конфигурации поставщика LDAP, заменив имя по умолчанию profile1:

rm /etc/ovirt-engine/extensions.d/profile1-authn.properties
rm /etc/ovirt-engine/extensions.d/profile1-authz.properties
rm /etc/ovirt-engine/aaa/profile1.properties

Перезапустите службу ovirt-engine:

systemctl restart ovirt-engine

Во вкладке "Пользователи" Портала администрирования выберите пользователей этого поставщика (пользователи со значением profile1-authz для параметра "Поставщик авторизации") и нажмите Удалить.

Настройка единого входа для LDAP и Kerberos

Механизм единого входа даёт возможность пользователям войти в систему на Портале ВМ или Портале администрирования без повторного ввода пароля. Данные учётной записи для аутентификации получаются с сервера Kerberos. Для настройки единого входа на Портале администрирования необходимо настроить два расширения: ovirt-engine-extension-aaa-misc и ovirt-engine-extension-aaa-ldap, а также два модуля Apache: mod_auth_gssapi и mod_session. Есть возможность настроить единый вход без использования Kerberos, но она выходит за рамки данного руководства.

Примечание — При активированном едином входе на Портал ВМ невозможен единый вход в виртуальные машины. При активированном едином входе на Портал ВМ порталу нет необходимости принимать пароль, поэтому невозможно передать этот пароль для входа в систему на ВМ.

В данном примере предполагается, что:

На существующем центре распределения ключей (KDC) используется версия MIT Kerberos 5.
Для сервера KDC имеются полномочия администратора.
Клиент Kerberos установлен на СУСВ и на ВМ пользователя.
Для создания принципалов служб Kerberos и файлов таблиц ключей использовалась утилита kadmin.

Последовательность действий для настройки единого входа для LDAP и Kerberos:

На сервере KDC:
- На машине диспетчера ROSA Virtualization создайте принципала службы и файл keytab для службы Apache.
На диспетчере ROSA Virtualization:
- Установите пакеты расширений аутентификации и авторизации, а также модуль аутентификации Kerberos для Apache.
- Настройте файлы расширений.

Настройка Kerberos для службы Apache

Для настройки Kerberos для службы Apache выполните следующие действия:

На сервере KDC используйте утилиту kadmin для создания принципала для службы Apache на машине диспетчера виртуализации. Принципал службы — это ссылочный идентификатор службы Apache.

kadmin
kadmin> addprinc -randkey HTTP/fqdn-of-rhevm@REALM.COM

Создайте файл keytab для службы Apache. В этом файле хранится общий секретный ключ.

Примечание — Во время создания и восстановления резервных копий команде engine-backup указывается файл /etc/httpd/http.keytab. Если файлу keytab было дано другое имя, убедитесь, что для него была создана и восстановлена резервная копия.

kadmin> ktadd -k /tmp/http.keytab HTTP/fqdn-of-rhevm@REALM.COM
kadmin> quit

Скопируйте файл keytab с сервера KDC на машину диспетчера виртуализации:

scp /tmp/http.keytab root@rhevm.example.com:/etc/httpd

Настройка единого входа для Портала ВМ или Портала администрирования

Для настройки единого входа для Портала ВМ или Портала администрирования:

На машине диспетчера виртуализации установите соответствующие права доступа и укажите владельца файла таблицы ключей:

chown apache /etc/httpd/http.keytab
chmod 400 /etc/httpd/http.keytab

Установите пакет расширения для аутентификации, пакет расширения для LDAP, а также модули Apache mod_auth_gssapi и mod_session:

dnf install ovirt-engine-extension-aaa-misc \
ovirt-engine-extension-aaa-ldap mod_auth_gssapi mod_session

Скопируйте файл шаблона конфигурации SSO в каталог /etc/ovirt-engine. Файлы шаблонов доступны для Active Directory (ad-sso) и для других типов каталогов (simple-sso). В данном примере используется шаблон конфигурации simple SSO:

cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple-sso/. \
/etc/ovirt-engine

Переместите файл ovirt-sso.conf в каталог настройки Apache:

Примечание — Во время создания и восстановления резервных копий команде engine-backup указывается файл /etc/httpd/conf.d/ovirt-sso.conf. Если этому файлу было дано другое имя, убедитесь, что для него была создана и восстановлена резервная копия.

mv /etc/ovirt-engine/aaa/ovirt-sso.conf /etc/httpd/conf.d

Просмотрите файл метода аутентификации. Этот файл не нужно редактировать, поскольку данные области автоматически получаются из файла keytab.

vi /etc/httpd/conf.d/ovirt-sso.conf

Пример файла метода аутентификации:

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http- auth)|^/ovirt-engine/api>
<If "req('Authorization') !~ /^(Bearer|Basic)/i"> RewriteEngine on
RewriteCond %{LA-U:REMOTE_USER} ^(.*)$ RewriteRule ^(.*)$ ‒ [L,NS,P,E=REMOTE_USER:%1] RequestHeader set X-Remote-User %{REMOTE_USER}s
AuthType GSSAPI AuthName "Kerberos Login"
Modify to match installation GssapiCredStore keytab:/etc/httpd/http.keytab GssapiUseSessions On
Session On
SessionCookieName ovirt_gssapi_session path=/private;httponly;secure;
Require valid-user
ErrorDocument 401 "<html><meta http-equiv=\"refresh\" content=\"0; url=/ovirt- engine/sso/login-unauthorized\"/><body><a href=\"/ovirt-engine/sso/login- unauthorized\">Here</a></body></html>"
</If>
</LocationMatch>

Переименуйте файлы конфигурации для соответствия с именем профиля, который должен быть видимым для пользователей на страницах входа в систему Порталов ВМ и администрирования:

mv /etc/ovirt-engine/aaa/profile1.properties \
/etc/ovirt-engine/aaa/example.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-authn.properties \
/etc/ovirt-engine/extensions.d/example-http-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-mapping.properties \
/etc/ovirt-engine/extensions.d/example-http-mapping.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties \
/etc/ovirt- engine/extensions.d/example-authz.properties

Измените файл конфигурации LDAP property, убрав комментарии со строк с типом сервера LDAP и обновив информацию в полях домена и пароля:

vi /etc/ovirt-engine/aaa/example.properties

Пример профиля: раздел сервера LDAP:

Select one
include = <openldap.properties>
#include = <389ds.properties>
#include = <rhds.properties>
#include = <ipa.properties>
#include = <iplanet.properties>
#include = <rfc2307-389ds.properties>
#include = <rfc2307-rhds.properties>
#include = <rfc2307-openldap.properties>
#include = <rfc2307-edir.properties>
#include = <rfc2307-generic.properties>
Server
#vars.server = ldap1.company.com
Search user and its password. #
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com vars.password = 123456
pool.default.serverset.single.server = ${global:vars.server} pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password}

Если для обмена информацией с сервером LDAP используются протоколы TLS или SSL, получите сертификат корневого центра сертификации для сервера LDAP и с его помощью создайте файл открытого ключа. Раскомментируйте строки, указанные ниже, и укажите полный путь к открытому ключу и паролю доступа к файлу.

Примечание — Дополнительные сведения о создании файла хранения открытого ключа смотрите в разделе "Настройка подключения SSL или TLS между диспетчером и сервером LDAP".

Пример профиля: раздел keystore:

Create keystore, import certificate chain and uncomment
if using ssl/tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
pool.default.ssl.truststore.password = password

Просмотрите файл параметров аутентификации. "Имя" профиля, видимое пользователям на страницах входа в систему на Ппортале администрирования и на портале ВМ, определяется файлом ovirt.engine.aaa.authn.profile.name. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.

vi /etc/ovirt-engine/extensions.d/example-http-authn.properties

Пример файла параметров аутентификации:

ovirt.engine.extension.name = example-http-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.http.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = example-http ovirt.engine.aaa.authn.authz.plugin = example-authz ovirt.engine.aaa.authn.mapping.plugin = example-http-mapping config.artifact.name = HEADER
config.artifact.arg = X-Remote-User

Просмотрите файл параметров авторизации. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.

vi /etc/ovirt-engine/extensions.d/example-authz.properties

Пример файла параметров авторизации:

ovirt.engine.extension.name = example-authz ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/example.properties

Просмотрите файл конфигурации отображения аутентификации. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Расширение имени профиля конфигурации должно совпадать со значением ovirt.engine.aaa.authn.mapping.plugin в файле конфигурации аутентификации. Для всех полей можно оставить значения по умолчанию.

vi /etc/ovirt-engine/extensions.d/example-http-mapping.properties

Пример файла параметров отображения аутентификации:

ovirt.engine.extension.name = example-http-mapping ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.mapping.MappingExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Mapping config.mapAuthRecord.type = regex
config.mapAuthRecord.regex.mustMatch = true
config.mapAuthRecord.regex.pattern  =  ^(?<user>.*?)((\\\\(?<at>@)(?<suffix>.*?)@.*)|(?
<realm>@.*))$
config.mapAuthRecord.regex.replacement = ${user}${at}${suffix}

Установите соответствующие права доступа и укажите владельца файла конфигурации:

chown ovirt:ovirt /etc/ovirt-engine/aaa/example.properties
chown ovirt:ovirt \
/etc/ovirt-engine/extensions.d/example-http-authn.properties
chown ovirt:ovirt \
/etc/ovirt-engine/extensions.d/example-http-mapping.properties
chown ovirt:ovirt /etc/ovirt-engine/extensions.d/example-authz.properties
chmod 600 /etc/ovirt-engine/aaa/example.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-authn.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-mapping.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-authz.properties

Перезапустите службу Apache и службу ovirt-engine:

systemctl restart httpd.service
systemctl restart ovirt-engine.service

Авторизация пользователей

Модель авторизации пользователей

Управление авторизацией в системе ROSA Virtualization базируется на сочетании трёх составляющих:

Пользователь, выполняющий действие.
Тип этого выполняемого действия.
Объект, над которым выполняется это действие.

Действия пользователей

Чтобы действие выполнилось успешно, у пользователя должны быть соответствующие полномочия на объект, над которым выполняется действие. У каждого типа действий есть соответствующие полномочия.

Некоторые действия выполняются более чем над одним объектом. Копирование шаблона в другой домен хранения, например, влияет и на шаблон и целевой домен хранения. Пользователь, выполняющий это действие, должен иметь полномочия на все объекты, подпадающие под влияние этого действия.

Администрирование задач пользователей на Портале администрирования

Окно "Параметры учётной записи"

В окне "Администрирование → Параметры учётной записи" можно просматривать или редактировать следующие параметры пользователя Портала администрирования:

Вкладка "Общее":
Имя пользователя (только для чтения).
E-mail (только для чтения).
Домашняя страница:
По умолчанию ‒ #dashboard-main.
Настраиваемая домашняя страница: введите только последнюю часть URL, включая символ "#"., например #vms-snapshots;name-testVM.
Последовательная консоль.
Открытый ключ пользователя — введите открытый ключ SSH, используемый для доступа к диспетчеру с помощью последовательной консоли.
Таблицы.
Параметры сохранения состояния сетки — сохранение параметров столбцов сетки на сервере.
Вкладка "Подтверждения":
Показывать диалог подтверждения при заморозке ВМ — включение показа диалога подтверждения заморозки ВМ.

Добавление пользователей и присвоение полномочий для работы на Портале виртуальных машин

Роли и полномочия можно присваивать только ранее созданным пользователям. Роли и полномочия, присваиваемые в данной процедуре, дают пользователям права на выполнение входа в систему на Портале ВМ и на создание виртуальных машин. Процедура также применима и для учётных записей групп.

Добавление пользователей и присвоение полномочий

Последовательность действий по добавлению пользователей и присвоению полномочий для работы на Портале виртуальных машин:

На панели заголовков нажмите "Администрирование → Настроить", чтобы открыть окно "Параметры".
Нажмите Системные полномочия.
Нажмите Добавить, откроется окно "Добавить системные полномочия пользователю".
В разделе "Поиск" выберите профиль. Профиль — это домен, в котором нужно выполнить поиск. В поле поиска введите имя или часть имени и нажмите Выполнить. Как вариант, нажмите Выполнить, чтобы просмотреть список всех пользователей и групп.
Отметьте флажками нужных пользователей или нужные группы.
В списке "Присваиваемая роль" выберите подходящую роль. Роль UserRole даёт учётной записи пользователя полномочия на выполнения входа в систему на Портале ВМ.
Нажмите OK.

Выполните вход в систему на Портале ВМ, чтобы убедиться, что у пользователя есть полномочия на вход.

Просмотр сведений о пользователе

Последовательность действий по просмотру сведений о пользователе:

Нажмите "Администрирование → Пользователи", чтобы просмотреть список авторизованных пользователей.
Нажмите на имя пользователя, чтобы перейти к подробному просмотру; обычно это вкладка "Общее", где показываются такие сведения, как имя домена, почтовый адрес и статус пользователя.
В других вкладках можно просмотреть группы, полномочия, квоты и события пользователя.

Чтобы, например, просмотреть группы, к которым принадлежит пользователь, перейдите на вкладку "Группы каталогов".

Просмотр полномочий пользователя для работы с ресурсами

Администратор может присваивать пользователям полномочия на работу с конкретными ресурсами или иерархией ресурсов. Для каждого ресурса можно просмотреть присвоенных пользователей и их полномочия.

Последовательность действий по просмотру полномочий пользователя для работы с ресурсами:

Найдите и нажмите на имя ресурса, чтобы перейти к подробному просмотру
Перейдите на вкладку "Полномочия", чтобы просмотреть список присвоенных пользователей, их роли, а также наследуемые полномочия на выбранные ресурсы.

Удаление пользователей

Если учётная запись пользователя больше не нужна, удалите её из системы ROSA Virtualization.

Последовательность действий по удалению пользователей:

Нажмите "Администрирование → Пользователи", чтобы просмотреть список авторизованных пользователей.
Выберите удаляемого пользователя. Убедитесь в том, что от имени пользователя не выполняются никакие ВМ.
Нажмите Удалить, затем нажмите ОК.

Пользователь будет удалён из системы ROSA Virtualization, но не с внешнего каталога.

Просмотр пользователей, выполнивших вход в систему

Администратор может просматривать пользователей, на текущий момент выполнивших вход в систему, а также время длительности их сеанса и другие подробности. Нажмите "Администрирование → Активные сеансы пользователей", чтобы просмотреть "ID сеанса в БД", "Имя пользователя", "Поставщика авторизации", "ID пользователя", "IP источника", "Время начало сеанса" и "Активное время последнего сеанса" каждого из пользователей, выполнивших вход в систему.

Завершение сеанса работы пользователя

Администратор может завершать сеансы работы пользователей, выполнивших вход в систему.

Для завершения сеанса работы пользователя:

Нажмите "Администрирование → Активные сеансы" пользователей.
Выберите сеанс пользователя, который необходимо завершить.
Нажмите Завершить сеанс.
Нажмите OK.

Администрирование задач пользователей в консольном режиме

С помощью утилиты ovirt-aaa-jdbc-tool можно управлять учётными записями пользователей во внутреннем домене. Изменения, внесённые при помощи этой утилиты, применяются мгновенно и не требуют перезапуска службы ovirt-engine. Полный список параметров для работы с пользователями можно просмотреть в выводе команды:

ovirt-aaa-jdbc-tool user —help

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

Примечание — Администратор должен выполнить вход в систему на машине СУСВ.

Создание нового пользователя

Администратор может создавать учётные записи новых пользователей. Дополнительный параметр --attribute передаёт подробности. Чтобы просмотреть полный список параметров, выполните ovirt-aaa-jdbc-tool user add --help.

ovirt-aaa-jdbc-tool user add test1 \
--attribute=firstName=John --attribute=lastName=Doe
adding user test1...
user added successfully

Теперь только что созданного пользователя можно добавить на Портал администрирования и присвоить ему подходящие роли и полномочия. Подробности см. в п. Администрирование задач пользователей на Портале администрирования.

Настройка пароля пользователя

Администратор может создавать пароли. Необходимо указать значение параметру --password-valid-to, в противном случае время истечения действия пароля по умолчанию равно текущему времени.

Формат по умолчанию: гггг-ММ-дд ЧЧ:мм:ссX, где X — значение смещения часового пояса от UTC. В данном примере значение -0800 означает время по Гринвичу (GMT) минус 8 часов. Для нулевого смещения используйте значение Z.
Дополнительные параметры см. в выводе ovirt-aaa-jdbc-tool user password-reset --help.

ovirt-aaa-jdbc-tool user password-reset test1 \
--password-valid-to="2025-08-01 12:00:00-0800"
Password:
updating user test1... user updated successfully

Примечание — По умолчанию политика паролей для учётных записей пользователей во внутренних доменах имеет следующие ограничения:

Минимум 6 символов.
При смене пароля нельзя снова назначить три предыдущих пароля.
Чтобы получить дополнительные сведения о политике паролей и других значениях по умолчанию, выполните ovirt-aaa- jdbc-tool settings show.

Сразу после обновления пароля необходимо вручную распространить изменения в ovirt-provider-ovn. В противном случае пользователь admin будет заблокирован, т.к. для синхронизации сетей из ovirt-provider-ovn диспетчер ROSA Virtualization продолжит использовать старый пароль. Для внесения нового пароля в ovirt-provider-ovn выполните следующие действия:

На портале администрирования выберите "Администрирование → Поставщики".
Выберите ovirt-provider-ovn.
Нажмите Изменить и введите новый пароль в поле "Пароль".
Нажмите Проверить, чтобы протестировать успешность аутентификации с предоставленными данными учётной записи.
В случае успешности проверки нажмите OK.

Настройка интервала истечения времени ожидания сеанса пользователя

Администратор может настроить интервал истечения времени ожидания сеанса пользователя:

engine-config --set UserSessionTimeOutInterval=integer

Предварительное шифрование паролей пользователей

С помощью сценария ovirt-engine-crypto-tool администратор может создавать предварительно зашифрованные пароли пользователей. Эта возможность удобна, если пользователи и пароли добавляются в базу данных с помощью сценариев.

Примечание — Пароли хранятся в базе данных диспетчера виртуализации в зашифрованном виде. Сценарий ovirt-engine-crypto-tool используется потому, что все пароли должны быть зашифрованы с использованием одного и того же алгоритма.

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

Выполните следующую команду:

/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode

Сценарий предложит ввести пароль.

Как вариант, чтобы зашифровать один пароль, указанный в первой строке файла, можно использовать параметр --password=file:файл. Эта возможность удобна для автоматизации. В примере ниже файл — это текстовый файл с паролем, который нужно зашифровать:

/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode \
--password=file:file

С помощью сценария ovirt-aaa-jdbc-tool с параметром --encrypted укажите новый пароль:

ovirt-aaa-jdbc-tool user password-reset test1 \
--password-valid-to="2025-08-01 12:00:00- 0800" --encrypted

Введите и подтвердите зашифрованный пароль:

Password:
Reenter password:
updating user test1...
user updated successfully

Просмотр информации о пользователях

Администратор может просматривать подробные сведения об учётных записях пользователей:

ovirt-aaa-jdbc-tool user show test1

Указанная команда выводит больше сведений, чем можно получить на экране "Администрирование → Пользователи" на Портале администрирования.

Изменение информации о пользователях

Администратор может обновлять информацию о пользователях, например почтовый адрес:

ovirt-aaa-jdbc-tool user edit test1 --attribute=email=jdoe@example.com

Удаление пользователей

Администратор может удалять учётные записи пользователей:

ovirt-aaa-jdbc-tool user delete test1

Удалите пользователя с Портала администрирования. Подробности см. в п. Администрирование задач пользователей на Портале администрирования.

Отключение внутреннего пользователя-администратора

Администратор может отключать пользователей в локальных доменах, включая пользователя admin@internal, создаваемого во время выполнения engine-setup. Перед отключением изначального пользователя admin убедитесь в том, что в окружении имеется ещё как минимум один пользователь с полными административными полномочиями.

Последовательность действий по отключению внутреннего пользователя-администратора:

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Убедитесь в том, что в окружение был добавлен ещё один пользователь с ролью SuperUser. Подробности см. в п. Администрирование задач пользователей на Портале администрирования.
Отключите изначального пользователя admin:

ovirt-aaa-jdbc-tool user edit admin --flag=+disabled

Примечание — Чтобы включить отключённого пользователя, выполните команду:

ovirt-aaa-jdbc-tool user edit username --flag=-disabled

Управление группами

С помощью утилиты ovirt-aaa-jdbc-tool можно управлять учётными записями групп во внутреннем домене. Управление учётными записями групп аналогично управлению учётными записями пользователей. Полный список возможностей для групп смотрите в выводе ovirt-aaa-jdbc-tool group --help. В данном разделе приводятся общие примеры.

Создание группы пользователей

Данная последовательность действий объясняет, как создать группу пользователей, добавить пользователей в группу и просматривать сведения о группе:

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Создайте новую группу:

ovirt-aaa-jdbc-tool group add group1

Добавьте пользователей в группу. Эти пользователи должны уже быть созданы ранее.

ovirt-aaa-jdbc-tool group-manage useradd group1 --user=test1

Примечание — Полный список параметров управления группами см. в выводе команды:

ovirt-aaa-jdbc-tool group- manage --help

Просмотрите сведения об учётной записи группы:

ovirt-aaa-jdbc-tool group show group1

Добавьте только что созданную группу на Портале администрирования и выделите группе необходимые роли и полномочия. Пользователи-участники группы наследуют роли и полномочия группы. Подробности см. в п. Администрирование задач пользователей на Портале администрирования.

Создание вложенных групп

Данная процедура объясняет, как создать группу внутри группы:

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Создайте новую группу:

ovirt-aaa-jdbc-tool group add group1

Создайте вторую группу:

ovirt-aaa-jdbc-tool group add group1-1

Добавьте вторую группу к первой:

ovirt-aaa-jdbc-tool group-manage groupadd group1 --group=group1-1

Добавьте первую группу на Портале администрирования и присвойте группе необходимые роли и полномочия. Подробности смотрите в п. Администрирование задач пользователей на Портале администрирования.

Запрос сведений о группах и пользователях

Модуль query даёт возможность запросить сведения о пользователях и группах. Полный список параметров можно посмотреть в выводе команды:

ovirt-aaa-jdbc-tool query --help

Просмотр сведений об учётных записях всех пользователей или групп

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

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Получите список сведений об учётных записях:

Учётные записи всех пользователей:

ovirt-aaa-jdbc-tool query --what=user

Учётные записи всех групп:

ovirt-aaa-jdbc-tool query --what=group

Получение списка учётных записей с применением фильтра

Данная процедура объясняет, как применять фильтры при получении списка сведений об учётных записях:

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Примените фильтр к информации об учётной записи с помощью параметра --pattern.

Получить список учётных записей с именами, начинающимися с символа j:

ovirt-aaa-jdbc-tool query --what=user --pattern="name=j*"

Получить список групп, со значением marketing атрибута department:

ovirt-aaa-jdbc-tool query --what=group --pattern="department=marketing"

Управление параметрами учётных записей

Для изменения исходных параметров учётной записи используйте модуль ovirt-aaa-jdbc-tool settings.

Обновление информации о параметрах учётной записи

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

Выполните вход в систему на машине с установленным диспетчером виртуализации.
Для просмотра всех доступных параметров выполните следующую команду:

ovirt-aaa-jdbc-tool settings show

Измените необходимые параметры:

В данном примере изначальное значение длительности сеанса пользователя (10080 минут) изменяется на 60 минут для всех учётных записей пользователей:

ovirt-aaa-jdbc-tool settings set --name=MAX_LOGIN_MINUTES --value=60

В данном примере изменяется значение числа неудачных попыток входа в систему, которые может выполнить пользователь до того, как его учётная запись будет заблокирована. Значение по умолчанию ‒ 5:

ovirt-aaa-jdbc-tool settings set --name=MAX_FAILURES_SINCE_SUCCESS \
--value=3

Примечание — Для разблокирования учётной записи пользователя выполните команду:

ovirt-aaa-jdbc-tool user unlock test1

Настройка дополнительных локальных доменов

Создание дополнительных локальных доменов, помимо изначального домена internal, также поддерживается. Это выполняется с помощью расширения ovirt-engine-extension-aaa-jdbc, дающего возможность создания более одного домена без присоединения внешних серверов каталогов, хотя такой сценарий использования не очень часто встречается в корпоративных окружениях.

Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений версий системы ROSA Virtualization: после выходов следующих версий эти домены необходимо будет обновлять вручную. Дополнительные сведения о создании дополнительных локальных доменов и об обновлении версий этих доменов смотрите в файле README, расположенном по пути /usr/share/doc/ovirt-engine-extension-aaa-jdbc-версия/README.admin.

Квоты и политика соглашения об уровне обслуживания

Что такое Quota

Quota — это утилита ограничения ресурсов, предоставляемая системой ROSA Virtualization. Quota может быть описана в виде слоя ограничений, располагающегося поверх слоя ограничений, налагаемых полномочиями пользователей.

Quota является объектом дата-центра.

Quota предоставляет возможность администраторам окружений системы ROSA Virtualization ограничивать доступ пользователей к памяти, ЦП и хранилищам. Quota определяет объём ресурсов памяти и хранилища, который администраторы могут выделить пользователям. В итоге пользователи могут расходовать только те ресурсы, которые им были выделены.

Существует два различных типа квот:

Quota времени выполнения. Эта квота ограничивает потребление ресурсов времени выполнения, таких как ЦП и память.
Quota хранилища. Эта квота ограничивает доступный объём хранилища.

У Quota, как и у SELinux, есть три режима, представленные в таблице 69.

При попытке пользователя запустить ВМ её спецификации сравниваются с допустимыми нормами хранилища и допустимыми нормами времени выполнения, указанными в применимой квоте.

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

При создании нового диска пользователем запрошенный размер диска добавляется к общему объёму дисков, покрываемых применимой квотой. Если общий объём, включая объём нового диска, превышает объём, разрешённый квотой, то диск не будет создан.

Quota допускает разделение ресурсов одного аппаратного обеспечения. Есть поддержка мягкого и жёсткого порогов. Администраторы могут использовать квоту для настройки порогов использования ресурсов. С точки зрения пользователя, эти пороги выглядят как стопроцентное использование данного ресурса. Для предотвращения сбоев при неожиданном превышении этих порогов в интерфейсе присутствует поддержка "льготного" значения, на которое может быть превышено пороговое значение в течение краткого периода времени. При превышении порога пользователю показывается предупреждение.

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

В принудительном режиме квоты виртуальные машины и диски, не имеющие присвоенных квот, не могут использоваться.

Для возможности запуска ВМ этой ВМ должна быть присвоена квота.

Для создания снимка ВМ диску, связанному с этой ВМ, должна быть присвоена квота.

При создании шаблона на базе ВМ будет предложено выбрать квоту, которую должен потреблять шаблон. Это даёт возможность указать для шаблона (и для всех будущих ВМ, которые будут созданы на базе этого шаблона) другую квоту, чем квоты, настроенные для ВМ и диска, на базе которых создаётся этот шаблон.

Общие и индивидуальные квоты

Пользователи с полномочиями SuperUser могут создавать квоты для отдельных пользователей или квоты для групп.

Для пользователей Active Directory можно настроить групповые квоты. Если группе из десяти пользователей будет назначена квота в 1 ТБ в хранилище, а один из этих десяти пользователей заполнит весь этот объём, то в таком случае квота будет превышена для всей группы, и ни один из десяти пользователей не сможет использовать хранилище, связанное с этой группой.

Квота отдельного пользователя настраивается для одного пользователя. Как только вся квота хранилища времени выполнения будет превышена отдельным пользователем, этот пользователь больше не сможет использовать хранилище, связанное с его квотой.

Расчёт квот

При назначенной пользователю или ресурсу квоте каждое действие этого потребителя или действие с ресурсом, включающим хранилище, виртуальный ЦП или память, приводит к потреблению квоты или освобождению квоты.

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

Пример расчёта квоты

Пользователь запустил ВМ с 1 виртуальным ЦП и 1024 МБ памяти. Это действие потребляет 1 виртуальный ЦП и 1024 МБ квоты, выделенной этому пользователю. После остановки этой ВМ 1 ЦП и 1024 МБ ОЗУ возвращаются обратно в квоту, присвоенную этому пользователю. Потребление квоты времени выполнения считается только во время фактического времени выполнения потребителя.

Пользователь создаёт виртуальный диск тонкого резервирования размером в 10 ГБ. Фактическое потребление дискового объёма может указывать, что используется только 3 ГБ. Но потребление квоты, тем не менее, будет составлять 10 ГБ, т.е. максимальный потенциал роста этого диска.

Включение и изменение режима квот в дата-центре

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

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

Последовательность действий по включению и изменению режима квот в дата-центре:

Нажмите "Ресурсы → Дата-центры" и выберите дата-центр.
Нажмите Изменить.
В выпадающем списке "Режим квоты" измените режим на "Принудительный".
Нажмите OK.

Если во время тестирования установить режим "Аудит", то для того, чтобы параметры квоты вступили в силу, режим необходимо сменить на "Принудительный".

Создание новых политик квотирования

Если администратор включил режим квоты либо в режиме "Аудит", либо в режиме "Принудительный", то теперь необходимо настроить политику квоты для управления потреблением ресурсов в дата-центре.

Последовательность действий по созданию новых политик квотирования:

Нажмите "Администрирование → Квота".
Нажмите Добавить.
Заполните поля "Название" и "Описание".
Выберите "Дата-центр".
В разделе "Память и ЦП" с помощью зелёного бегунка настройте "Порог кластера".
В разделе "Память и ЦП" с помощью голубого бегунка настройте "Льготу кластера".
Активируйте переключатель "Все кластеры" или переключатель "Конкретные кластеры". При выборе переключателя "Конкретные кластеры" отметьте кластеры, для которых нужно добавить политику квоты.
Нажмите Изменить, чтобы открыть окно "Изменить квоту".
В поле "Память" активируйте либо переключатель "Без ограничений" (чтобы не ограничивать использование ресурсов памяти в кластере), либо активируйте переключатель "Ограничить до", чтобы указать объём памяти, установленный для этой квоты. При выборе переключателя "Ограничить до" указывайте объём памяти в мегабайтах (МБ) в поле "МБ".
В поле "ЦП" активируйте либо переключатель "Без ограничений", либо переключатель "Ограничить до", чтобы указать объём ЦП, установленный для этой квоты. При выборе переключателя "Ограничить до" указывайте число виртуальных ЦП в поле "ЦП".
Нажмите OK в окне "Изменить квоту".
В разделе "Хранилище" с помощью зелёного бегунка настройте "Порог хранилища".
В разделе "Хранилище" с помощью голубого бегунка настройте "Льготу хранилища".
Активируйте переключатель "Все домены хранилищ" или "Конкретные домены хранилищ". При выборе переключателя "Конкретные домены хранилищ" отметьте домены хранения, для которых нужно добавить политику квоты.
Нажмите Изменить, чтобы открыть окно "Изменить квоту".
В поле "Квота хранилища" активируйте либо переключатель "Без ограничений" (чтобы не ограничивать использование ресурсов хранилища), либо активируйте переключатель "Ограничить до", чтобы указать объём хранилища, до которого пользователи будут ограничены квотой. При выборе переключателя "Ограничить до" указывайте объём размера квоты на хранилище в гигабайтах (ГБ) в поле "ГБ".
Нажмите OK в окне "Изменить квоту".
Нажмите OK в окне "Новая квота".

Описание параметров порога квоты

Параметры квот представлены в таблица 70.

При квоте, установленной в 100 ГБ со льготой в 20%, потребителям будет запрещено использование хранилища после того, как используемый ими объём хранилища достигнет 120 ГБ. Если та же самая квота имеет значение порога в 70%, тогда потребителям выводится предупреждение в момент, когда используемый ими объём превысит 70 ГБ (но остаётся возможность потреблять хранилище до тех пор, пока потребляемый объём не достигнет 120 ГБ).

Как значение "Порога", так и значение "Льготы" настраиваются относительно значения квоты. "Порог" можно представить как "мягкий предел", и при его превышении выводится предупреждение. "Льготу" можно представить как "жёсткое ограничение", и при его превышении дальнейшее потребление ресурсов хранилища становится невозможным.

Присвоение квот объектам

Для присвоения квот виртуальным машинам:

Нажмите "Ресурсы → ВМ" и выберите виртуальную машину.
Нажмите Изменить.
В выпадающем списке "Квота" выберите квоту, которую будет потреблять выбранная ВМ.
Нажмите OK.

Присвоение квоты диску

Для присвоения квоты диску:

Нажмите "Ресурсы → ВМ".
Нажмите на имя ВМ, чтобы перейти к подробному просмотру.
Перейдите на вкладку "Диски" и выберите диск, который планируется связать с квотой.
Нажмите Изменить.
В выпадающем списке "Квота" выберите квоту, которую будет потреблять выбранный виртуальный диск.
Нажмите OK.

Примечание — Для работы ВМ необходимо, чтобы для всех объектов, связанных с этой ВМ, была выбрана квота. Если квота для всех объектов не будет выбрана, ВМ не будет работать. Ошибка, которую выдаёт при этом диспетчер виртуализации, является очень общей, что затрудняет нахождение её связи с отсутствием присвоения квот объектам, связанным с виртуальной машиной. Нельзя сделать снимок ВМ, которой не была присвоена квота. Нельзя сделать шаблон на базе ВМ, виртуальным дискам которой не были присвоены квоты.

Использование квот для ограничения потребления ресурсов пользователем

Данная последовательность действий объясняет, как с помощью квот ограничить доступные пользователю ресурсы.

Последовательность действий по использованию квот для ограничения потребления ресурсов пользователем:

Выберите "Администрирование → Квота".
Нажмите на название целевой квоты, чтобы перейти к подробному просмотру.
Перейдите на вкладку "Потребители".
Нажмите Добавить.
В поле "Поиск" введите имя пользователя, которого нужно связать с квотой.
Нажмите Выполнить.
Поставьте флажок рядом с именем пользователя.
Нажмите OK.

Через некоторое время пользователь появится во вкладке "Потребители".

Редактирование квот

Данная последовательность действий объясняет, как изменять существующие квоты.

Последовательность действий по редактированию квот:

Нажмите "Администрирование → Квота" и выберите квоту.
Нажмите Изменить.
Внесите необходимые изменения.
Нажмите OK.

Удаление квот

Данная последовательность действий объясняет, как удалять квоты.

Последовательность действий по удалению квот:

Нажмите "Администрирование → Квота" и выберите квоту.
Нажмите Удалить.
Нажмите OK.

Принудительное применение политики соглашения об уровне обслуживания

Данная последовательность действий объясняет, как настроить параметры ЦП согласно соглашению об уровне обслуживания.

Последовательность действий по принудительному применению политики соглашения об уровне обслуживания:

Нажмите "Ресурсы → ВМ".
Нажмите Создать или выберите ВМ и нажмите Изменить.
Перейдите на вкладку "Выделение ресурсов".
Укажите "Ресурсы ЦП". Возможные значения: "Низкое", "Среднее", "Высокое", "Пользовательское" и "Отключено". Виртуальные машины, для которых указано "Высокое значение", получают в два раза больше ресурсов, чем ВМ, для которых указано "Среднее" значение, а ВМ со "Средним" значением получают в два раза больше ресурсов, чем ВМ, для которых указано "Низкое" значение. Значение "Отключено" указывает, что для расчёта распределения долей демон VDSM должен использовать старый алгоритм; как правило, число долей, распределяемых в этих условиях, равно 1020.

Потребление ресурсов ЦП пользователями теперь управляется настроенной политикой.

Уведомления о событиях

Настройка уведомлений о событиях на Портале администрирования

При возникновении конкретных событий в окружении, управляемом диспетчером системы ROSA Virtualization, диспетчер может послать почтовое сообщение предварительно назначенным пользователям с уведомлением об этом событии. Чтобы использовать эту возможность, необходимо настроить агент пересылки сообщений. На Портале администрирования можно настроить только почтовые уведомления. Ловушки SNMP настраиваются на машине СУСВ.

Последовательность действий по настройке уведомлений о событиях:

Убедитесь в том, что имеется доступ на почтовый сервер, который может принимать автоматизированные сообщения из виртуализированного ЦУ и доставлять их по списку адресатов.
Нажмите "Администрирование → Пользователи" и выберите пользователя.
Нажмите на "Имя" пользователя, чтобы перейти на страницу подробного просмотра.
На вкладке "Уведомления о событиях" нажмите Управление событиями.
Для просмотра событий используйте кнопку Развернуть все или отдельные кнопки развёртывания по темам.
Отметьте флажками необходимые элементы.
В поле "Получатель почты" введите почтовый адрес.
Нажмите OK.

Примечание — Почтовый адрес может быть адресом для отправления СМС (например, 1234567890@carrierdomainname.com) или почтовым адресом группы, включающий в себя как обычные почтовые адреса, так и почтовые адреса для отправления СМС.

На машине диспетчера скопируйте ovirt-engine-notifier.conf в новый файл с именем 90-email-notify.conf:

cp /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf /etc/ovirt- engine/notifier/notifier.conf.d/90-email-notify.conf

Отредактируйте файл 90-email-notify.conf, удалив всё, кроме раздела "EMAIL Notifications".
Укажите корректные почтовые переменные, следуя примеру ниже. Данный файл переопределяет значения в исходном файле ovirt-engine-notifier.conf file.

EMAIL Notifications
The SMTP mail server address. Required.
MAIL_SERVER=myemailserver.example.com
The SMTP port (usually 25 for plain SMTP, 465 for SMTP with SSL, 587 for SMTP with TLS)
MAIL_PORT=25
Required if SSL or TLS enabled to authenticate the user. Used also to specify 'from' user address if mail server
supports, when MAIL_FROM is not set. Address is in RFC822 format MAIL_USER=
Required to authenticate the user if mail server requires authentication or if SSL or TLS is enabled
SENSITIVE_KEYS="${SENSITIVE_KEYS},MAIL_PASSWORD" MAIL_PASSWORD=
Indicates type of encryption (none, ssl or tls) should be used to communicate with mail server.
MAIL_SMTP_ENCRYPTION=none
If set to true, sends a message in HTML format.
HTML_MESSAGE_FORMAT=false
Specifies 'from' address on sent mail in RFC822 format, if supported by mail server.
MAIL_FROM=rhevm2017@example.com
Specifies 'reply-to' address on sent mail in RFC822 format. MAIL_REPLY_TO=
Interval to send smtp messages per # of IDLE_INTERVAL MAIL_SEND_INTERVAL=1
Amount of times to attempt sending an email before failing. MAIL_RETRIES=4

Примечание — Дополнительные параметры см. в файле /etc/ovirt-engine/notifier/notifier.conf.d/README.

Для применения внесённых изменений активируйте и перезапустите службу ovirt-engine-notifier:

systemctl daemon-reload
systemctl enable ovirt-engine-notifier.service
systemctl restart ovirt-engine-notifier.service

Указанный пользователь с этого момента будет получать почтовые сообщения о событиях в окружении системы ROSA Virtualization. Выбранные события будут показываться во вкладке "Уведомления о событиях" этого пользователя.

Отмена уведомлений о событиях на Портале администрирования

Если пользователь ранее настроил ненужные почтовые уведомления и хочет их отменить, то применяется следующая последовательность действий по отмене уведомлений о событиях на Портале администрирования:

Нажмите "Администрирование → Пользователи".
Нажмите на "Имя" пользователя, чтобы перейти к подробному просмотру.
Перейдите на вкладку "Уведомления о событиях", чтобы просмотреть события, для которых пользователь ранее настроил получение почтовых уведомлений.
Нажмите Управление событиями.
Для просмотра событий используйте кнопку Развернуть все или отдельные кнопки развёртывания по темам.
Снимите соответствующие фладки для отмены уведомлений по этим событиям.
Нажмите OK.

Параметры уведомлений о событиях в файле ovirt-engine-notifier.conf

Файл конфигурации уведомителя о событиях можно найти по пути /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf.

В таблице 71 описаны переменные для файла ovirt-engine-notifier.conf.

Настройка отправки ловушек SNMP из диспетчера ROSA Virtualization

Настройте отправку ловушек протокола SNMP (Simple Network Management Protocol ‒ простой протокол сетевого управления) из диспетчера ROSA Virtualization на один или несколько внешних диспетчеров SNMP. Ловушки SNMP содержат сведения о системных событиях и используются для наблюдения за окружением системы ROSA Virtualization. Число и тип ловушек, отправляемых диспетчеру SNMP, можно настроить на диспетчере виртуализации.

Система ROSA Virtualization поддерживает версии SNMP 2 и 3. В SNMP версии 3 поддерживаются следующие уровни защиты:

NoAuthNoPriv ‒ Ловушки SNMP отправляются без необходимости авторизации или защиты конфиденциальности данных.
AuthNoPriv ‒ Ловушки SNMP отправляются с авторизацией по паролю, но без защиты конфиденциальности данных
AuthPriv ‒ Ловушки SNMP отправляются с авторизацией по паролю и с защитой конфиденциальности данных.

Последовательность действий по настройке отправки ловушек SNMP:

На одном или более внешних диспетчерах SNMP настраивается получение ловушек.
Адреса IP или полные доменные имена машин, которые будут выполнять роль диспетчеров SNMP ‒ Опционально настройте порт, на котором диспетчер будет получать уведомления от ловушек. Порт по умолчанию: порт UDP, 162.
Комьюнити SNMP (только для SNMP версии 2) ‒ Несколько диспетчеров SNMP могут принадлежать к одному и тому же комьюнити. Системы управления и агенты могут взаимодействовать между собой только в границах одного комьюнити. Комьюнити по умолчанию: public.
Идентификатор объектов ловушек для уведомлений ‒ Диспетчер ROSA Virtualization предоставляет OID по умолчанию: 1.3.6.1.4.1.2312.13.1.1. При настройке данного OID все ловушки, дополненные сведениями о событии, отправляются диспетчеру SNMP. Обратите внимание, что изменение ловушки по умолчанию отменяет соответствие создаваемых ловушек требованиям базы MIB диспетчера.
Имя пользователя SNMP ‒ для SNMP версии 3 и уровням защиты 1,2 и 3.
Парольная фраза SNMP ‒ для SNMP версии 3 и уровням защиты 2 и 3.
Закрытая парольная фраза ‒ для SNMP версии 3 и уровня защиты 3.

Примечание — Диспетчер ROSA Virtualization предоставляет базы MIB в файлах /usr/share/doc/ovirt-engine/mibs/OVIRT-MIB.txt. Загрузите базы в диспетчер SNMP до того, как продолжить.

Значение конфигурации SNMP по умолчанию присутствует на диспетчере в файле конфигурации демона уведомлений о событиях по пути /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. Значения, упоминаемые в последовательности действий ниже, базируются на значениях по умолчанию либо примерных значениях из этого файла. Не редактируйте файл напрямую, т.к. такие системные изменения, как обновления, могут в дальнейшем изменить его значения. Для редактирования файла создайте его копию в виде /etc/ovirt-engine/notifier/notifier.conf.d/<целое_число>-snmp.conf, где <целое_число> является числом, указывающим приоритет, с которым должен запускаться этот файл.

Последовательность действий по настройке отправки ловушек SNMP из диспетчера ROSA Virtualization:

Создайте на диспетчере файл конфигурации SNMP с именем <целое_число>-snmp.conf, где <целое_число> — это число, указывающее порядок обработки файлов, например:

vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

Примечание — Скопируйте значения SNMP по умолчанию из файла конфигурации демона уведомлений о событиях по пути /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. В этом файле есть построковые комментарии для каждого из параметров.

Укажите диспетчеров SNMP, комьюнити SNMP (только для SNMP версии 2) и OID в формате, приведённом в примере ниже:

SNMP_MANAGERS="manager1.example.com manager2.example.com:162" SNMP_COMMUNITY=public
SNMP_OID=1.3.6.1.4.1.2312.13.1.1

Укажите используемую версию SNMP: версию 2 (по умолчанию) или 3:

SNMP_VERSION=3

Укажите значение SNMP_ENGINE_ID, например:

SNMP_ENGINE_ID="80:00:00:00:01:02:05:05"

Для SNMP версии 3 укажите уровень защиты ловушек SNMP:

Уровень защиты 1; ловушки NoAuthNoPriv:

SNMP_USERNAME=NoAuthNoPriv SNMP_SECURITY_LEVEL=1

Уровень защиты 2; ловушки AuthNoPriv; от имени пользователя ovirtengine; с парольной фразой SNMP Auth authpass:

SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5
SNMP_AUTH_PASSPHRASE=authpass SNMP_SECURITY_LEVEL=2

Уровень защиты 3; ловушки AuthPriv; от имени пользователя ovirtengine; с парольной фразой SNMP Auth authpass и закрытой парольной фразой SNMP privpass., например:

SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5
SNMP_AUTH_PASSPHRASE=authpass SNMP_PRIVACY_PROTOCOL=AES128
SNMP_PRIVACY_PASSPHRASE=privpass SNMP_SECURITY_LEVEL=3

Укажите, какие события отправляются на диспетчер SNMP, основываясь на примере событий:

Отправлять все события на профиль SNMP по умолчанию:

FILTER="include:*(snmp:) ${FILTER}"

Отправлять все события с уровнем серьёзности ERROR или ALERT на профиль SNMP по умолчанию:

FILTER="include:*:ERROR(snmp:)  ${FILTER}"
FILTER="include:*:ALERT(snmp:) ${FILTER}"

Отправлять события VDC_START на указанный почтовый адрес:

FILTER="include:VDC_START(snmp:mail@example.com) ${FILTER}"

Отправлять все события, кроме событий VDC_START, на профиль SNMP по умолчанию:

FILTER="exclude:VDC_START include:*(snmp:) ${FILTER}"

Это фильтр по умолчанию, настроенный в ovirt-engine-notifier.conf; если этот фильтр не будет отключён либо будут активированы перезаписывающие фильтры, уведомления о событиях отсылаться не будут:

FILTER="exclude:*"

VDC_START — это пример доступных сообщений журнала аудита. Полный список сообщений журнала аудита можно найти в файле /usr/share/doc/ovirt-engine/AuditLogMessages.properties. Как вариант, фильтруйте журнальные сообщения в рамках диспетчера SNMP.

Сохраните файл.
Запустите службу ovirt-engine-notifier и настройте запуск этой службы при загрузке:

systemctl start ovirt-engine-notifier.service
systemctl enable ovirt-engine-notifier.service

Проверьте получение ловушек на диспетчере SNMP.

Примечание — Для возможности работы службы уведомлений либо один из параметров SNMP_MANAGERS, MAIL_SERVER, либо оба эти параметра должны быть корректно настроены в файле /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf или в перезаписывающем его файле.

Пример файла конфигурации SNMP

Данный примерный файл конфигурации базируется на параметрах файла ovirt-engine-notifier.conf. Файл конкретной конфигурации SNMP, подобный указанному ниже, перезаписывает параметры общего файла ovirt-engine-notifier.conf.

Примечание — Скопируйте значения SNMP по умолчанию из файла конфигурации демона уведомлений о событиях по пути /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf в файл /etc/ovirt- engine/notifier/notifier.conf.d/<целое_число>-snmp.conf, где <целое_число> — это число, указывающее приоритет, с которым должен запускаться файл. В этом файле есть построковые комментарии для всех параметров: /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf.

Служебные программы

Утилита oVirt Engine Rename

Применение утилиты oVirt Engine Rename

При запуске команды engine-setup в чистом окружении команда создаёт некоторое количество сертификатов и ключей, использующих полное доменное имя диспетчера, предоставленное во время процесса настройки. Если полное доменное имя диспетчера позже нужно будет сменить (например, как последствие миграции ВМ, размещающей диспетчера, в другой домен), то информация в записях с полным доменным именем должна быть обновлена для отражения нового имени. Эту задачу автоматизирует команда ovirt-engine-rename.

Команда ovirt-engine-rename обновляет записи полного доменного имени диспетчера по следующим местоположениям:

/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf;
/etc/ovirt-engine/isouploader.conf.d/10-engine-setup.conf;
/etc/ovirt-engine/logcollector.conf.d/10-engine-setup.conf;
/etc/pki/ovirt-engine/cert.conf;
etc/pki/ovirt-engine/cert.template;
/etc/pki/ovirt-engine/certs/apache.cer;
/etc/pki/ovirt-engine/keys/apache.key.nopass;
/etc/pki/ovirt-engine/keys/apache.p12.

Примечание — Начиная с версии 3.0, появилась возможность добавления большего числа имён для доступа к веб-интерфейсу диспетчера.

Убедитесь в том, что выбранные имена разрешаются на адрес IP машины диспетчера, для чего добавьте соответствующие записи на сервер DNS или в /etc/hosts (для проверки используйте ping enginename или getent hosts enginename).
Выполните следующие команды:

echo \
'SSO_ALTERNATE_ENGINE_FQDNS="alias1.example.com alias2.example.com"' \
> /etc/ovirt-engine/engine.conf.d/99-custom-sso-setup.conf
systemctl restart ovirt-engine.service
. List the alternate names separated by spaces.

Также возможно добавить IP-адрес машины диспетчера, но использование адресов IP вместо имён DNS не является лучшей практикой.

Примечание — Несмотря на то, что команда ovirt-engine-rename создаёт новый сертификат для веб-сервера, на котором выполняется диспетчер, она не влияет на сертификат для самого диспетчера или на ЦС. В связи с этим при использовании команды ovirt-engine-rename существует некоторый риск, особенно в окружениях, прошедших через процесс обновления с ROSA Virtualization более ранних версий. Соответственно, везде, где возможно, рекомендуется изменять полное доменное имя диспетчера с помощью команд engine-cleanup и engine-setup.

Примечание — Во время процесса обновления старое имя хоста должно оставаться разрешаемым. Если работа утилиты oVirt Engine Rename завершится сбоем со следующим сообщением:

[ ERROR ] Host name is not valid:
<OLD FQDN> did not resolve into an IP address,

добавьте старое имя хоста в файл /etc/hosts, запустите утилиту oVirt Engine Rename и затем удалите старое имя хоста из /etc/hosts.

Синтаксис команды oVirt Engine Rename

Базовый синтаксис команды ovirt-engine-rename:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

Команда также принимает следующие параметры:

--newname=[new name] ‒ даёт возможность указать новое полное доменное имя диспетчера без необходимости действий со стороны пользователей
--log=[file] ‒ даёт возможность указать путь и имя файла, в который будет записываться журнал операции переименования.
--config=[file] ‒ даёт возможность указать путь и имя файла конфигурации для использования во время операции переименования.
--config-append=[file] ‒ даёт возможность указать путь и имя файла конфигурации для добавления во время операции переименования. С помощью этого параметра можно указать путь и имя существующего файла с ответами для автоматизации операции переименования.
--generate-answer=[file] ‒ даёт возможность указать путь и имя файла, в котором записаны ответы и значения, изменённые командой ovirt-engine-rename.

Переименование СУСВ с помощью утилиты oVirt Engine Rename

С помощью команды ovirt-engine-rename можно обновлять записи полного доменного имени (FQDN) СУСВ.

Утилита проверяет, предоставляет ли СУСВ локальный домен ISO или домен хранения данных. Если да, то перед тем как продолжать, утилита предлагает пользователю извлечь, выключить или перевести в режим обслуживания любые ВМ или домены хранения, подключённые к хранилищу, что обеспечивает сохранение подключения ВМ к своим виртуальным дискам и предотвращает потерю возможности подключения доменов хранилищ ISO во время процесса переименования.

Последовательность действий по переименованию СУСВ с помощью утилиты oVirt Engine Rename:

Подготовьте все DNS и другие записи, необходимые для нового FQDN.
Обновите конфигурацию сервера DHCP, в случае если используется DHCP.
Обновите имя хоста на СУСВ.
Выполните следующую команду:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

По запросу команды нажмите Enter для остановки службы engine:

During execution engine service will be stopped (OK, Cancel) [OK]:

По запросу команды введите новый FQDN для СУСВ:

New fully qualified server name:new_engine_fqdn

Команда ovirt-engine-rename обновит записи FQDN СУСВ.

Для виртуализированного ЦУ выполните следующие дополнительные шаги:

На каждом из существующих узлов виртуализированного ЦУ выполните следующую команду:

hosted-engine --set-shared-config fqdn new_engine_fqdn --type=he_local

Данная команда изменяет полное доменное имя в каждой локальной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf на всех узлах виртуализированного ЦУ.

На каждом из узлов виртуализированного ЦУ выполните следующую команду:

hosted-engine --set-shared-config fqdn new_engine_fqdn --type=he_shared

Данная команда изменяет полное доменное имя в главной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf разделяемого домена хранения.

Теперь все новые и уже существующие узлы виртуализированного ЦУ используют новое полное доменное имя.

Примечание — Утилита oVirt Engine Rename предназначена для работы только на локальных машинах. Смена имени диспетчера не изменяет автоматически имя на удалённых машинах хранилища данных. Смена имени на этих машинах должна выполняться вручную.

Для развёртываний в удалённых хранилищах данных выполните следующие шаги на удалённой машине (не на машине диспетчера):

Удалите следующие файлы PKI:

/etc/pki/ovirt-engine/apache-ca.pem/etc/pki/ovirt-engine/apache-grafana- ca.pem/etc/pki/ovirt-engine/certs/*/etc/pki/ovirt-engine/keys/*

Обновите полное доменное имя СУСВ в следующих файлах (например, vm-new-name.local_lab_server.example.ru):

/etc/grafana/grafana.ini/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Выполните engine-setup с переключателем --offline для исключения выполнения обновлений в это время:

engine-setup --offline

Утилита Engine Configuration

Применение утилиты Engine Configuration

Утилита Engine Cconfiguration является консольной утилитой для настройки глобальных параметров окружения ROSA Virtualization. Утилита взаимодействует со списком отображений "ключ-значение", которые хранятся в базе данных диспетчера виртуализации, и даёт возможность получить список всех ключей и значений, доступных для настройки. Кроме того, для каждого из уровней настройки системы ROSA Virtualization могут храниться различные значения.

Примечание — Для получения или настройки значений ключей конфигурации выполнение виртуализированного ЦУ или платформы JBoss не обязательно. Поскольку отображения "значение-ключ" конфигурации хранятся в базе данных диспетчера виртуализации, их можно обновлять при работающей службе postgresql. Далее изменения применяются при перезапуске службы ovirt-engine.

Синтаксис команды engine-config

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

engine-config --help

Стандартные задачи:

Вывод списка доступных ключей конфигурации:

engine-config --list

Вывод списка доступных значений конфигурации:

engine-config --all

Получение значения ключа конфигурации:

engine-config --get ИМЯ_КЛЮЧА

Для получения значения указанной версии ключа, замените ИМЯ_КЛЮЧА на имя нужного ключа. Для указания версии конфигурации получаемого значения используйте параметр --cver. Если версия не указывается, выводятся значения для всех существующих версий.

Настроить значение ключа конфигурации:

engine-config --set ИМЯ_КЛЮЧА=ЗНАЧЕНИЕ_КЛЮЧА --cver=ВЕРСИЯ

Замените ИМЯ_КЛЮЧА на имя конкретного настраиваемого ключа и замените ЗНАЧЕНИЕ_КЛЮЧА на настраиваемое значение. В окружениях с несколькими версиями конфигурации необходимо указать значение ВЕРСИЯ.

Для применения изменений перезапустить службу ovirt-engine:

systemctl restart ovirt-engine.service

Утилита Log Collector

Применение утилиты Log Collector

Утилита для сбора файлов журналов Log Collector включена в состав ПО СУСВ. С её помощью можно легко собрать необходимые файлы журналов в окружении ROSA Virtualization, например, для создания сводки при обращении в техподдержку.

По умолчанию утилита не установлена. Для установки выполните в консоли СУСВ команду:

dnf install ovirt-log-collector

Исполняемая команда сборщика ‒ ovirt-log-collector. Для её запуска необходимо выполнить вход в систему в качестве пользователя root и предоставить административные полномочия в окружении виртуализации. Команда:

ovirt-log-collector -h

показывает сведения о её применении, включая список всех действительных параметров.

Синтаксис команды ovirt-log-collector

Базовый синтаксис команды сборщика журналов:

ovirt-log-collector options list all|clusters|datacenters
ovirt-log-collector options collect

Поддерживаются два режима выполнения ‒ list и collect:

Параметр list выводит список хостов, кластеров или дата-центров, присоединённых к диспетчеру виртуализации. Можно выполнять фильтрацию на основе списка объектов.
Параметр collect выполняет сбор файлов журналов в виртуализированном ЦУ. Собранные файлы помещаются в файл архива в каталоге /tmp/logcollector. Каждому из файлов журналов команда ovirt-log-collector присваивает конкретное имя.

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

Для детализации требуемых действий у команды ovirt-log-collector существует множество параметров.

Общие параметры ovirt-log-collector

Общие параметры ovirt-log-collector:

--version ‒ отображает номер версии используемой команды и возвращает приглашение командной строки.
-h, --help ‒ отображает сведения об использовании команды и возвращает приглашение командной строки.
--conf-file=ПУТЬ ‒ настраивает ПУТЬ до конфигурационного файла, который должна использовать утилита.
--local-tmp=ПУТЬ ‒ настраивает ПУТЬ в качестве каталога для сохранения журналов. Каталог по умолчанию ‒ /tmp/logcollector.
--ticket-number=ЗАЯВКА ‒ настраивает ЗАЯВКУ в качестве номера заявки в службу поддержки.
--upload= СЕРВЕР_FTP ‒ указывает СЕРВЕР_FTP в качестве цели при отсылке полученных файлов журналов по FTP. Используйте этот параметр только по рекомендации работников техподдержки.
--log-file=ПУТЬ ‒ указывает ПУТЬ для имени файла, который используется командой для вывода журнала.
--quiet ‒ режим без сообщений, при котором вывод сообщений в консоль является минимальным. По умолчанию выключен.
-v, --verbose ‒ режим подробной информации; расширенный вывод сообщений в консоль. По умолчанию выключен.
--time-only ‒ выводит только сведения о разнице во времени между хостами без создания сводки для техподдержки.

Параметры диспетчера виртуализации

С помощью этих параметров выполняется фильтрация собранных файлов журналов и указываются сведения об аутентификации виртуализированного ЦУ.

Эти параметры можно комбинировать в конкретные команды. Например, команда:

ovirt-log-collector --user=admin@internal --cluster ClusterA,ClusterB \
--hosts "SalesHost"*

конкретно указывает пользователя admin@internal и настраивает сбор журналов только для хостов SalesHost в кластерах A и B.

Параметры диспетчера виртуализации:

--no-hypervisors ‒ исключает хосты виртуализации из сбора файлов журналов.
--one-hypervisor-per-cluster ‒ собирает журналы только с одного гипервизора в кластере (диспетчера пула хранилища, при его наличии).
-u ПОЛЬЗОВАТЕЛЬ, --user= ПОЛЬЗОВАТЕЛЬ ‒ указывает имя пользователя для входа в систему. ПОЛЬЗОВАТЕЛЬ указывается в формате пользователь@домен, где пользователь — это имя пользователя, а домен — имя используемого домена служб каталогов. Этот пользователь должен существовать в службе каталогов и должен быть известен диспетчеру виртуализации.
-r FQDN, --rhevm=FQDN ‒ указывает полное доменное имя диспетчера виртуализации, с которого нужно собрать файлы журналов, где FQDN необходимо заменить на полное доменное имя диспетчера. Подразумевается, что сборщик журналов запущен на том же локальном хосте, что и диспетчер виртуализации; значение по умолчанию — localhost.
-c КЛАСТЕР, --cluster=КЛАСТЕР ‒ в дополнение к файлам журналов диспетчера виртуализации, собирает файлы с хостов виртуализации в указанном КЛАСТЕРЕ. Необходимые кластеры должны указываться в виде списка имён кластеров или шаблонов для совпадения через запятую.
-d ДАТА-ЦЕНТР, --data-center= ДАТА-ЦЕНТР ‒ в дополнение к файлам журналов диспетчера виртуализации собирает файлы с хостов виртуализации в указанном ДАТА-ЦЕНТРЕ. Необходимые дата-центры должны указываться в виде списка имён дата-центров или шаблонов для совпадения через запятую.
-H СПИСОК_ХОСТОВ, --hosts= СПИСОК_ХОСТОВ ‒ в дополнение к файлам журналов диспетчера виртуализации, собирает файлы с хостов виртуализации в указанном СПИСКЕ_ХОСТОВ. Включаемые хосты должны указываться в виде списка имён хостов, полных доменных имён или адресов IP. Также принимаются шаблоны для совпадения.

Параметры SSH

Параметры SSH:

--ssh-port=ПОРТ ‒ указывает ПОРТ для использования в подключениях по протоколу SSH между хостами виртуализации.
-k ФАЙЛ_КЛЮЧА, --key-file= ФАЙЛ_КЛЮЧА ‒ указывает ФАЙЛ_КЛЮЧА в качестве ключа SSH, используемого для доступа к хостам виртуализации.
--max-connections=MAX_CONNECTIONS ‒ указывает MAX_CONNECTIONS как максимально возможное число параллельных подключений по протоколу SSH для получения файлов журналов с хостов виртуализации. Число по умолчанию ‒ 10.

Параметры базы данных PostgreSQL

С помощью параметров pg-user и dbname необходимо указать имя пользователя базы данных и имя базы данных, если значения по умолчанию были ранее изменены.

Если база данных находится не на локальном хосте, используйте параметр pg-dbhost. Для сбора удалённых файлов журналов используйте дополнительный параметр pg-host-key. Для успешного сбора удалённых файлов журналов на сервере базы данных должно быть установлено расширение PostgreSQL SOS.

Параметры базы данных PostgreSQL:

--no-postgresql ‒ отключает сбор с базы данных. Сборщик журналов подключится к базе данных PostgreSQL диспетчера виртуализации и включит эти данные в отчёт о журналах, если только не будет указан параметр --no-postgresql.
--pg-user= ПОЛЬЗОВАТЕЛЬ ‒ указывает ПОЛЬЗОВАТЕЛЯ в качестве пользователя, используемого для подключению к серверу базы данных. По умолчанию используется postgres.
--pg-dbname= ИМЯ_БД ‒ указывает ИМЯ_БД в качестве имени базы данных для подключения к серверу баз данных. По умолчанию используется rhevm.
--pg-dbhost= ХОСТ_БД ‒ указывает ХОСТ_БД в качестве имени хоста сервера база данных. По умолчанию ‒ localhost.
--pg-host-key= ФАЙЛ_КЛЮЧА ‒ указывает ФАЙЛ_КЛЮЧА в качестве открытого файла идентификации на сервер базы данных. Значение по умолчанию отсутствует; этот параметр необходим, только если база данных существует не на локальном хосте.

Базовое использование Log Collector

При запуске без дополнительных параметров команда ovirt-log-collector по умолчанию собирает все файлы журналов с диспетчера виртуализации и его присоединённых хостов. Также собираются файлы журналов базы данных, если только не был указан параметр --no-postgresql. В примере ниже Log Collector выполняется для сбора файлов журналов СУСВ и трёх присоединённых хостов:

ovirt-log-collector
INFO: Gathering oVirt Engine information...
INFO: Gathering PostgreSQL the oVirt Engine database and log files from localhost...
Please provide REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): About to collect information from 3 hypervisors. Continue? (Y/n):
INFO: Gathering information from selected hypervisors... INFO: collecting information from 192.168.122.250 INFO: collecting information from 192.168.122.251 INFO: collecting information from 192.168.122.252
INFO: finished collecting information from 192.168.122.250 INFO: finished collecting information from 192.168.122.251 INFO: finished collecting information from 192.168.122.252 Creating compressed archive...
INFO Log files have been collected and placed in /tmp/logcollector/sosreport-rhn-account- 20110804121320-ce2a.tar.xz.
The MD5 for this file is 6d741b78925998caff29020df2b2ce2a and its size is 26.7M

Утилита Engine Vacuum

Применение утилиты Engine Vacuum

Утилита Engine Vacuum поддерживает базы данных PostgreSQL, обновляя информацию в таблицах и удаляя устаревшие строки, освобождая пространство на диске. Сведения о команде VACUUM и её параметрах см. в документации PostgreSQL.

Исполняемая команда утилиты ‒ engine-vacuum. Для её запуска необходимо выполнить вход в систему в качестве пользователя root и предоставить административные полномочия в окружении ROSA Virtualization.

Как вариант, утилиту можно запустить во время выполнения команды engine-setup для настройки параметров существующей установки:

$ engine-setup
...
[ INFO ] Stage: Environment customization
...
Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/static/sql-vacuum.html (Yes, No) [No]:

С параметром "Yes" утилита Engine Vacuum запускается в режиме подробного вывода.

Режимы Engine Vacuum

Утилита Engine Vacuum имеет два режима:

Standard Vacuum

Рекомендуется к частому запуску. Standard vacuum удаляет устаревшие версии в строках таблиц и индексов и помечает это пространство как доступное для будущего использования. Часто обновляемые таблицы должны очищаться таким образом на регулярной основе. Тем не менее стандартная очистка не возвращает пространство операционной системе. Без дополнительных параметров standard vacuum обрабатывает каждую таблицу в базе данных.

Full Vacuum

Не рекомендуется для повседневного использования. Рекомендуется в случаях, когда необходимо освободить значительный объём свободного пространства, ранее используемого таблицей. Full vacuum сжимает таблицы, записывая новые копии файлов таблиц, освобождённых от 6еиспользуемого пространства, тем самым давая возможность ОС получить это пространство. Работа в этом режиме занимает значительный объём времени. Для работы в этом режиме необходимо дополнительное место на диске для хранения новой копии таблицы до окончания процедуры и удаления старой копии. Поскольку этому режиму необходима эксклюзивная блокировка таблицы, он не может выполняться параллельно с работой других пользователей с этой таблицей.

Синтаксис команды engine-vacuum

Команда engine-vacuum имеет следующий базовый синтаксис:

engine-vacuum
engine-vacuum параметр

При запуске команды engine-vacuum без дополнительных параметров выполняется стандартная очистка.

У команды engine-vacuum есть некоторое число параметров для дальнейшей детализации.

Общие параметры команды engine-vacuum

Общие параметры команды engine-vacuum:

-h --help ‒ выводит сведения об использовании.
-a ‒ выполняет стандартную очистку, анализ базы данных и обновляет статистическую информацию оптимизатора.
-A ‒ анализирует базу данных и обновляет статистику оптимизатора, без очистки.
-f ‒ выполняет полную очистку.
-v ‒ выполняется в режиме подробного вывода в консоль.
-t table_name ‒ очищает конкретную таблицу или таблицы.

Пример команды:

engine-vacuum -f -v -t vm_dynamic -t vds_dynamic

Утилита отображения имён VDSM на имена сетей

Применение утилиты отображения имён VDSM на имена логических сетей

Если имя логической сети состоит более чем из 15 символов или содержит символы не в кодировке ASCII, система автоматически создаёт имя-идентификатор на хосте (vdsm_name); оно включает в себя буквы "on" и первые 13 символов уникального идентификатора сети, например ona1b2c3d4e5f6g. Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имён логических сетей и их автоматически созданных сетевых имён, используйте утилиту VDSM-to-Network-Name Mapping, расположенную в каталоге /usr/share/ovirt-engine/bin/.

Последовательность действий по отображению имён VDSM на имена логических сетей:

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

export PASSWORD=DatabaseUserPassword

Запустите утилиту VDSM-to-Network-Name-Mapping:

vdsm_to_network_name_map --user USER

где ПОЛЬЗОВАТЕЛЬ (USER) — это пользователь базы данных с правами на чтение базы данных диспетчера виртуализации, пароль которого присвоен переменной среды PASSWORD.

Утилита отобразит список имён логических сетей, отображённых на их соответствующие идентификаторы на хосте.

Утилиту можно запустить со следующими флагами:

--host — имя хоста/адрес IP сервера баз данных. Значение по умолчанию ‒ localhost.
--port — номер порта сервера БД. Значение по умолчанию ‒ 5432.
--database — имя базы данных. Значение по умолчанию ‒ engine ‒ имя базы данных диспетчера виртуализации.
--secure — активирует защищённое соединение с базой данных. По умолчанию утилита выполняется с незащищённым соединением.