Управление средой

1. Управление hosted engine

1.1. Обслуживание hosted engine

1.1.1. Описание режимов обслуживания hosted engine

Режимы обслуживания позволяют запускать, останавливать и модифицировать виртуальную машину с Менеджером управления без вмешательства со стороны агентов с признаком высокой доступности, а также перезапускать и модифицировать узлы с ролью hosted engine в среде, не мешая работе Менеджера управления.

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

Глобальный (global) – всем агентам с признаком высокой доступности в кластере запрещено вести мониторинг состояния виртуальной машины с Менеджером управления. Глобальный режим обслуживания должен применяться для любых операций настройки или обновления, требующих остановки службы ovirt-engine, таких как обновление до более новой версии ПО «zVirt Max».
Локальный (local) – агенту с признаком высокой доступности на узле, выдающем команду, запрещено вести мониторинг состояния виртуальной машины с Менеджером управления. В локальном режиме обслуживания этот узел освобождается от размещения виртуальной машины с Менеджером управления; если же виртуальная машина с Менеджером управления размещалась на нем на момент перевода в этот режим, то Менеджер управления будет перенесен на другой узел при условии, что один из узлов доступен. Локальный режим обслуживания рекомендуется при применении системных изменений или обновлений к узлу с ролью hosted engine.
Не назначен (none) – отключает режим обслуживания, обеспечивая работоспособность агентов с признаком высокой доступности.

1.1.2. Установка локального режима обслуживания

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

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

Переведите узел с ролью hosted engine в локальный режим обслуживания:
- На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите узел с ролью hosted engine.
- Нажмите Управление (Management) → Обслуживание (Maintenance) и OK. Для этого узла автоматически инициируется локальный режим обслуживания.
После выполнения всех задач обслуживания выключите режим обслуживания:
- На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите узел с ролью hosted engine.
- Нажмите Управление (Management) → Активировать (Activate).

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

Авторизуйтесь на узле с ролью hosted engine и переведите его в локальный режим обслуживания:
```
 hosted-engine --set-maintenance --mode=local
```
После выполнения всех задач обслуживания выключите режим обслуживания:
```
 hosted-engine --set-maintenance --mode=none
```

1.1.3. Установка глобального режима обслуживания

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

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

Переведите все узлы с ролью hosted engine в глобальный режим обслуживания:
- На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите любой узел с ролью hosted engine.
- Нажмите Дополнительные действия (More Actions), затем нажмите Включить глобальное обслуживание высокой доступности (Enable Global HA Maintenance).
После выполнения всех задач обслуживания выключите режим обслуживания:
- На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите любой узел с ролью hosted engine.
- Нажмите Дополнительные действия (More Actions), затем нажмите Отключить глобальное обслуживание высокой доступности (Disable Global HA Maintenance).

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

Авторизуйтесь на узле с ролью hosted engine и переведите его в глобальный режим обслуживания:
```
 hosted-engine --set-maintenance --mode=global
```
После выполнения всех задач обслуживания выключите режим обслуживания:
```
 hosted-engine --set-maintenance --mode=none
```

1.2. Управление виртуальной машиной с Менеджером управления

Утилита hosted-engine предлагает много команд, помогающих управлять виртуальной машиной с Менеджером управления. Запустить hosted-engine можно на любом узле с ролью hosted engine. Чтобы увидеть все доступные команды, выполните hosted-engine --help. Чтобы увидеть дополнительную информацию по конкретной команде, выполните hosted-engine --command --help.

1.2.1. Обновление конфигурации hosted engine

Чтобы обновить конфигурацию hosted engine, воспользуйтесь командой hosted-engine --set-shared-config. Эта команда обновляет конфигурацию hosted engine в общем домене хранения после первоначального развертывания.

Чтобы просмотреть текущие значения параметров конфигурации, воспользуйтесь командой hosted-engine --get-shared-config.

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

 hosted-engine --set-shared-config _key_ --type=_type_ --help

где type может принимать одно из следующих значений:

he _ local	Устанавливает значения в локальном экземпляре /etc/ovirt-hosted-engine/hosted-engine.conf на локальном хосте, поэтому только этот хост использует новые значения. Чтобы применить новое значение, перезапустите службы ovirt-ha-agent и ovirt-ha-broker.
he _ shared	Устанавливает значения в /etc/ovirt-hosted-engine/hosted-engine.conf на общем хранилище, поэтому все хосты, развернутые после изменения конфигурации, используют эти значения. Чтобы применить новое значение на хосте, повторно разверните хост.
ha	Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/ha.conf на локальном хранилище. Новые настройки вступают в силу немедленно.
broker	Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/broker.conf на локальном хранилище. Чтобы применить новые настройки, перезапустите службу ovirt-ha-broker.

he _ local

Устанавливает значения в локальном экземпляре /etc/ovirt-hosted-engine/hosted-engine.conf на локальном хосте, поэтому только этот хост использует новые значения. Чтобы применить новое значение, перезапустите службы ovirt-ha-agent и ovirt-ha-broker.

he _ shared

Устанавливает значения в /etc/ovirt-hosted-engine/hosted-engine.conf на общем хранилище, поэтому все хосты, развернутые после изменения конфигурации, используют эти значения. Чтобы применить новое значение на хосте, повторно разверните хост.

Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/ha.conf на локальном хранилище. Новые настройки вступают в силу немедленно.

broker

Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/broker.conf на локальном хранилище. Чтобы применить новые настройки, перезапустите службу ovirt-ha-broker.

1.2.2. Настройка уведомлений по электронной почте

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

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

На узле с ролью hosted engine установите ключ smtp-server в значение, соответствующее желаемому адресу SMTP-сервера:

 hosted-engine --set-shared-config smtp-server __smtp.example.com__ --type=broker

Чтобы убедиться, что файл конфигурации hosted engine был обновлен, выполните:

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

Убедитесь, что SMTP-порт по умолчанию (порт 25) настроен:

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

Укажите адрес электронной почты, который SMTP-сервер должен использовать для отправки уведомлений. Указать можно только один адрес.
```
hosted-engine --get-shared-config smtp-port --type=broker
broker : 25, type : broker
```
Укажите адрес электронной почты для получения уведомлений. Можно указать несколько адресов через запятую.
```
hosted-engine --set-shared-config destination-emails _destination1@example.com_,_destination2@example.com_ --type=broker
```
Чтобы убедиться в правильной настройке SMTP для среды hosted engine, измените состояние высокой доступности на узле с ролью hosted engine и проверьте, были ли отправлены уведомления по электронной почте. Например, можно изменить состояние высокой доступности, переведя агенты с признаком высокой доступности в режим обслуживания. Дополнительную информацию см. в Разделе 3.1.1. Обслуживание hosted engine.

1.2.3. Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах

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

Чтобы добавить дополнительные узлы с ролью hosted engine в Менеджер управления, см. Раздел 3.1.4. Добавление узлов с ролью hosted engine в Менеджер управления.

Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах

Нажмите Ресурсы (Compute) → Кластеры (Clusters) и выберите кластер, содержащий узлы с ролью hosted engine.
Нажмите Изменить (Edit).
Откройте вкладку Политика планирования (Scheduling Policy).
Нажмите + и выберите HeSparesCount.
Введите количество дополнительных узлов с ролью hosted engine, которые будут резервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления.
Нажмите btn:OK.

1.3. Добавление узлов с ролью hosted engine в Менеджер управления

Узлы с ролью hosted engine добавляются так же, как и стандартные хосты, но с дополнительным шагом – развертыванием хоста в качестве узла с ролью hosted engine. Общий домен хранения определяется автоматически, и при необходимости узел можно использовать в качестве хоста для аварийного переключения, чтобы разместить на нем виртуальную машину с Менеджером управления. К среде hosted engine можно подключать и стандартные хосты, но на них не может размещаться виртуальная машина с Менеджером управления. Чтобы обеспечить высокую доступность виртуальной машины с Менеджером управления, необходимо иметь как минимум два узла с ролью hosted engine.

Предварительные условия

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

Процедура

На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts).
Нажмите Новый (New).

Информацию о дополнительных настройках хоста см. в разделе Описание настроек и средств управления в окнах "Новый хост (New Host)" и "Изменить хост (Edit Host)" в Руководстве администратора.
В выпадающем списке выберите Центр данных (Data Center) и Хост кластера (Host Cluster) для нового хоста.
Введите имя и адрес нового хоста в поля Имя (Name) и Адрес (Address). В поле SSH-порт (SSH Port) автоматически подставляется порт 22 – стандартный номер SSH-порта.
Выберите метод аутентификации, который будет использоваться для доступа Менеджера управления к хосту.
- Укажите пароль root-пользователя, чтобы использовать аутентификацию по паролю.
- Либо скопируйте ключ, отображаемый в поле Публичный ключ SSH (SSH PublicKey), в /root/.ssh/authorized_keys на хосте, чтобы использовать аутентификацию по открытому ключу.
При желании настройте управление питанием, если у хоста есть поддерживаемая карта управления питанием. Информацию о конфигурации управления питанием см. в разделе Описание настроек управления питанием хоста в Руководстве пользователя.
Откройте вкладку Hosted Engine.
Выберите Развернуть (Deploy).
Нажмите btn:OK.

1.4. Переустановка существующего хоста в качестве узла с ролью hosted engine

Существующий стандартный хост в среде hosted engine можно преобразовать в узел с ролью hosted engine, на котором может размещаться виртуальная машина с Менеджером управления.

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
Нажмите OK.

Хост переустанавливается с конфигурацией hosted engine и помечается значком короны на Портале администрирования.

1.5. Загрузка виртуальной машины с Менеджером управления в режиме восстановления

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

Подключитесь к одному из узлов с ролью hosted engine:
```
$ ssh root@_host_address_
```
Переведите hosted engine в глобальный режим обслуживания:
```
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
```
Теперь можно запускать задачи восстановления на виртуальной машине с Менеджером управления.

1.6. Удаление хоста из среды hosted engine

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

Удаление хоста из среды hosted engine

На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите узел с ролью hosted engine.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Отменить развертывание (UNDEPLOY). Это действие останавливает службы ovirt-ha-agent и ovirt-ha-broker и удаляет файл конфигурации hosted engine.
Нажмите OK.
При желании нажмите Удалить (Remove). Откроется окно подтверждения Удалить хост(ы) (Remove Host(s)).
Нажмите OK.

1.7. Обновление hosted engine

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

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

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

Процедура

Авторизуйтесь на одном из узлов с ролью hosted engine и включите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Прежде чем продолжить, убедитесь, что среда находится в глобальном режиме обслуживания:
```
hosted-engine --vm-status
```
Должно отобразиться сообщение о том, что кластер находится в глобальном режиме обслуживания.

Обновление Менеджера управления

Процедура

На машине с Менеджером управления проверьте и убедитесь в доступности обновленных пакетов:
```
engine-upgrade-check
```
Обновите установочные пакеты:
```
yum update ovirt*setup*
```

Обновите Менеджер управления с помощью скрипта engine-setup. Скрипт engine-setup выведет несколько вопросов о конфигурации, остановит службу ovirt-engine, загрузит и установит обновленные пакеты, создаст резервную копию базы данных и обновит ее, выполнит настройку после установки и запустит службу ovirt-engine.

engine-setup

После успешного завершения скрипта появится следующее сообщение: Настройка успешно завершена (Execution of setup completed successfully).

Скрипт engine-setup также используется во время установки Менеджера управления и хранит заданные значения параметров конфигурации. Во время обновления сохраненные значения отображаются при предварительном просмотре конфигурации и могут быть неактуальными, если для обновления конфигурации после установки использовался engine-config. Например, если engine-config использовался для обновления значения SANWipeAfterDelete до true после установки, то при предварительном просмотре конфигурации engine-setup выведет "Значение по умолчанию 'Очистить SAN после удаления': false (Default SAN wipe after delete: False)". Однако engine-setup не перезапишет обновленные значения.

Процесс обновления может занять определенное время. Не останавливайте процесс до его завершения.

Обновите базовую операционную систему и все дополнительные пакеты, установленные в Менеджере управления:
```
yum update
```

Если были обновлены какие-либо пакеты ядра:

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

Процедура

Авторизуйтесь на виртуальной машине с Менеджером управления и выключите ее.
Авторизуйтесь на одном из узлов с ролью hosted engine и отключите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=none
```
- При выходе из глобального режима обслуживания ovirt-ha-agent запускает виртуальную машину c Менеджером управления, после чего автоматически запускается Менеджер управления. На запуск Менеджера управления может потребоваться до 10 минут.

Убедитесь, что среда работает:

hosted-engine --vm-status

Перечисленная информация включает в себя Статус engine (Engine Status). Значение параметра Статус engine (Engine status) должно быть:

{"health": "good", "vm": "up", "detail": "Up"}

Если виртуальная машина все еще загружается и Менеджер управления еще не запустился, то значение параметра Статус engine (Engine status) должно быть:

{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

В таком случае подождите несколько минут и попробуйте снова.

1.8. Изменение FQDN Менеджера управления в hosted engine

Можно использовать команду ovirt-engine-rename для обновления записей FQDN Менеджера управления.

1.9. Обновление версии СУБД Jatoba

Обновление версии СУБД Jatoba описано для режима установки Hosted Engine.

В данном пункте описано обновление СУБД «Jatoba» в рамках одной мажорной версий с 4.5.2 до 4.13.2.

Предварительные условия

установленная версия СУБД «Jatoba» 4.5.2;
настроенный локальный доступ к обновляемой СУБД в файле pg_hba.conf с использованием метода peer;
обновляемая СУБД не содержит дополнительных расширений или установлены только те, которые не вызовут конфликтов при обновлении.

Процедура

Авторизуйтесь на хосте, на котором работает ВМ Hosted Engine и переведите его в глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Подключитесь к ВМ HostedEngine по SSH и авторизуйтесь под пользователем root.
Выключить службу СУБД «Jatoba» и проверить статус.
```
systemctl stop jatoba-4.5.2
systemctl status jatoba-4.5.2
```
Скопировать необходимые файлы для установки СУБД «Jatoba». Требуется скопировать полную структуру файлов и каталогов из дистрибутива.
В каталоге /localrepo заменить версию дистрибутива на 4.13.2, для этого очистить содержимое каталога /localrepo и разархивировать архив с новой версией.
```
rm -rf /localrepo/*
tar xvf /tmp/jatoba-4.13.2.tar.gz -C /localrepo
```
Обновить список доступных пакетов:
```
dnf update
```

Установить новые версии компонентов СУБД.

dnf install --allowerasing jatoba4-gis-activator11-1.1.0-181.x86_64.rpm
dnf install --allowerasing jatoba4-libs-4.13.2-53316.x86_64.rpm
dnf install --allowerasing jatoba4-client-4.13.2-53316.x86_64.rpm
dnf install --allowerasing jatoba4-server-4.13.2-53316.x86_64.rpm
dnf install --allowerasing jatoba4-contrib-4.13.2-53316.x86_64.rpm

В случае отображения запроса о файле /etc/pam.d/jatoba, нажать клавишу Enter.
Запустить службу СУБД, добавить ее в автозагрузку ОС и проверить состояние.
```
systemctl start jatoba-4.13.2
systemctl enable jatoba-4.13.2
systemctl status jatoba-4.13.2
```
Выполнить подключение к СУБД и убедиться в исправности БД:
```
sudo -u postgres psql
postgres=# \l+
```
Отключитесь от ВМ HostedEngine.
Авторизуйтесь на хосте, на котором работает ВМ Hosted Engine и выведите его из глобального режима обслуживания:
```
hosted-engine --set-maintenance --mode=none
```
Проверьте статус работы ВМ Hosted Engine.
```
hosted-engine --vm-status
```
Ожидаемый статус:
```
Engine status  : {"vm": "up", "health": "good", "detail": "Up"}
```
Войдите на Портал Администрирования и проверьте работоспособность ПО «zVirt Max».

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

2.1. Резервное копирование и восстановление Менеджера управления

2.1.1. Общая информация о резервном копировании Менеджера управления

Используйте инструмент engine-backup для регулярного резервного копирования Менеджера управления. Инструмент создает резервную копию базы данных и файлов конфигурации engine в виде одного файла, и его можно запускать, не прерывая работу службы ovirt-engine.

2.1.2. Синтаксис команды резервного копирования engine (engine-backup)

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

engine-backup --mode=backup

engine-backup --mode=restore

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

Основные параметры:

--mode (режим)

Определяет, будет ли команда выполнять операцию резервного копирования или восстановления. Доступны два варианта: резервное копирование (backup) и восстановление (restore). Это обязательный параметр.

--file (файл)

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

--log (журнал)

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

--scope (состав)

Определяет объем операции резервного копирования или восстановления. Возможны четыре варианта:

всё (all): резервное копирование или восстановление всех баз данных и данных конфигурации;
файлы (files): резервное копирование или восстановление только файлов в системе;
база данных (db): резервное копирование или восстановление только базы данных Менеджера управления;
хранилище базы данных (dwhdb): резервное копирование или восстановление только базы данных Хранилища (DWH). По умолчанию используется значение всё (all).

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

Параметры базы данных Менеджера управления

Следующие параметры доступны только для команды engine-backup в режиме восстановления (restore). Синтаксис приведенных ниже параметров применяется к восстановлению базы данных Менеджера управления. Аналогичные параметры предусмотрены для восстановления базы данных Хранилища (DWH). См. синтаксис параметров для Хранилища (DWH) с помощью команды engine-backup --help.

--provision-db (предоставить бд)

Создает базу данных, куда будет выполнено восстановление из резервной копии базы данных Менеджера управления. Это обязательный параметр при восстановлении из резервной копии на удаленном хосте или новой установке, в которой еще не сконфигурирована база данных.

--change-db-credentials (сменить учетные данные бд)

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

--restore-permissions (восстановить разрешения) или --no-restore-permissions (не восстанавливать разрешения)

Восстанавливает (или не восстанавливает) разрешения пользователей базы данных. Один из этих параметров обязателен при восстановлении резервной копии.

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

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

Можно создать резервную копию Менеджера управления с помощью команды engine-backup, пока он активен. Необходимо добавить одно из следующих значений к параметру --scope, чтобы указать, резервную копию чего нужно создать:

all (всё)

Полная резервная копия всех баз данных и файлов конфигурации Менеджера управления.

files (файлы)

Резервная копия только файлов в системе.

db (база данных)

Резервная копия только базы данных Менеджера управления.

dwhdb (база данных хранилища)

Резервная копия только базы данных Хранилища (DWH).

cinderlibdb (база данных cinderlib)

Резервная копия только базы данных Cinderlib

Параметр --scope можно прописать несколько раз.

Кроме того, можно сконфигурировать команду engine-backup на резервное копирование дополнительных файлов. Она восстанавливает все, что записывает в резервную копию.

Для восстановления базы данных в новой установке Менеджера управления недостаточно одной резервной копии базы данных. Менеджеру управления также требуется доступ к файлам конфигурации. Если значение объема не всё (all), то обязательно нужно добавить параметр --scope=files или создать резервную копию файловой системы._

Полное описание команды engine-backup доступно при вводе команды engine-backup --help на машине с Менеджером управления.

Процедура

Авторизуйтесь на Менеджере управления.
Создайте резервную копию:
```
engine-backup --scope=all --mode=backup --file= file_name  --log=_log_file_name
```
При использовании этой команды создается резервная копия в file_name.tar и файл журналов в log_file_name.

Используйте file_name.tar для восстановления среды.

Несколько сценариев резервного копирования показано на примерах ниже.

Пример 1. Полное резервное копирование

engine-backup --scope=all --mode=backup --file=_file_name_ --log=_log_file_name_

Пример 2. Резервная копия базы данных Менеджера управления

engine-backup --scope=files --scope=db --mode=backup --file=_file_name_  --log= _log _file_name_

Пример 3. Резервная копия базы данных Хранилища (DWH)

engine-backup --scope=files --scope=dwhdb --mode=backup --file= _file_name_  --log= _log_file_name_

Пример 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.

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

Восстановление из резервной копии с помощью команды engine-backup предусматривает больше шагов, чем создание резервной копии, и зависит от того, куда будут восстанавливаться данные. Например, команду engine-backup можно использовать для восстановления резервных копий на новые установки ПО «zVirt Max», поверх существующих установок ПО «zVirt Max», с использованием локальных или удаленных баз данных.

Версия Менеджера управления, которая используется для восстановления из резервной копии, должна быть выше или равна версии Менеджера управления, использованной для создания резервной копии. Начиная с версии ПО «zVirt Max» 3.0, эта политика строго соблюдается командой engine-backup. Чтобы узнать версию ПО «zVirt Max» в файле резервной копии, распакуйте файл резервной копии и посмотрите значение в файле версия (version), расположенном в корневом каталоге распакованных файлов.

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

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

Процедура

Авторизуйтесь на Менеджере управления. Для восстановления базы данных engine на удаленном хосте нужно будет авторизоваться и выполнить соответствующие действия на этом хосте. Аналогично, для одновременного восстановления базы данных Хранилища (DWH) на удаленном хосте нужно будет авторизоваться и выполнить соответствующие действия на этом хосте.
Восстановление полной резервной копии или резервной копии только базы данных.
- Восстановление из полной резервной копии:
  engine-backup --mode=restore --file=_file_name_ --log= _log_file_name_ --provision-db --restore-permissions
  Если Хранилище (DWH) тоже восстанавливается в составе полной резервной копии, необходимо предоставить дополнительную базу данных:
  engine-backup --mode=restore --file= _file_name_ --log=_log_file_name_ --provision-db --provision-dwh-db --restore-permissions
- Восстановление из резервной копии только базы данных через восстановление файлов конфигурации и резервной копии базы данных:
  engine-backup --mode=restore --scope=files --scope=db --file= _file_name_ --log= _log_file_name_ --provision-db --restore-permissions
  В примере выше также восстанавливается резервная копия базы данных Менеджера управления.
  engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log= _log_file_name _ --provision-dwh-db --restore-permissions
  В примере выше также восстанавливается резервная копия базы данных Хранилища (DWH).
  
  В случае положительного результата на экране появится следующее сообщение:
  You should now run engine-setup. Done.
Выполните следующую команду и следуйте подсказкам для настройки восстановленного Менеджера управления:
```
engine-setup
```

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

С помощью команды 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

Чтобы восстановить только базу данных Менеджера управления (например, если база данных Хранилища (DWH) находится на другой машине), можно не указывать параметр --scope=dwhdb.

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

You should now run engine-setup.

Done.

Переконфигурируйте Менеджер управления:
```
engine-setup
```

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

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

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

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

Процедура

Авторизуйтесь на машине с Менеджером управления.
Выполните следующую команду и следуйте подсказкам, чтобы удалить файлы конфигурации Менеджера управления и очистить его базу данных:
```
engine-cleanup
```
Измените пароль для владельца базы данных engine, если учетные данные этого пользователя неизвестны:
- Введите в командной строке:
  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

Если Хранилище (DWH) тоже восстанавливается в составе полной резервной копии, то включите обновленные учетные данные в дополнительную базу данных:

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 --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
```
В примере выше также восстанавливается резервная копия базы данных Хранилища (DWH). В случае положительного результата на экране появится следующее сообщение:
```
You should now run engine-setup.

Done.
```

Выполните команду ниже и следуйте подсказкам, чтобы перенастроить межсетевой экран и убедиться, что служба ovirt-engine настроена правильно:
```
engine-setup
```

2.1.8. Резервное копирование и восстановление hosted engine

Можно создать резервную копию hosted engine и восстановить его в новой среде hosted engine. Эта процедура применяется для таких задач, как перенос среды в новый домен хранения hosted engine с другим типом хранилища.

Когда указывается файл резервной копии во время развертывания, резервная копия восстанавливается на новой виртуальной машине с Менеджером управления с новым доменом хранения hosted engine. Старый Менеджер управления удаляется, а старый домен хранения hosted engine переименовывается, и его можно удалить вручную после, убедившись, что новая среда работает корректно.

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

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

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

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

Предварительные условия

FQDN готово для Менеджера управления и хоста. В DNS должны быть установлены записи прямого и обратного просмотра. FQDN нового Менеджера управления должно совпадать с FQDN исходного Менеджера управления.

Исходный Менеджер управления должен быть обновлен до последней промежуточной версии.

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

Уровень совместимости центра данных должен быть установлен на последнюю версию, чтобы обеспечить совместимость с обновленной версией хранилища.
В среде должен быть как минимум один обычный хост. Этот хост (и любые другие обычные хосты) будет оставаться активным, чтобы взять на себя роль SPM и разместить любые запущенные виртуальные машины. Если обычный хост еще не является SPM, переместите роль SPM до создания резервной копии, выбрав обычный хост и нажав Управление (Management) → Назначить как SPM (Select as SPM).

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

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

2.1.8.1. Резервное копирование исходного Менеджера управления

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

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

Процедура

Авторизуйтесь на одном из узлов с ролью hosted engine и переведите среду в глобальный режим обслуживания:
```
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 – это FQDN сервера сетевого хранилища, на котором будет храниться резервная копия до востребования, а /backup/ – это любая указанная папка или путь.
```
scp -p _file_name_ _log_file_name_ storage.example.com:/backup/
```
Авторизуйтесь на одном из узлов с ролью hosted engine и выключите виртуальную машину с исходным Менеджером управления:
```
hosted-engine --vm-shutdown
```
После создания резервной копии Менеджера управления разверните новый hosted engine и восстановите резервную копию на новой виртуальной машине.

2.1.8.2. Восстановление из резервной копии на новом hosted engine

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

Если вы используете хранилище iSCSI и ваш iSCSI-таргет фильтрует подключения в соответствии со списком контроля доступа инициатора, то развертывание может завершиться с ошибкой ДОМЕН_ХРАНЕНИЯ_НЕДОСТУПЕН (STORAGE _ DOMAIN _ UNREACHABLE). Чтобы этого избежать, обновите конфигурацию iSCSI перед началом развертывания hosted engine.

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

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

Процедура

Скопируйте файл резервной копии на новый хост. В следующем примере host.example.com – это FQDN хоста, а /backup/ – любая указанная папка или путь.
```
scp -p  _file_name_  host.example.com:/backup/
```
Авторизуйтесь на новом хосте.
В случае развертывания на ПО «zVirt Max» Host пакет ovirt-hosted-engine-setup уже установлен, поэтому пропустите этот шаг. В случае развертывания на Red Hat Enterprise Linux установите пакет ovirt-hosted-engine-setup:
```
dnf install ovirt-hosted-engine-setup
```
Для запуска скрипта используйте менеджер окон tmux, чтобы избежать потери сеанса в случае нарушения работы сети или терминала. Установите и запустите tmux:
```
dnf -y install tmux
tmux
```
Запустите скрипт hosted-engine, указав путь к файлу резервной копии:
```
hosted-engine --deploy --restore-from-file=backup/ _file_name_
```
Чтобы в любой момент выйти из скрипта и прервать развертывание, нажмите CTRL+D.

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

Введите сетевые параметры виртуальной машины. Если вы укажете Статический (Static), то введите 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-адрес.
Оценить ситуацию, выяснить, почему хост не работает, и внести необходимые исправления. Например, если развернутая система была восстановлена из резервной копии и эта резервная копия включала в себя обязательные сети (required networks) для кластера хоста, то настройте сети, подключив к ним соответствующие сетевые карты хоста.
Если все выглядит как положено и хост имеет статус Включен (Up), удалите файл блокировки, показанный в сообщении выше. Развертывание продолжается.

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

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

Не используйте точку монтирования старого домена хранения hosted engine для нового домена хранения, так как вы рискуете потерять данные виртуальной машины.

Для iSCSI введите данные портала и выберите таргет и LUN из списков автоматически обнаруженных устройств. Во время развертывания можно выбрать только один iSCSI-таргет, но поддерживаются несколько путей для подключения всех порталов одной группы порталов.
Для Fibre Channel выберите LUN из списка автоматически обнаруженных устройств. Адаптеры шины хоста должны быть настроены и подключены, а на LUN не должно быть никаких данных. Информацию о том, как повторно использовать существующий LUN, см. в разделе Повторное использование LUN в Руководстве пользователя.

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

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

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

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

Предварительные условия

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall). Откроется окно Установить хост (Install Host).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
Нажмите OK, чтобы переустановить хост.

После переустановки хоста и возвращения его статуса к значению Включен (Up) вы сможете перенести виртуальные машины обратно на хост.

После того как вы зарегистрируете хост с ПО «zVirt Max» Host в Менеджере управления и переустановите его, Портал администрирования может ошибочно отобразить его статус как Не удалось установить (Install Failed). Нажмите Управление (Management) → Активировать (Activate), затем статус хоста поменяется на Включен (Up) и он будет готов к использованию.

После переустановки узлов с ролью hosted engine можно проверить статус новой среды, выполнив следующую команду на одном из узлов:

hosted-engine --vm-status

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

2.1.8.4. Удаление домена хранения

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Переведите домен хранения в режим обслуживания и отключите его:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Обслуживание (Maintenance), а затем OK.
- Нажмите Отсоединить (Detach), а затем OK.
Нажмите Удалить (Remove).
При желании установите флажок Форматирование домена, т.е. содержимое хранилища будет потеряно! (Format Domain, i.e. Storage Content will be lost!), чтобы стереть содержимое домена.
Нажмите OK.

Домен хранения навсегда удален из среды.

2.1.9. Восстановление hosted engine из существующей резервной копии

Если hosted engine недоступен из-за неустранимых проблем, то можно восстановить его в новой среде, используя резервную копию, сделанную до появления проблемы (если таковая копия имеется).

Когда вы указываете файл резервной копии во время развертывания, резервная копия восстанавливается на новой виртуальной машине с Менеджером управления с новым доменом хранения hosted engine. Старый Менеджер управления удаляется, а старый домен хранения hosted engine переименовывается, и его можно удалить вручную после, убедившись, что новая среда работает корректно. Настоятельно рекомендуется развертывание на новом хосте; если хост, используемый для развертывания, существовал в среде, с которой была сделана резервная копия, то он будет удален из восстановленной базы данных, чтобы избежать конфликтов в новой среде. При развертывании на новом хосте необходимо присвоить хосту уникальное имя. Повторное использование имени существующего хоста, включенного в резервную копию, может привести к конфликтам в новой среде.

Восстановление hosted engine включает в себя следующие основные действия:

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

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

Предварительные условия

FQDN готово для Менеджера управления и хоста. В DNS должны быть установлены записи прямого и обратного просмотра. FQDN нового Менеджера управления должно совпадать с FQDN исходного Менеджера управления.

2.1.9.1. Восстановление из резервной копии на новом hosted engine

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

Процедура

Скопируйте файл резервной копии на новый хост. В следующем примере host.example.com – это FQDN хоста, а /backup/ – любая указанная папка или путь.
```
scp -p  _file_name_  host.example.com:/backup/
```
Авторизуйтесь на новом хосте.
В случае развертывания на ПО «zVirt Max» Host пакет ovirt-hosted-engine-setup уже установлен, поэтому пропустите этот шаг. В случае развертывания на Red Hat Enterprise Linux установите пакет ovirt-hosted-engine-setup:
```
dnf install ovirt-hosted-engine-setup
```
Для запуска скрипта используйте менеджер окон tmux, чтобы избежать потери сеанса в случае нарушения работы сети или терминала. Установите и запустите tmux:
```
dnf -y install tmux
tmux
```
Запустите скрипт hosted-engine, указав путь к файлу резервной копии:
```
hosted-engine --deploy --restore-from-file=backup/ _file_name_
```
Чтобы в любой момент выйти из скрипта и прервать развертывание, нажмите CTRL+D.

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

Укажите, нужно ли добавлять записи для виртуальной машины с Менеджером управления и базового хоста в файл /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-адрес.
Оценить ситуацию, выяснить, почему хост не работает, и внести необходимые исправления. Например, если развернутая система была восстановлена из резервной копии и эта резервная копия включала в себя обязательные сети (required networks) для кластера хоста, то настройте сети, подключив к ним соответствующие сетевые карты хоста.
Если все выглядит как положено и хост имеет статус Включен (Up), удалите файл блокировки, показанный в сообщении выше. Развертывание продолжается.

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

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

Для iSCSI введите данные портала и выберите таргет и LUN из списков автоматически обнаруженных устройств. Во время развертывания можно выбрать только один iSCSI-таргет, но поддерживаются несколько путей для подключения всех порталов одной группы порталов.
Для Fibre Channel выберите LUN из списка автоматически обнаруженных устройств. Адаптеры шины хоста должны быть настроены и подключены, а на LUN не должно быть никаких данных. Информацию о том, как повторно использовать существующий LUN, см. в разделе Повторное использование LUN в Руководстве пользователя.

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

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

Предварительные условия

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall). Откроется окно Установить хост (Install Host).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
Нажмите OK, чтобы переустановить хост.

hosted-engine --vm-status

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

2.1.9.3. Удаление домена хранения

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Переведите домен хранения в режим обслуживания и отключите его:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Обслуживание (Maintenance), а затем OK.
- Нажмите Отсоединить (Detach), а затем OK.
Нажмите Удалить (Remove).
При желании установите флажок Форматирование домена, т.е. содержимое хранилища будет потеряно! (Format Domain, i.e. Storage Content will be lost!), чтобы стереть содержимое домена.
Нажмите OK.

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

2.1.10. Перезапись hosted engine из существующей резервной копии

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

Восстановление hosted engine до предшествующего состояния включает в себя следующие шаги:

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

Дополнительные сведения об опциях engine-backup --mode=restore см. в Разделе 3.2.1. Резервное копирование и восстановление Менеджера управления.

2.1.10.1. Включение глобального режима обслуживания

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

Процедура

Авторизуйтесь на одном из узлов с ролью hosted engine и включите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Прежде чем продолжить, убедитесь, что среда находится в глобальном режиме обслуживания.
```
hosted-engine --vm-status
```
Должно отобразиться сообщение о том, что кластер находится в глобальном режиме обслуживания.

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

С помощью команды 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

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

You should now run engine-setup.

Done.

Переконфигурируйте Менеджер управления:
```
engine-setup
```

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

Процедура

Авторизуйтесь на виртуальной машине с Менеджером управления и выключите её.
Авторизуйтесь на одном из узлов hosted engine и отключите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=none
```
При выходе из глобального режима обслуживания ovirt-ha-agent запускает виртуальную машину c Менеджером управления, после чего автоматически запускается Менеджер управления. На запуск Менеджера управления может потребоваться до 10 минут.

Убедитесь, что среда работает:

hosted-engine --vm-status

Перечисленная информация включает в себя Статус engine (Engine Status). Значение параметра Статус engine (Engine Status) должно быть:

 { "health": "good", "vm": "up", "detail": "Up"}

Если виртуальная машина все еще загружается и Менеджер управления еще не запустился, значение параметра Статус engine (Engine status) должно быть:

{ "reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

В таком случае подождите несколько минут и попробуйте снова.

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

2.2. Перенос Хранилища (DWH) на отдельную машину

В этом разделе описано, как перенести базу данных и службу Хранилища (DWH) с машины с Менеджером управления на отдельную машину. Размещение службы Хранилища (DWH) на отдельной машине снижает нагрузку на каждую отдельную машину и позволяет избежать потенциальных конфликтов, связанным с тем, что ресурсы ЦП и памяти приходится делить с другими процессами.

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

Можно перенести службу Хранилища (DWH) с машины с Менеджером управления и подключить ее к существующей базе данных Хранилища (DWH) (ovirt_engine_history).
Можно перенести базу данных Хранилища (DWH) с машины с Менеджером управления, а затем перенести службу Хранилища (DWH).

Перенесите базу данных Хранилища (DWH) (ovirt_engine_history) до переноса службы Хранилища (DWH). Используйте engine-backup для создания резервной копии базы данных и ее восстановления на новой машине с базой данных. Дополнительные сведения о engine-backup см. с помощью команды engine-backup --help.

Процедура

Создайте резервную копию базы данных и файлов конфигурации Хранилища (DWH) в Менеджере управления:
```
engine-backup --mode=backup --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
```
Установите серверный пакет:
```
dnf install postgresql-server postgresql-contrib
```
Инициализируйте базу данных, запустите службу и убедитесь, что она стартует при загрузке:
```
su - postgres -c 'initdb'
systemctl enable postgresql
systemctl start postgresql
```
Восстановите базу данных Хранилища (DWH) на новой машине. file _ name – это файл резервной копии, скопированный из Менеджера управления.
```
engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --provision-dwh-db --restore-permissions
```

Теперь база данных Хранилища (DWH) и Менеджер управления размещаются на разных машинах. После успешного восстановления базы данных Хранилища (DWH) система предложит выполнить команду engine-setup. Перед выполнением этой команды перенесите службу Хранилища (DWH).

2.2.1. Перенос службы Хранилища (DWH) на отдельную машину

Службу Хранилища (DWH), установленную и настроенную в Менеджере управления, можно перенести на отдельную машину. Размещение службы Хранилища (DWH) на отдельной машине помогает снизить нагрузку на машину с Менеджером управления.

Обратите внимание, что эта процедура переносит только службу Хранилища (DWH).

Информацию о том, как перенести базу данных Хранилища (DWH) (ovirt_engine_history) перед переносом службы Хранилища (DWH), см. в разделе 3.2.2.1. Перенос базы данных Хранилища (DWH) на отдельную машину.

Предварительные условия

На одной машине должны быть установлены и настроены Менеджер управления и Хранилище (DWH).
Чтобы настроить новую машину с Хранилищем (DWH), нужно иметь:
- Пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup-database.conf Менеджера управления.
- Разрешенный доступ с машины с Хранилищем (DWH) к TCP-порту 5432 машины с базой данных Менеджера управления.
- Имя пользователя и пароль для базы данных Хранилища (DWH) из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf Менеджера управления.

Если перенос базы данных ovirt _ engine _ history выполнялся с использованием процедур, описанных в разделе 3.2.2.1. Перенос базы данных Хранилища (DWH) на отдельную машину, то резервная копия включает в себя эти учетные данные, заданные во время настройки базы данных на этой машине.

Для установки этого сценария выполните 4 шага:

Установка новой машины со службой Хранилища (DWH).
Остановка службы Хранилища (DWH) на машине с Менеджером управления.
Настройка новой машины со службой Хранилища (DWH).
Отключение пакета Хранилища (DWH) на машине с Менеджером управления.

2.2.1.1. Установка новой машины со службой Хранилища (DWH)

Включите репозитории ПО «zVirt Max» и установите пакет настроек Хранилища (DWH) на машину с Red OS:

Убедитесь в актуальности всех установленных пакетов:
```
dnf upgrade --nobest
```
Установите пакет ovirt-engine-dwh-setup:
```
dnf install ovirt-engine-dwh-setup
```
===== Остановка службы Хранилища (DWH) на машине с Менеджером управления

Процедура

Остановите службу Хранилища (DWH):
```
systemctl stop ovirt-engine-dwhd.service
```
Если база данных размещена на удаленной машине, предоставьте доступ вручную, изменив файл postgres.conf. Измените файл /var/lib/pgsql/data/postgresql.conf и скорректируйте строку listen _ addresses, чтобы она выглядела так:
```
listen _ addresses = ' * '
```
Если этой строки нет или она закомментирована, то добавьте ее вручную. Если база данных размещена на машине с Менеджером управления и была настроена во время чистой установки Менеджера управления, то доступ предоставляется по умолчанию.
Перезапустите службу:
```
systemctl restart postgresql
```

2.2.1.2. Настройка новой машины со службой Хранилища (DWH)

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

В случае переноса базы данных ovirt_engine_history и службы Хранилища (DWH) на одну и ту же машину выполните перечисленные ниже действия, в противном случае перейдите к следующему шагу.
```
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
```
Выполните команду engine-setup, чтобы начать настройку Хранилища (DWH) на машине:
```
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). Это применимо, даже если список содержит всего один элемент.

Введите FQDN и пароль для Менеджера управления. Нажмите Ввод (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:
1 - Access remote engine server using ssh as root
2 - 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_

Введите FQDN и пароль для машины с базой данных Менеджера управления. Нажмите Ввод (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 (btn:[OK], Cancel)  [ btn:[OK] ] :
```

Теперь служба Хранилища (DWH) настроена на удаленной машине. Далее отключите службу Хранилища (DWH) на машине с Менеджером управления.

2.2.1.3. Отключение службы Хранилища (DWH) на машине с Менеджером управления

Процедура

Перезапустите Менеджер управления на машине с Менеджером управления:
```
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

Отключите службу Хранилища (DWH):
```
systemctl disable ovirt-engine-dwhd.service
```
Удалите файлы Хранилища (DWH):
```
rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/* .conf /var/lib/ovirt-engine-dwh/backups/*
```
Теперь служба Хранилища (DWH) и Менеджер управления размещаются на разных машинах.

2.3. Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения (Backup Storage Domain)

2.3.1. Описание Резервного домена хранения

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

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

Любой домен хранения данных можно задать в качестве резервного домена. Чтобы включить/выключите эту настройку, установите/снимите флажок в диалоговом окне "Управление доменом (Manage Domain)". Эту настройку можно включить только после остановки всех виртуальных машин в этом домене хранения.

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

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

Преимущества

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

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

Ограничения

У любой виртуальной машины или шаблона в резервном домене ( _ backup) все диски должны быть в этом же домене.
Все виртуальные машины в домене хранения должны быть выключены, прежде чем его можно будет сделать резервным доменом.
Невозможно запустить виртуальную машину, хранящуюся в резервном домене, потому что это может привести к изменению данных на диске.
Резервный домен не может быть целевым доменом томов памяти (memory volumes), поскольку тома памяти поддерживаются только для активных виртуальных машин.
Предварительный просмотр виртуальной машины в резервном домене невозможен.
Перенос виртуальной машины "на лету" в резервный домен невозможен.
Невозможно задать резервный домен в качестве мастер-домена.
Невозможно задать домен hosted engine в качестве резервного домена.
Не используйте домен хранения по умолчанию в качестве резервного домена.

2.3.2. Установка домена хранения данных в качестве резервного домена

Предварительные условия

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

Процедура

На Портале администрирования нажмите Хранилище (Storage) → Домены (Domains).
Создайте новый домен хранения или выберите существующий домен хранения и нажмите Управление доменом (Manage Domain). Откроется диалоговое окно Управление доменами (Manage Domains).
В блоке Расширенные параметры (Advanced Parameters) установите флажок Резервный (Backup).

Теперь домен стал резервным доменом.

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

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

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

Создайте резервный домен. См. Раздел 3.2.3.2. Установка домена хранения данных в качестве резервного домена.
Создайте новую виртуальную машину на базе виртуальной машины, резервную копию которой вы хотите сделать:
- Чтобы сделать резервную копию моментального снимка, сначала создайте из него виртуальную машину. См. раздел Создание виртуальной машины из шаблона в Руководстве пользователя.
- Чтобы сделать резервную копию виртуальной машины, сначала клонируйте ее. См. раздел Клонирование виртуальной машины в Руководстве пользователя.
Экспортируйте новую виртуальную машину в резервный домен. См. раздел Экспорт виртуальной машины в домен данных в Руководстве пользователя.

Процедура: Восстановление виртуальной машины

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

Сопутствующая информация

Раздел 2.6.8.2. Импортирование доменов хранения.
Раздел 2.6.8.3. Перенос доменов хранения между центрами данных в одной среде.
Раздел 2.6.8.4. Перенос доменов хранения между центрами данных в разных средах.

2.4. Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления

2.4.1. API резервного копирования и восстановления

API резервного копирования и восстановления – это набор функций, которые позволяют выполнять полное или пофайловое резервное копирование и восстановление виртуальных машин. API сочетает в себе ряд компонентов ПО «zVirt Max» (таких как создаваемые на лету моментальные снимки и REST API) для создания и использования временных томов, которые можно подключить к виртуальной машине, содержащей ПО резервного копирования, предоставленное независимым поставщиком ПО.

2.4.2. Резервное копирование виртуальной машины

Используйте API резервного копирования и восстановления для создания резервной копии виртуальной машины. Эта процедура предполагает, что у вас есть две виртуальные машины: виртуальная машина, с которой нужно сделать резервную копию, и виртуальная машина, на которой установлено ПО для управления резервным копированием.

Процедура

Используя REST API, создайте моментальный снимок виртуальной машины, резервную копию которой нужно сделать:

POST /api/vms/`_{vm:id}_`/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<snapshot>
    <description>BACKUP</description>
</snapshot>

Замените здесь { vm:id} идентификатором виртуальной машины, моментальный снимок которой вы делаете. Этот идентификатор можно посмотреть на вкладке Общие (General) окон Создать виртуальную машину (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine) на Портале администрирования и Пользовательским портале.
При создании моментального снимка виртуальной машины данные ее текущей конфигурации помещаются в атрибут data атрибута configuration блока initialization, расположенного под моментальным снимком.

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

Получите данные конфигурации виртуальной машины из атрибута data, расположенного под моментальным снимком:

GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1
All-Content: true
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.
Добавьте заголовок All-Content: true, чтобы получить дополнительные данные OVF в ответе. Данные OVF в XML-ответе находятся в элементе конфигурации виртуальной машины < initialization >< configuration >. Позже вы будете использовать эти данные для восстановления виртуальной машины.

Получите идентификатор моментального снимка:

GET /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

Определите соответствующий моментальному снимку идентификатор диска:
```
GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_`/disks HTTP/1.1
Accept: application/xml
Content-type: application/xml
```

Подключите к резервной виртуальной машине моментальный снимок как активный диск, используя корректный тип интерфейса (например, virtio _ scsi):

POST /api/vms/`_{vm:id}_`/diskattachments/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk_attachment>
	<active>true</active>
	<interface>_virtio_scsi_</interface>
	<disk id="_{disk:id}_">
	<snapshot id="_{snapshot:id}_"/>
	</disk>
</disk_attachment>

Замените параметр {vm:id} идентификатором резервной виртуальной машины, а не той виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {disk:id} идентификатором диска.
Замените { snapshot:id} идентификатором моментального снимка.

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

Отключите моментальный снимок, подключенный как диск, от резервной виртуальной машины:

DELETE /api/vms/`_{vm:id}_`/diskattachments/`_{snapshot:id}_` HTTP/1.1
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором резервной виртуальной машины, а не той виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.

При желании удалите моментальный снимок:

DELETE /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.

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

2.4.3. Восстановление виртуальной машины

Чтобы восстановить виртуальную машину, для которой была создана резервная копия, используйте API резервного копирования и восстановления. Эта процедура предполагает, что у вас есть резервная виртуальная машина, на которой установлено ПО, управлявшее предыдущей резервной копией.

Процедура

На Портале администрирования создайте плавающий диск, на который нужно восстановить ВМ из резервной копии. Подробную информацию о порядке создания плавающего диска см. в Разделе 2.8.6.1. Создание виртуального диска.

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

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="_{disk:id}_">
</disk>

Замените параметр {vm:id} на идентификатор (ID) этой резервной виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените параметр {disk:id} на идентификатор диска, который вы получили во время резервного копирования виртуальной машины.

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

Отключите диск от резервной виртуальной машины:

DELETE /api/vms/`_{vm:id}_`/disks/_{disk:id}_ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <detach>true</detach>
</action>

Замените параметр {vm:id} на идентификатор (ID) этой резервной виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените параметр {disk:id} на идентификатор диска.

Создайте новую виртуальную машину, используя данные конфигурации восстанавливаемой виртуальной машины:

POST /api/vms/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<vm>
    <cluster>
        <name>cluster_name</name>
    </cluster>
    <name>_NAME_</name>
      <initialization>
      <configuration>
  <data>
  <!-- omitting long ovf data -->
  </data>
      <type>ovf</type>
      </configuration>
      </initialization>
    ...
</vm>

Чтобы при создании виртуальной машины переопределить любое из значений в ovf, переопределите элемент до или после элемента initialization.

Подключите диск к новой виртуальной машине:

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="_{disk:id}_">
</disk>

Замените параметр `{vm:id} `на идентификатор новой виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {disk:id} на идентификатор диска.

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

2.5. Резервное копирование и восстановление виртуальных машин с помощью API инкрементного резервного копирования и восстановления

ПО «zVirt Max» предоставляет API инкрементного резервного копирования, который можно использовать для создания полных резервных копий виртуальных дисков форматов QCOW2 или RAW или инкрементных резервных копий виртуальных дисков формата QCOW2 без создания каких-либо временных моментальных снимков.

Резервные копии данных создаются в формате RAW независимо от того, в каком формате созданы резервные копии виртуального диска - QCOW2 или RAW. Можно восстанавливать гостевые данные формата RAW и диски формата RAW или QCOW2. API инкрементного резервного копирования входит в состав ПО «zVirt Max» REST API. Можно создавать резервные копии как работающих, так и неработающих виртуальных машин.

Особенности

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

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

Ограничения:

Инкрементное резервное копирование можно выполнять только для дисков формата QCOW2, а не RAW. В процессе резервного копирования резервные копии данных сохраняются в формате RAW.
Данные можно восстановить только из резервных копий формата RAW.
Инкрементное восстановление не поддерживает восстановление моментальных снимков, существовавших на момент резервного копирования. При инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в моментальных снимках, существовавших на момент резервного копирования. Это ограничение обычно присутствует в решениях резервного копирования для других систем.
Обычно в решениях резервного копирования при инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в моментальных снимках, существовавших на момент резервного копирования.
Некорректное завершение работы виртуальной машины по любой причине может испортить карты битов на диске, что повредит всю цепочку резервного копирования. Восстановление из инкрементной резервной копии с помощью некорректной карты битов приведет к повреждению данных виртуальной машины.

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

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

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

Таблица 1. Поддерживаемые конфигурации дисков для инкрементного резервного копирования
Тип хранилища	Тип предоставления дискового пространства	Когда инкрементное резервное копирование	Виртуальный диск имеет формат
блочное	динамическое	включено	qcow2
блочное	предварительно выделенное	включено	qcow2 (предварительно выделенное)
файловое	динамическое	включено	qcow2
файловое	предварительно выделенное	включено	qcow2 (предварительно выделенное)
блочное	динамическое	отключено	qcow2
блочное	предварительно выделенное	отключено	raw (предварительно выделенное)
файловое	динамическое	отключено	raw (динамически расширяемое)
файловое	предварительно выделенное	отключено	raw (предварительно выделенное)
сеть	Не применимо	отключено	raw
lun	Не применимо	отключено	raw

2.5.1. Процесс инкрементного резервного копирования

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

Приложение резервного копирования использует REST API для поиска дисков виртуальной машины, которые нужно добавить в резервную копию. Добавляются только диски формата QCOW2.
Приложение резервного копирования запускает полное резервное копирование или инкрементное резервное копирование. Вызов API указывает идентификатор виртуальной машины, необязательный идентификатор (ID) предыдущей контрольной точки и список дисков для резервного копирования. Если в вызове API не указан идентификатор предыдущей контрольной точки, то начинается полное резервное копирование, охватывающее все данные на указанных дисках, исходя из текущего состояния каждого диска.
Engine подготавливает виртуальную машину к резервному копированию. Во время резервного копирования виртуальная машина может продолжать работать.
Приложение резервного копирования запрашивает у engine статус резервного копирования до тех пор, пока engine не сообщит о готовности начать резервное копирование.
При готовности начать резервное копирование приложение резервного копирования создаст объект imagetransfer для каждого диска, включенного в резервную копию.
Приложение резервного копирования получает список измененных блоков от ovirt-imageio для каждой передачи образов. Если список изменений недоступен, то приложение резервного копирования выдаст ошибку.
Приложение резервного копирования загружает измененные блоки в формате RAW из ovirt-imageio и сохраняет их на резервном носителе. Если список измененных блоков недоступен, то приложение резервного копирования может откатиться к копированию всего диска.
Приложение резервного копирования завершает все передачи образов.
Приложение резервного копирования завершает резервное копирование с помощью REST API.

2.5.2. Процесс инкрементного восстановления

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

С помощью приложения резервного копирования пользователь выбирает точку восстановления, исходя из доступных резервных копий.
Приложение резервного копирования создает новый диск или моментальный снимок существующего диска для хранения восстановленных данных.
Приложение резервного копирования запускает передачу выгружаемого образа для каждого диска, задав для параметра format значение raw. Это позволяет конвертировать формат при выгрузке данных формата RAW на диск формата QCOW2.
Приложение резервного копирования передает данные, включенные в эту точку восстановления, в imageio с помощью API.
Приложение резервного копирования завершает передачи образов.

2.5.3. Задачи, связанные с API инкрементного резервного копирования и восстановления

Процесс резервного копирования и восстановления предусматривает выполнение следующих действий.

Включение инкрементного резервного копирования либо на новом, либо на существующем виртуальном диске:
- На новом диске с помощью Портала администрирования.
- На существующем диске с помощью Портала администрирования.
- На новом или существующем диске с помощью вызова API.
Поиск дисков, для которых включено инкрементное резервное копирование.
Запуск полного резервного копирования.
Запуск инкрементного резервного копирования.
Завершение резервного копирования.
Получение информации о резервной копии.
Получение информации о дисках в резервной копии.
Составление списка всех контрольных точек для виртуальной машины.
Выдача информации по конкретной контрольной точке для виртуальной машины.
Удаление контрольной точки конкретной виртуальной машины.
Загрузка объекта imagetransfer для архивирования резервной копии.
Выгрузка объекта imagetransfer для восстановления из резервной копии.
Составление списка измененных блоков.
Загрузка и выгрузка измененных блоков.

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

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

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

Поскольку для инкрементного резервного копирования требуются диски в формате QCOW2, используйте QCOW2 вместо RAW.

Процедура

Добавьте новый виртуальный диск. Дополнительную информацию см. в разделе 2.8.6.1. Создание виртуального диска.
При настройке параметров диска установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).

2.5.3.2. Включение инкрементного резервного копирования на существующем виртуальном диске формата RAW

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

Если на базовом слое диска используется формат RAW, то удаление последнего моментального снимка и объединение верхнего слоя QCOW2 с базовым слоем преобразует диск в формат RAW, тем самым отключая инкрементное резервное копирование, если оно было установлено. Чтобы снова включить инкрементное резервное копирование, можно создать новый моментальный снимок, включающий в себя этот диск.

Процедура

На Портале администрирования нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Выберите виртуальную машину и откройте вкладку Диски (Disks).
Нажмите Изменить (Edit). Откроется диалоговое окно Изменить диск (Edit Disk).
Установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).

2.5.3.3. Включение инкрементного резервного копирования

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

Процедура

Включите инкрементное резервное копирование для нового диска. Например, для нового диска на виртуальной машине с идентификатором 123 отправьте запрос:

POST /ovirt-engine/api/vms/123/diskattachments

Тело этого запроса должно включать в себя параметр backup, установленный в значение incremental, в составе объекта disk, как показано ниже:

 <disk_attachment>
    ...
    <disk>
       ...
       <backup>incremental</backup>
       ...
    </disk>
</disk_attachment>

Ответ:

<disk_attachment>
    ...
    <disk href="/ovirt-engine/api/disks/456" id="456"/>
    ...
</disk_attachment>

2.5.3.4. Поиск дисков, на которых включено инкрементное резервное копирование

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

Процедура

Выведите список дисков, подключенных к виртуальной машине. Например, для виртуальной машины с идентификатором 123 отправьте запрос:
```
GET /ovirt-engine/api/vms/123/diskattachments
```
Ответ включает в себя все объекты disk_attachment, каждый из которых включает в себя один или несколько объектов disk. Например:
```
<disk_attachments>
    <disk_attachment>
       ...
       <disk href="/ovirt-engine/api/disks/456" id="456"/>
       ...
    </disk_attachment>
    ...
</disk_attachments>
```
Используйте службу disk, чтобы просмотреть свойства диска из предыдущего шага. Например, для диска с идентификатором 456 отправьте запрос:
```
GET /ovirt-engine/api/disks/456
```
Ответ включает в себя все свойства для диска. Параметр backup установлен в значение none или incremental. Например:
```
<disk href="/ovirt-engine/api/disks/456" id="456">
    ...
    <backup>incremental</backup>
    ...
</disk>
```

2.5.3.5. Запуск полного резервного копирования

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

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

Запуск полного резервного копирования требует вызова запроса с телом и включает в себя ответ.

Процедура

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
```
POST /ovirt-engine/api/vms/123/backups
```
В теле запроса укажите диск, с которого нужно снять резервную копию. Например, чтобы запустить полное резервное копирование диска с идентификатором 456, отправьте запрос со следующим телом:
```
<backup>
    <disks>
       <disk id="456" />
       ...
    </disks>
</backup>
```
Тело ответа должно выглядеть примерно так:
```
<backup id="789">
    <disks>
       <disk id="456" />
       ...
       ...
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>
```
Ответ включает в себя:
- Идентификатор резервной копии.
- Статус резервной копии, указывающий, что она инициализируется.

Опрос резервной копии до появления статуса готова (ready). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.

2.5.3.6. Запуск инкрементного резервного копирования

После завершения полного резервного копирования данного виртуального диска последующие инкрементные резервные копии этого диска будут содержать только изменения, внесенные с момента последнего резервного копирования. Используйте значение идентификатора конечной контрольной точки (to_checkpoint_id) из последней резервной копии в качестве значения для идентификатора начальной контрольной точки (from_checkpoint_id) в теле запроса.

Запуск инкрементного или смешанного резервного копирования требует вызова запроса с телом и включает в себя ответ.

Процедура

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
```
POST /ovirt-engine/api/vms/123/backups
```

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

<backup>
    <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
    <disks>
       <disk id="456" />
       ...
    </disks>
</backup>

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

 <backup>
    <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
    <disks>
       <disk id="456" />
       **<disk id="789" />**
       ...
    </disks>
</backup>

Тело ответа должно выглядеть примерно так:

 <backup id="101112">
<from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
<to_checkpoint_id>__new-checkpoint-uuid__</to_checkpoint_id>
    <disks>
       <disk id="456" />
       <disk id="789" />
       ...
       ...
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>

Ответ включает в себя:

Идентификатор резервной копии.
Идентификатор любого диска, который был включен в резервную копию.
Статус, указывающий, что резервная копия инициализируется.

Опрос резервной копии до появления статуса готова (ready). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.

2.5.3.7. Получение информации о резервной копии

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

Метод list службы VmBackups возвращает следующую информацию о резервной копии:

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

Когда параметр <статус (status)> имеет значение готова (ready), ответ включает в себя <идентификатор конечной контрольной точки (to_checkpoint_id) > , который следует использовать в качестве `< идентификатора начальной контрольной точки from_checkpoint_id)> ` при следующем инкрементном резервном копировании, и можно начать загрузку дисков, чтобы выполнить резервное копирование хранилища виртуальной машины.

Процедура

Чтобы получить информацию о резервной копии с идентификатором 456 виртуальной машины с идентификатором 123, отправьте запрос следующего вида:
```
GET /ovirt-engine/api/vms/456/backups/123
```

Ответ включает в себя резервную копию с идентификатором 456 с <идентификатором начальной контрольной точки (from_checkpoint_id)> 999 и `<идентификатором конечной контрольной точки (to_checkpoint_id)> ` 666. Диски, включенные в резервную копию, указаны в элементе <link>.

<backup id="456">
    <from_checkpoint_id>999</from_checkpoint_id>
    <to_checkpoint_id>666</to_checkpoint_id>
    <link href="/ovirt-engine/api/vms/456/backups/123/disks" rel="disks"/>
    <status>ready</status>
    <creation_date>
</backup>

2.5.3.8. Получение информации о дисках в резервной копии

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

Метод list службы VmBackupDisks возвращает следующую информацию о резервной копии:

Идентификатор и имя каждого диска, с которого была снята резервная копия.
Идентификатор образа диска в резервной копии, для каждого диска, включенного в процесс резервного копирования.
Формат диска.
Поведение процесса резервного копирования, поддерживаемое диском.
Тип резервного копирования, взятый для диска (полное/инкрементное).

Процедура

Чтобы получить информацию о резервной копии с идентификатором 456 виртуальной машины с идентификатором 123, отправьте запрос следующего вида:
```
GET /ovirt-engine/api/vms/456/backups/123/disks
```

Ответ включает в себя диск с идентификатором 789, а идентификатор образа – 555.

 <disks>
    <disk id="789">
        <name>vm1_Disk1</name>
        <actual_size>671744</actual_size>
        <backup>incremental</backup>
        <backup_mode>full</backup_mode>
        <format>cow</format>
        <image_id>555</image_id>
        <qcow_version>qcow2_v3</qcow_version>
        <status>locked</status>
        <storage_type>image</storage_type>
        <total_size>0</total_size>
    </disk>
</disks>

2.5.3.9. Завершение резервного копирования

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

Процедура

Чтобы завершить резервное копирование диска с идентификатором 456 на виртуальной машине с идентификатором 123, отправьте запрос следующего вида:

POST /vms/123/backups/456/finalize

2.5.3.10. Создание объекта imagetransfer для инкрементного резервного копирования

Когда резервная копия готова к загрузке, приложение резервного копирования должно создать объект imagetransfer, который инициирует перенос инкрементной резервной копии.

Создание объекта imagetransfer требует вызова запроса с телом.

Процедура

Отправьте запрос следующего вида:
```
POST /ovirt-engine/api/imagetransfers
```
В теле запроса укажите следующие параметры:
- идентификатор диска (disk id);
- идентификатор резервной копии (backup id);
- направление для диска установлено в значение загрузка (download);
- формат для диска установлен в значение raw.
  
  Например, чтобы перенести резервную копию диска с идентификатором диска 123 и идентификатором резервной копии 456, отправьте следующее тело запроса:

 < image _ transfer >
 < disk id="123"/ >
 < backup id="456"/ >
 < direction > download < /direction >
 < format > raw < /format >
 < /image _ transfer >

2.5.3.11. Создание объекта imagetransfer для инкрементного восстановления

Чтобы включить восстановление неформатированных (raw) данных из резервной копии с помощью API инкрементного резервного копирования на диск формата QCOW2, приложение резервного копирования должно создать объект imagetransfer.

Если формат переноса – raw, а формат базового диска – QCOW2, то выгружаемые данные на лету преобразуются в формат QCOW2 во время записи в хранилище. Выгрузка данных с диска QCOW2 на диск RAW не поддерживается.

Создание объекта imagetransfer требует вызова запроса с телом.

Процедура

Отправьте запрос следующего вида:
```
POST /ovirt-engine/api/imagetransfers
```
В теле запроса укажите следующие параметры:
- идентификатор диска или идентификатор моментального снимка;
- направление для диска установлено в значение выгрузка (upload);
- формат для диска установлен в значение raw.

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

 < image _ transfer >
 < disk id="123"/ >
 < direction > upload < /direction >
 < format > raw < /format >
 < /image _ transfer >

2.5.3.12. Составление списка контрольных точек для виртуальной машины

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

Процедура

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
```
GET /vms/123/checkpoints/
```
Ответ включает в себя все контрольные точки виртуальной машины. Каждая контрольная точка содержит следующую информацию:
- Диски контрольной точки.
- Идентификатор родительской контрольной точки.
- Дата создания контрольной точки.
- Виртуальная машина, к которой она относится.
  
  Например:
  <parent_id>, <creation_date> and the virtual machine it belongs to <vm>: <checkpoints> <checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint> </checkpoints>

2.5.3.13. Выдача информации о конкретной контрольной точке виртуальной машины

Можно получить информацию о конкретной контрольной точке виртуальной машины, отправив запрос.

Процедура

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 123 и идентификатором контрольной точки 456 как показано ниже:
```
GET /vms/123/checkpoints/456
```
В ответе будет дана следующая информация о контрольной точке:
- Диски контрольной точки.
- Идентификатор родительской контрольной точки.
- Дата создания контрольной точки.
- Виртуальная машина, к которой она относится.
  
  Например:
  <checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint>

2.5.3.14. Удаление контрольной точки

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

Процедура

Отправьте запрос с указанием виртуальной машины и контрольной точки. Например, укажите виртуальную машину с идентификатором 123 и контрольную точку с идентификатором 456 как показано ниже:

DELETE /vms/123/checkpoints/456/

2.5.3.15. Использование API imageio для передачи данных резервного копирования

API imagetransfer запускает и останавливает передачу образов. В результате появится URL-адрес передачи.

Используйте API imageio для фактической передачи данных из URL-адреса передачи.

Таблица 2. Таблица Методы API imageio Image, используемые при инкрементном резервном копировании и восстановлении
Запрос API (API request)	Описание	Справочный раздел API imageio Image
OPTIONS /images/ { ticket-id} HTTP/1.1	Выводит параметры сервера, чтобы можно было узнать, какие функции поддерживает сервер.	См. ПАРАМЕТРЫ (OPTIONS)
GET /images/ { ticket-id}/extents	Выводит информацию о содержимом и выделении образа диска или о блоках, которые изменились во время инкрементного резервного копирования. Эта информация называется экстент (extent).	См. ЭКСТЕНТЫ (EXTENTS)
GET /images/ { ticket-id}/extent?context=dirty	Программа, выполняющая передачу образа, должна загрузить изменения из резервной копии. Эти изменения называются ожидающие записи экстенты (dirty extents). Чтобы загрузить изменения, отправьте следующий запрос:	См. ЭКСТЕНТЫ (EXTENTS)→ Примеры (Examples)→ Запрос ожидающих записи экстентов (Request dirty extents)
PUT /images/ { ticket-id}	Приложение резервного копирования создает новый диск или моментальный снимок существующего диска для хранения восстановленных данных.	См. PUT_

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

3.1. Общая информация о пользователях

В ПО «zVirt Max» есть два типа пользовательских доменов: локальный и внешний. При установке Менеджера управления создаются локальный домен по умолчанию, называемый внутренним (internal) доменом, и пользователь по умолчанию – admin.

Во внутреннем (internal) домене можно создавать дополнительных пользователей с помощью программы ovirt-aaa-jdbc-tool. Учетные записи пользователей, созданные в локальных доменах, называются локальными пользователями.

Кроме того, к ПО «zVirt Max» можно подключить внешние серверы каталогов, такие как Red Hat Directory Server, Active Directory, OpenLDAP (и другие поддерживаемые варианты), и использовать их в качестве внешних доменов. Учетные записи пользователей, созданные во внешних доменах, называются пользователями из каталогов.

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

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

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

Во время установки Менеджер управления создает пользователя 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.

Невозможно установить Менеджер управления (rhevm) и IdM (ipa-server) на одну систему. IdM несовместим с пакетом mod_ssl, который необходим Менеджеру управления.

Если в качестве сервера каталогов используется Active Directory и для создания шаблонов и виртуальных машин нужно использовать sysprep, то управление доменом необходимо делегировать пользователю c правами администратора ПО «zVirt Max», чтобы тот мог:

Подключить компьютер к домену.
Изменить членство группы.

3.2. Настройка внешнего провайдера LDAP

3.2.1. Настройка внешнего провайдера LDAP (интерактивная установка)

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

Если тип сервера LDAP не указан в интерактивном скрипте установки или нужна дополнительная настройка, можно вручную отредактировать файлы конфигурации. Дополнительную информацию см. в Разделе 3.3.3.3. Настройка внешнего провайдера LDAP (ручной метод).

Пример для Active Directory см. в Разделе 3.3.3.2. Подключение Active Directory.

Предварительные условия

Нужно знать доменное имя DNS- или LDAP-сервера.
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM.
Подготовьте хотя бы одну учетную запись (имя и пароль) для выполнения запросов на поиск и вход на LDAP-сервер.

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap-setup
```
Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:
```
ovirt-engine-extension-aaa-ldap-setup
```
Выберите тип LDAP, введя соответствующий номер. Если вы не знаете точно, какая схема у вашего LDAP-сервера, выберите стандартную схему для вашего типа LDAP-сервера. Для Active Directory выполните процедуру, описанную в Разделе 3.3.3.2. Подключение Active Directory.
```
Available LDAP implementations:

1 - 389ds
2 - 389ds RFC-2307 Schema
3 - Active Directory
4 - IBM Security Directory Server
5 - IBM Security Directory Server RFC-2307 Schema
6 - IPA
7 - Novell eDirectory RFC-2307 Schema
8 - OpenLDAP RFC-2307 Schema
9 - OpenLDAP Standard Schema
10 - Oracle Unified Directory RFC-2307 Schema
11 - RFC-2307 Schema (Generic)
12 - RHDS
13 - RHDS RFC-2307 Schema
14 - iPlanet

Please select:
```
Нажмите Ввод (Enter), чтобы принять значение по умолчанию и настроить разрешение доменного имени для имени LDAP-сервера:
```
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]:
```
Выберите метод политики DNS:
- Вариант 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.com SRV.
- Вариант 3: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика предусматривает балансировку нагрузки между LDAP-серверами. Запросы распределяются между всеми LDAP-серверами по циклическому алгоритму (round-robin).
- Вариант 4: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика определяет первый LDAP-сервер как LDAP-сервер, по умолчанию отвечающий на запросы. Если первый сервер недоступен, запрос будет направлен на следующий LDAP-сервер в списке.
  1 - Single server 2 - DNS domain LDAP SRV record 3 - Round-robin between multiple hosts 4 - Failover between multiple hosts Please select:

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

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

Insecure пропускает проверку сертификата, но соединение по-прежнему шифруется с помощью 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 расшифровывается как облегченный протокол доступа к каталогам по SSL. Для 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:
```

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

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

Выберите Да (Yes), если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```
Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано example.com.
```
Please specify profile name that will be visible to users: example.com
```

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

Пользователи должны выбрать профиль из выпадающего списка при первом входе в систему. Информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.

Проверьте работоспособность входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к ПО «zVirt Max». Для запроса на вход введите свои имя пользователя и пароль:

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.com
The following files were created:
    /etc/ovirt-engine/aaa/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com-authn.properties
[ INFO  ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20220104101225-mmneib.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

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

systemctl restart ovirt-engine.service

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

3.2.2. Подключение Active Directory

Предварительные условия

Известно имя леса Active Directory. Имя леса также называется именем корневого домена.

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

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

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap-setup
```
Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:
```
ovirt-engine-extension-aaa-ldap-setup
```

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

Available LDAP implementations:
 1 - 389ds
 2 - 389ds RFC-2307 Schema
 3 - Active Directory
 4 - IBM Security Directory Server
 5 - IBM Security Directory Server RFC-2307 Schema
 6 - IPA
 7 - Novell eDirectory RFC-2307 Schema
 8 - OpenLDAP RFC-2307 Schema
 9 - OpenLDAP Standard Schema
10 - Oracle Unified Directory RFC-2307 Schema
11 - RFC-2307 Schema (Generic)
12 - RHDS
13 - RHDS RFC-2307 Schema
14 - iPlanet
Please select: 3

Введите имя леса Active Directory. Если имя леса неразрешимо DNS-сервером Менеджера управления, то скрипт предложит ввести разделенный пробелами список имен DNS-серверов Active Directory.
```
Please enter Active Directory Forest name: ad-example.example.com
[ INFO  ] Resolving Global Catalog SRV record for ad-example.example.com
[ INFO  ] Resolving LDAP SRV record for ad-example.example.com
```

Параметр 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:

Дополнительную информацию о создании сертификата Центра сертификации в кодировке PEM см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Введите отличительное имя (DN) пользователя, формирующего поисковые запросы. Пользователь должен иметь разрешения для просмотра всех пользователей и групп на сервере каталогов. Пользователь, формирующий поисковый запрос, должен быть включен в аннотацию LDAP. Если разрешен анонимный поиск, нажмите Ввод (Enter), не вводя ничего.
```
Enter search user DN (empty for anonymous): cn=user1,ou=Users,dc=test,dc=example,dc=com
Enter search user password:
```
Укажите, следует ли использовать единый вход для виртуальных машин. По умолчанию эта функция включена, но ее нельзя использовать, если включен единый вход на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```

Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано example.com.

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

Пользователи должны выбрать нужный профиль из выпадающего списка при первом входе в систему. Затем информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.

Проверьте работоспособность поиска и входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к ПО «zVirt Max». Для запроса на вход введите имя учетной записи (account name) и пароль (password). Для поискового запроса выберите Субъект (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: example.com
          The following files were created:
              /etc/ovirt-engine/aaa/example.com.properties
              /etc/ovirt-engine/extensions.d/example.com-authz.properties
              /etc/ovirt-engine/extensions.d/example.com-authn.properties
[ INFO  ] Stage: Clean up
          Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20220514064955-1yar9i.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
  Stage: Termination

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

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

3.2.3. Настройка внешнего провайдера LDAP (ручной метод)

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

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

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap
```
Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для активных каталогов (ad) и других типов каталогов (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, раскомментировав тип 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}

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

Дополнительную информацию о создании открытого файла хранилища ключей см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Пример профиля: раздел хранилища ключей

# 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-сервере соответствующие разрешения, например, для входа на Пользовательский портал, см. Раздел 3.3.9. Администрирование пользовательских задач с Портала администрирования.

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

3.2.4. Удаление внешнего провайдера 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
```
На Портале администрирования на ресурсной вкладке Пользователи (Users) выберите пользователей этого провайдера (тех, чьим Провайдером авторизации (Authorization provider) является profile1-authz) и нажмите Удалить (Remove).

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

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

Чтобы настроить единый вход на Портал администрирования и Пользовательский портал, нужно настроить два расширения: ovirt-engine-extension-aaa-misc и ovirt-engine-extension-aaa-ldap; а также два модуля Apache: mod_auth_gssapi и mod_session. Можно настроить единый вход и без использования Kerberos, однако это выходит за рамки данной документации.

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

В этом примере предполагается следующее:

Существующий сервер Центра распределения ключей (Key Distribution Center, KDC) использует Kerberos 5 в версии MIT.
У вас есть права администратора на сервере KDC.
Клиент Kerberos установлен на Менеджере управления и машинах пользователей.
Утилита kadmin используется для создания субъектов (principals) службы Kerberos и файлов keytab.

Эта процедура содержит следующие компоненты:

На сервере KDC

Создайте субъекта службы и файл keytab для службы Apache в Менеджере управления.

В Менеджере управления

Установите пакеты расширений аутентификации и авторизации и модуль аутентификации Apache Kerberos.
Настройте файлы расширения.

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

На сервере KDC, используя утилиту kadmin, создайте субъекта службы для службы Apache в Менеджере управления. Субъект службы – это идентификатор для ссылки на KDC для службы Apache.
```
kadmin
kadmin> addprinc -randkey _HTTP/fqdn-of-rhevm_@_REALM.COM_
```

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

kadmin> ktadd -k /tmp/http.keytab _HTTP/fqdn-of-rhevm_@_REALM.COM_
kadmin> quit

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

Скопируйте файл keytab с сервера KDC в Менеджер управления:
```
scp /tmp/http.keytab root@rhevm.example.com:/etc/httpd
```

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

В Менеджере управления убедитесь, что для файла keytab заданы соответствующие владелец и разрешения:
```
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). В этом примере используется простой шаблон конфигурации SSO.
```
cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple-sso/  ./etc/ovirt-engine
```

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

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

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

Просмотрите файл метода аутентификации. Этот файл редактировать не нужно, так как область автоматически извлекается из файла 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, раскомментировав тип 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}

Дополнительную информацию о создании открытого файлаnхранилища ключей см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Пример профиля: раздел хранилища ключей

# 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

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

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
```

3.4. Установка и настройка единого входа от Red Hat (Red Hat SSO)

Чтобы использовать единый вход от Red Hat в качестве метода авторизации, необходимо:

Установить единый вход от Red Hat.
Настроить сопоставитель групп LDAP.
Настроить Apache на Менеджере управления.
Настроить учетные данные провайдера OVN.

Если настроен единый вход от Red Hat, предыдущие входы LDAP не будут работать, поскольку одновременно может использоваться только один протокол авторизации.

3.5. Установка единого входа от Red Hat

Вы можете установить единый вход Red Hat, загрузив zip-файл и распаковав его, или используя RPM-файл.

Следуйте инструкциям по установке в документе Red Hat SSO Installation

Подготовьте следующую информацию:

Путь/местонахождение сервера Open ID Connect.
Канал подписки на корректные репозитории.
Корректные учетные данные для авторизации в системе подписки Red Hat.

3.6. Конфигурирование инструмента сопоставления групп LDAP

Процедура

Добавьте в инструмент сопоставления групп LDAP следующую информацию:
- Имя (Name): ldapgroups.
- Тип инструмента сопоставления (Mapper Type): group-ldap-mapper.
- DN групп LDAP (LDAP Groups DN): ou=groups,dc=example,dc=com.
- Классы объектов группы (Group Object Classes): groupofuniquenames (адаптируйте этот класс в соответствии с настройками сервера LDAP).
- Атрибут членства LDAP (Membership LDAP Attribute): uniquemember (адаптируйте этот класс в соответствии с настройками сервера LDAP).
Нажмите Сохранить (Save).
Нажмите Синхронизировать группы LDAP с KeyCloak (Sync LDAP Groups to KeyCloak).
Внизу страницы Провайдер федерации пользователей (User Federation Provider) нажмите Синхронизировать всех пользователей (Synchronize all users).
На вкладке Клиенты (Clients), в разделе Добавить клиента (Add Client), добавьте ovirt-engine в качестве Идентификатора клиента (Client ID) и введите URL-адрес engine в качестве Корневого URL-адреса (Root URL).
Измените Протокол клиента (Client Protocol) на openid-connect, а Тип доступа (Access Type) на конфиденциальный (confidential).
На вкладке Клиенты (Clients), в разделе Ovirt-engine → Расширенные настройки (Advanced Settings), увеличьте значение параметра Срок действия токена доступа (Access Token Lifespan).
Добавьте https://rhvm.example.com:443/ * в качестве правильного URI переадресации.
Генерируется секрет клиента, который можно просмотреть на вкладке Учетные данные (Credentials).
На вкладке Клиенты (Clients), в разделе Создать протокол инструмента сопоставления (Create Mapper Protocol), создайте инструмент сопоставления со следующими настройками:
- Имя (Name): группы.
- Тип инструмента сопоставления (Mapper Type): Членство в группе.
- Имя токена для запроса (Token Claim Name): группы.
- Полный путь к группе: Включено (ON).
- Добавить в токен идентификации (Add to ID token): Включено (ON).
- Добавить в токен доступа (Add to access token): Включено (ON).
- Добавить в информацию о пользователе (Add to userinfo): Включено (ON).
Добавьте Встроенный в протокол инструмент сопоставления (Builtin Protocol Mapper) для имени пользователя (username).
Создайте области, необходимые для ovirt-engine, ovirt-app-api, ovirt-app-admin и ovirt-ext=auth:sequence-priority=~.
Используйте области, созданные в предыдущем шаге, для настройки дополнительных областей клиента для клиента ovirt-engine.

Конфигурирование Apache в Менеджере управления

Включите модуль mod_auth_openidc.
```
dnf module enable mod_auth_openidc:2.3 -y
```
Настройте Apache в Менеджере управления.
```
dnf install mod_auth_openidc
```

Создайте новый файл конфигурации httpd ovirt-openidc.conf в /etc/httpd/conf.d/ со следующим содержимым:

LoadModule auth_openidc_module modules/mod_auth_openidc.so

OIDCProviderMetadataURL https://SSO.example.com/auth/realms/master/.well-known/openid-configuration
OIDCSSLValidateServer Off

OIDCClientID ovirt-engine
OIDCClientSecret <client_SSO _generated_key>
OIDCRedirectURI https://rhvm.example.com/ovirt-engine/callback
OIDCDefaultURL https://rhvm.example.com/ovirt-engine/login?scope=ovirt-app-admin+ovirt-app-portal+ovirt-ext%3Dauth%3Asequence-priority%3D%7E

# maps the prefered_username claim to the REMOTE_USER environment variable:

OIDCRemoteUserClaim <preferred_username>
OIDCCryptoPassphrase <random1234>

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)|^/ovirt-engine/callback>
    <If "req('Authorization') !~ /^(Bearer|Basic)/i">

      Require valid-user
      AuthType openid-connect

      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>

OIDCOAuthIntrospectionEndpoint https://SSO.example.com/auth/realms/master/protocol/openid-connect/token/introspect
OIDCOAuthSSLValidateServer    Off
OIDCOAuthIntrospectionEndpointParams token_type_hint=access_token
OIDCOAuthClientID ovirt-engine
OIDCOAuthClientSecret <client_SSO _generated_key>
OIDCOAuthRemoteUserClaim sub

<LocationMatch ^/ovirt-engine/(api$|api/)>
   AuthType oauth20
   Require valid-user
</LocationMatch>

Для сохранения изменения конфигурации, перезапустите httpd и ovirt-engine:
```
systemctl restart httpd

systemctl restart ovirt-engine
```

Создайте файл openidc-authn.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-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 = openidchttp
ovirt.engine.aaa.authn.authz.plugin = openidc-authz
ovirt.engine.aaa.authn.mapping.plugin = openidc-http-mapping
config.artifact.name = HEADER
config.artifact.arg = OIDC_CLAIM_preferred_username

Создайте файл openidc-authn.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-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 = false
config.mapAuthRecord.regex.pattern = ^(?<user>.*?)((\\\\(?<at>@)(?<suffix>.*?)@.*)|(?<realm>@.*))$
config.mapAuthRecord.regex.replacement = ${user}${at}${suffix}

Создайте файл openidc-authz.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-authz
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.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.artifact.name.arg = OIDC_CLAIM_preferred_username
config.artifact.groups.arg = OIDC_CLAIM_groups

Создайте файл 99-enable-external-auth.conf в /etc/ovirt-engine/engine.conf.d/ со следующим содержимым:

ENGINE_SSO_ENABLE_EXTERNAL_SSO=true
ENGINE_SSO_EXTERNAL_SSO_LOGOUT_URI="${ENGINE_URI}/callback"
EXTERNAL_OIDC_USER_INFO_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/userinfo
EXTERNAL_OIDC_TOKEN_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/token
EXTERNAL_OIDC_LOGOUT_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/logout
EXTERNAL_OIDC_CLIENT_ID=ovirt-engine
EXTERNAL_OIDC_CLIENT_SECRET="<client_SSO _generated_key>"
EXTERNAL_OIDC_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
EXTERNAL_OIDC_HTTPS_PKI_TRUST_STORE_PASSWORD=""
EXTERNAL_OIDC_SSL_VERIFY_CHAIN=false
EXTERNAL_OIDC_SSL_VERIFY_HOST=false

Конфигурирование OVN

При конфигурировании ovirt-ovn-provider в Менеджере управления, необходимо сконфигурировать учетные данные провайдера OVN.

Процедура

Создайте файл 20-setup-ovirt-provider-ovn.conf в /etc/ovirt-provider-ovn/conf.d/ со следующим содержимым, где user1 относится к группе LDAP ovirt-administrator, а openidchttp - это профиль, настроенный под aaa-ldap-misc.
```
[OVIRT]
# ovirt-admin-user-name=user1@openidchttp
```
Перезапустите ovirt-provider-ovn:
```
systemctl restart ovirt-provider-ovn
```
Авторизуйтесь на Портале администрирования, нажмите Управление (Administration) → Провайдеры (Providers), выберите ovirt-provider-ovn и нажмите Изменить (Edit), чтобы обновить пароль провайдера OVN.

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

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

ПО «zVirt Max» использует средства управления авторизацией, основанные на сочетании трех компонентов:

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

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

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

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

3.8. Администрирование пользовательских задач с Портала администрирования

3.8.1. Добавление пользователей и назначение разрешений Пользовательского портала

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

Процедура

В верхней панели нажмите Управление (Administration) → Настройка (Configure). Откроется окно Настройка (Configure).
Нажмите Системные разрешения (System Permissions).
Нажмите Добавить (Add). Откроется окно Добавить системные разрешения пользователю (Add System Permission to User).
Выберите профиль в разделе Поиск (Search). Профиль – это домен, в котором вы хотите искать. Введите имя или часть имени в текстовое поле и нажмите Искать (GO). Либо нажмите Искать (GO), чтобы просмотреть список всех пользователей и групп.
Установите нужные флажки, чтобы выбрать необходимых пользователей и группы.
Выберите соответствующую роль для назначения в разделе Роль для связи (Role to Assign). Роль UserRole предоставляет учетной записи пользователя разрешение авторизоваться на Пользовательском портале.
Нажмите OK.

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

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

Процедура

Нажмите Управление (Administration) → Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Нажмите имя пользователя. Откроется подробное представление, при этом на вкладке Общие (General) обычно отображается общая информация, такая как имя домена, адрес электронной почты и статус пользователя.
Другие вкладки позволяют просматривать информацию о группах, разрешениях, квотах и событиях для соответствующего пользователя.

Например, для просмотра групп, которым принадлежит пользователь, откройте вкладку Группы из каталогов (Directory Groups).

3.8.3. Просмотр пользовательских разрешений в отношении ресурсов

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

Процедура

Найдите и нажмите на имя ресурса. Откроется подробное представление.
Откройте вкладку Разрешения (Permissions), чтобы вывести список назначенных пользователей с информацией о роли каждого из них и унаследованных разрешениях для выбранного ресурса.

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

Если учетная запись пользователя больше не нужна, удалите ее из ПО «zVirt Max».

Процедура

Нажмите Управление (Administration) → Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Выберите пользователя для удаления. Убедитесь в том, что у него не запущена какая-либо виртуальная машина.
Нажмите Удалить (Remove), затем нажмите OK.

Пользователь удаляется из ПО «zVirt Max», но не из внешнего каталога.

3.8.5. Просмотр авторизованных пользователей

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

Нажмите Управление (Administration) → Сеансы активных пользователей (Active User Sessions), чтобы просмотреть Идентификатор БД сеанса (Session DB ID), Имя пользователя (User Name), Провайдера авторизации (Authorization provider), Идентификатор пользователя (User id), IP-адрес источника (Source IP), Время начала сеанса (Session Start Time) и Время последней активности в сеансе (Session Last Active Time) для каждого авторизованного пользователя.

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

Можно завершить сеанс пользователя, который в данный момент находится в системе.

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

Нажмите Управление (Administration) → Сеансы активных пользователей (Active User Sessions).
Выберите сеанс пользователя, который нужно завершить.
Нажмите Завершить сеанс (Terminate Session).
Нажмите OK.

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

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

Типичные примеры представлены в настоящем разделе.

Требуется авторизация на машине с Менеджером управления.

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

Можно создать новую учетную запись пользователя. При желании командой --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

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

3.9.2. Установка пароля пользователя

Можно создать пароль. Нужно задать значение для --password-valid-to, иначе срок действия пароля будет по умолчанию установлен как истекающий прямо сейчас. Дата указывается в формате гггг-ММ-дд ЧЧ:мм:ссX (yyyy-MM-dd HH:mm:ssX). В этом примере -0800 обозначает GMT минус 8 часов. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool user password-reset --help.

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

user added successfully

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

Минимум 6 знаков.
При изменении пароля нельзя снова использовать три предыдущих пароля.

Для получения дополнительной информации о политике паролей и других настройках по умолчанию выполните ovirt-aaa-jdbc-tool settings show.

После обновления пароля администратора изменения должны быть вручную распространены на ovirt-provider-ovn. В противном случае пользователь с правами администратора будет заблокирован, так как Менеджер управления продолжит использовать старый пароль для синхронизации сетей из ovirt-provider-ovn. Чтобы распространить новый пароль на ovirt-provider-ovn, сделайте следующее:

На Портале администрирования нажмите Управление (Administration) → Провайдеры (Providers).
Выберите ovirt-provider-ovn.
Нажмите Изменить (Edit) и введите новый пароль в поле Пароль (Password).
Нажмите Тестировать (Test), чтобы проверить, проходит ли успешно аутентификация с предоставленными учетными данными.
После успешной проверки аутентификации нажмите ОК.

3.9.3. Настройка допустимого периода неактивности пользователя

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

engine-config --set UserSessionTimeOutInterval= integer(укажите число)

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

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

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

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

Выполните следующую команду:
```
/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode
```
Скрипт запросит ввод пароля.

Либо с помощью параметра --password=file:file можно зашифровать один пароль, который отображается как первая строка файла. Такой параметр полезен при автоматизации. В следующем примере 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
```

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

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

ovirt-aaa-jdbc-tool user show test1

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

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

Информацию о пользователе (например, адрес электронной почты) можно обновить:

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

3.9.7. Удаление пользователя

Учетную запись пользователя можно удалить:

ovirt-aaa-jdbc-tool user delete test1

Удалите пользователя с Портала администрирования. Для получения дополнительной информации см. Раздел 3.3.9.4. Удаление пользователей.

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

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

Процедура

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Убедитесь, что в среду добавлен другой пользователь с ролью SuperUser. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.
Отключите пользователя admin по умолчанию:
```
#ovirt-aaa-jdbc-tool user edit `admin` --flag=+disabled
```

Чтобы подключить отключенного пользователя, выполните команду ovirt-aaa-jdbc-tool user edit username --flag=-disabled.

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

С помощью инструмента 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
```
Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help.
Посмотреть подробные сведения об учетной записи группы:
```
ovirt-aaa-jdbc-tool group show group1
```
Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.

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

Далее показано, как создавать группы внутри групп.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте первую группу:
```
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
```
Добавьте первую группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.

3.9.10. Опрашивание пользователей и групп

Модуль запросов (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):
  ovirt-aaa-jdbc-tool query --what=group --pattern="department=marketing"

3.9.11. Управление настройками учетной записи

Чтобы изменить настройки учетной записи по умолчанию, используйте модуль ovirt-aaa-jdbc-tool settings.

Обновление настроек учетной записи

Далее показано, как обновить настройки учетной записи по умолчанию.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Чтобы увидеть все доступные настройки, выполните команду:
```
ovirt-aaa-jdbc-tool settings show
```

Измените необходимые настройки:

В этом примере заданная по умолчанию длительность сеанса после авторизации изменена на 60 минут для всех учетных записей пользователей. Значение по умолчанию – 10 080 минут.
```
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 <имя пользователя>.

3.10. Конфигурирование дополнительных локальных доменов

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

Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений ПО «zVirt Max» и должны быть обновлены вручную при каждом новом релизе. Подробные сведения о создании дополнительных локальных доменов и о том, как обновлять домены, см. в файле README, расположенном в каталоге /usr/share/doc/ovirt-engine-extension-aaa-jdbc-<version>/README.admin.

4. Квоты и политика SLA

4.1. Введение в квоты

Квота – это инструмент ограничения ресурсов, предоставляемый с ПО «zVirt Max». Квоту можно рассматривать как слой ограничений поверх слоя ограничений, установленных разрешениями пользователя.

Квота – это объект центра данных.

Квота позволяет администраторам ПО «zVirt Max» ограничивать доступ пользователей к памяти, ЦП и хранилищу. Квота определяет ресурсы памяти и хранилища, которые администратор может назначить пользователям. В результате пользователи могут использовать только назначенные им ресурсы. Когда ресурсы по квоте исчерпаны, ПО «zVirt Max» не разрешает дальнейшие действия пользователей.

Существует два вида квот:

Таблица 3. Два вида квот
Тип квоты	Определение
Квота на ресурсы среды выполнения (Run-time Quota)	Эта квота ограничивает потребление ресурсов среды выполнения (например, ЦП и память).
Квота хранения (Storage Quota)	Эта квота ограничивает объем доступного хранилища.

У квоты, как и у SELinux, может быть три режима:

Таблица 4. Режимы квот
Режим квотирования	Описание
Принудительный (Enforced)	В этом режиме действует квота, установленная в режиме Аудита, которая ограничивает ресурсы для группы или пользователя, на которых распространяется квота.
Аудит (Audit)	В этом режиме регистрируются нарушения квот без блокировки пользователей, и он может использоваться для проверки квот. В режиме Аудита можно увеличить или уменьшить объем квоты на ресурсы среды выполнения и объем квоты хранения, доступный пользователям, на которых распространяется квота.
Выключенный (Disabled)	Этот режим отключает ограничения на ресурсы среды выполнения и ресурсы хранения, заданные квотой.

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

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

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

Квота позволяет совместно использовать ресурсы одного оборудования. Можно использовать жесткие и мягкие пороговые значения. Администраторы могут использовать квоту для установки пороговых значений по ресурсам. Для пользователя эти пороговые значения выглядят как 100% использование определенного ресурса. Для предотвращения сбоев в случае, когда заказчик внезапно превышает пороговое значение, в интерфейсе предусмотрен объем, на который можно без последствий кратковременно превысить пороговое значение. При превышении пороговых значений заказчику отправляется предупреждение.

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

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

Чтобы можно было включить виртуальную машину, ей должна быть назначена квота.

Чтобы можно было создать моментальный снимок виртуальной машины, диску, ассоциированному с виртуальной машиной, должна быть назначена квота.

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

4.2. Общая квота и индивидуально установленная квота

Пользователи с разрешениями Суперпользователя (SuperUser) могут создавать квоты для отдельных пользователей или квоты для групп.

Групповые квоты могут быть установлены для пользователей Active Directory. Если группе из десяти пользователей предоставлена квота в 1 ТБ хранилища, а один из десяти пользователей заполнит весь терабайт, то вся группа превысит квоту, и ни один из десяти пользователей не сможет использовать хранилище, ассоциированное с их группой.

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

4.3. Учет квот

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

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

Пример учета

Пользователь запускает виртуальную машину с 1 виртуальным ЦП и 1024 МБ памяти. Это действие потребляет 1 виртуальный ЦП и 1024 МБ из квоты, назначенной этому пользователю. После остановки виртуальной машины 1 виртуальный ЦП и 1024 МБ оперативной памяти высвобождаются и возвращаются обратно в квоту, назначенную этому пользователю.

Потребление квоты на ресурсы среды выполнения учитывается только во время фактического времени работы программ потребителя.

Пользователь создает виртуальный диск объемом 10 ГБ с динамическим выделением пространства. Фактическое использование диска может показать, что на самом деле используется только 3 ГБ этого диска. Однако квота потребления составит 10 ГБ, т.е. максимальный объем этого диска с учетом возможного роста.

4.4. Включение и изменение режима квотирования в центре данных

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

Используйте режим Аудит (Audit) для проверки квоты, чтобы убедиться, что она работает в соответствии с вашими ожиданиями. Чтобы создать или изменить квоту, не обязательно использовать режим Аудит (Audit).

Процедура

Нажмите Ресурсы (Compute) → Центры данных (Data Centers) и выберите центр данных.
Нажмите Изменить (Edit).
В выпадающем списке Режим квотирования (Quota Mode) измените режим квотирования на Принудительный (Enforced).
Нажмите OK.

Если во время проверки задать режим квотирования Аудит (Audit), то необходимо будет изменить его на Принудительный (Enforced), чтобы настройки квот вступили в силу.

4.5. Создание новой политики квотирования

Вы включили режим квотирования Аудит (Audit) или Принудительный (Enforcing). Теперь необходимо задать политику квотирования для управления использованием ресурсов в центре данных.

Процедура

Нажмите Управление (Administration) → Квота (Quota).
Нажмите Добавить (Add).
Заполните поля Имя (Name) и Описание (Description).
Выберите Центр данных (Data Center).
В разделе Память и ЦП (Memory & CPU) используйте зеленый бегунок, чтобы задать Пороговое значение в кластере (Cluster Threshold).
В разделе Память и ЦП (Memory & CPU) используйте синий бегунок, чтобы задать Допустимое превышение в кластере (Cluster Grace).
Кнопкой-переключателем выберите Все кластеры (All Clusters) или Указанные кластеры (Specific Clusters). Если вы выбрали Указанные кластеры (Specific Clusters), то отметьте флажками кластеры, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
- В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле МБ (MB).
- В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).
- Нажмите OK в окне Изменить квоту (Edit Quota).
В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).
В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).
Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Определенные домены хранения (Specific Storage Domains). Если вы выбрали Определенные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
- В поле Квота хранения (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле ГБ (GB).
- Нажмите OK в окне Изменить квоту (Edit Quota).
Нажмите OK в окне Создать квоту (New Quota).

4.6. Описание настроек пороговых значений квоты

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

Если квота установлена на 100 ГБ с допустимым превышением в 20%, то потребителям заблокируют доступ к ресурсам хранилища после того, как они заполнят 120 ГБ хранилища. Если для той же квоты установлено

Пороговое значение 70%, то потребители получат предупреждение, когда заполнят больше 70 ГБ хранилища (но при этом они смогут использовать хранилище до тех пор, пока не заполнят 120 ГБ хранилища).

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

4.7. Назначение квоты объекту

Назначение квоты виртуальной машине

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines) и выберите виртуальную машину.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую виртуальная машина будет потреблять.
Нажмите OK.

Назначение квоты диску

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Нажмите на имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks) и выберите диск, который собираетесь ассоциировать с квотой.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую диск будет потреблять.
Нажмите OK.

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

4.8. Использование квоты для ограничения ресурсов, доступных пользователю

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

Процедура

Нажмите Управление (Administration) → Квота (Quota).
Нажмите на имя целевой квоты. Откроется подробное представление.
Откройте вкладку Потребители (Consumers).
Нажмите Добавить (Add).
В поле Поиск (Search) введите имя пользователя, которого хотите ассоциировать с квотой.
Нажмите Искать (GO).
Поставьте флажок рядом с именем пользователя.
Нажмите OK.

Вскоре пользователь появится на вкладке Потребители (Consumers) в подобном представлении.

4.9. Изменение квот

Далее показано, как изменять существующие квоты.

Процедура

Нажмите Управление (Administration) → Квота (Quota) и выберите квоту.
Нажмите Изменить (Edit).
Измените поля согласно потребностям.
Нажмите OK.

4.10. Удаление квот

Далее показано, как удалять квоты.

Процедура

Нажмите Управление (Administration) → Квота (Quota) и выберите квоту.
Нажмите Удалить (Remove).
Нажмите OK.

4.11. Принудительное применение политики SLA

Далее показано, как задать SLA для функций ЦП

Процедура

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Нажмите Создать (New) или выберите виртуальную машину и нажмите Изменить (Edit).
Откройте вкладку Выделение ресурсов (Resource Allocation).
Укажите Общие ЦП (CPU Shares). Возможные варианты: Низкая (Low), Средняя (Medium), Высокая (High), Настраиваемый (Custom) и Выключенная (Disabled). Виртуальные машины c настройкой Высокая (High) получают в два раза больше долей, чем с настройкой Средняя (Medium), а виртуальные машины с настройкой Средняя (Medium) получают в два раза больше долей, чем виртуальные машины с настройкой Низкая (Low). Настройка Выключенная (Disabled) даёт VDSM указание использовать старый алгоритм для распределения долей; как правило, при таких условиях количество распределяемых долей равно 1020.

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

5. Уведомления о событиях

5.1. Настройка уведомлений о событиях на Портале администрирования

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

Процедура

Убедитесь, что у вас есть доступ к почтовому серверу, который может принимать автоматические сообщения от Менеджера управления и доставлять их по списку рассылки.
Нажмите Управление (Administration) → Пользователи (Users) и выберите пользователя.
Нажмите на Имя пользователя (User Name), чтобы открыть подробное представление.
На вкладке Уведомление о событиях (Event Notifier) нажмите Управление событиями (Manage Events).
Нажмите на кнопку Развернуть все (Expand All) или специальные кнопки расширения, чтобы просмотреть события.
Поставьте необходимые флажки.

Укажите адрес электронной почты в поле Получатель почты (Mail Recipient).

Адрес электронной почты может быть указан как адрес электронной почты для текстовых сообщений (например, 1234567890@carrierdomainname.com) или как групповой адрес электронной почты, в который входят как адреса электронной почты, так и адреса электронной почты для текстовых сообщений.

Нажмите OK.

На машине с Менеджером управления скопируйте 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.

#---------------------#
# 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
```

Теперь указанный пользователь будет получать сообщения по электронной почте о событиях в ПО «zVirt Max». Выбранные события отображаются для этого пользователя на вкладке Уведомление о событиях (Event Notifier).

5.2. Отмена уведомлений о событиях на Портале администрирования

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

Процедура

Нажмите Управление (Administration) → Пользователи (Users).
Нажмите на Имя пользователя (User Name). Откроется подробное представление.
Откройте вкладку Уведомление о событиях (Event Notifier), чтобы увидеть список событий, о которых пользователь получает уведомления по электронной почте.
Нажмите Управление событиями (Manage Events).
Нажмите кнопку Развернуть все (Expand All) или специальные кнопки расширения, чтобы просмотреть события.
Снимите необходимые флажки, чтобы удалить уведомления для этого события.
Нажмите OK.

5.3. Параметры уведомлений о событиях в ovirt-engine-notifier.conf

Файл конфигурации службы уведомлений о событиях находится в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf.

Таблица 6. Переменные ovirt-engine-notifier.conf

Имя переменной

Default (По умолчанию)

Примечания

SENSITIVE _ KEYS

Нет

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

JBOSS_HOME

/opt/rh/eap7/root/usr/share/wildfly

Местонахождение сервера приложений JBoss, используемого Менеджером управления.

ENGINE_ETC

/etc/ovirt-engine

Местонахождение каталога etc, используемого Менеджером управления.

ENGINE_LOG

/var/log/ovirt-engine

Местонахождение каталога logs, используемого Менеджером управления.

ENGINE_USR

/usr/share/ovirt-engine

Местонахождение каталога usr, используемого Менеджером управления.

ENGINE_JAVA_MODULEPATH

$ { ENGINE _ USR}/modules

Полный путь для подсоединения модулей JBoss.

NOTIFIER_DEBUG_ADDRESS

Нет

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

NOTIFIER_STOP_TIME

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

NOTIFIER_STOP_INTERVAL

Время (в секундах), на которое увеличивается значение счетчика времени ожидания.

INTERVAL_IN_SECONDS

120

Интервал (в секундах) между ситуациями отправки сообщений подписчикам.

IDLE_INTERVAL

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

DAYS_TO_KEEP_HISTORY

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

FAILED_QUERIES_NOTIFICATION_THRESHOLD

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

FAILED_QUERIES_NOTIFICATION_RECIPIENTS

Нет

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

DAYS_TO_SEND_ON_STARTUP

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

FILTER

exclude: *

Алгоритм, используемый для определения триггеров и получателей уведомлений по электронной почте. Значение этой переменной представляет собой комбинацию операторов включить (include) или исключить (exclude), события и получателя. Например, include:VDC _ START(smtp:mail@example.com) $ { FILTER}

MAIL_SERVER

Нет

Адрес почтового сервера SMTP. Обязательный параметр.

MAIL_PORT

Порт, используемый для связи. Возможные значения: 25 для простого SMTP, 465 для SMTP с SSL и 587 для SMTP с TLS.

MAIL_USER

Нет

Если для аутентификации пользователя включен SSL, то эту переменную нужно задать. Эта переменная также используется для указания адреса пользователя-отправителя, когда переменная MAIL _ FROM не задана. Некоторые почтовые серверы не поддерживают эту функцию. Адрес имеет формат RFC822.

SENSITIVE_KEYS

$ { SENSITIVE _ KEYS},MAIL _ PASSWORD

Требуется для аутентификации пользователя, если почтовый сервер требует аутентификации или если SSL или TLS включены.

MAIL_PASSWORD

Нет

MAIL_SMTP_ENCRYPTION

Нет

Тип шифрования, который должен использоваться для связи. Возможные значения: none, ssl и tls.

HTML_MESSAGE_FORMAT

false

Почтовый сервер отправляет сообщения в формате HTML, если эта переменная установлена в значение true.

MAIL_FROM

Нет

Эта переменная указывает адрес отправителя в формате RFC822, если он поддерживается почтовым сервером.

MAIL_REPLY_TO

Нет

Эта переменная указывает адреса получателя в формате RFC822 для отправляемых писем, если это поддерживается почтовым сервером.

MAIL_SEND_INTERVAL

Число SMTP-сообщений, которые должны отправляться в каждый IDLE _ INTERVAL

MAIL_RETRIES

Количество попыток отправить электронной сообщение, пока не будет признан факт неудачи.

SNMP_MANAGERS

Нет

IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, manager1.example.com manager2.example.com:164

SNMP_COMMUNITY

public

(только SNMP версии 2) SNMP Community.

SNMP_OID

1.3.6.1.4.1.2312.13.1.1

Идентификаторы объектов-ловушек по умолчанию для оповещений. Когда этот OID определен, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления.

SNMP_VERSION

Определяет, какую версию SNMP следует использовать. Поддерживаются ловушки SNMP версий 2 и 3. Возможные значения: 2 или 3.

SNMP_ENGINE_ID

Нет

(SNMPv3) Идентификатор Менеджера управления, используемый для ловушек SNMPv3. Это уникальный идентификатор устройства, подключенного через SNMP.

SNMP_USERNAME

Нет

(SNMPv3) Имя пользователя, используемое для ловушек SNMPv3.

SNMP_AUTH_PROTOCOL

Нет

(SNMPv3) Протокол авторизации SNMPv3. Возможные значения: MD5, SHA

SNMP_AUTH_PASSPHRASE

Нет

(SNMPv3) Парольная фраза, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH_NOPRIV и AUTH_PRIV.

SNMP_PRIVACY_PROTOCOL

Нет

(SNMPv3) Протокол обеспечения конфиденциальности SNMPv3. Возможные значения: AES128, AES192, AES256

Протоколы AES192 и AES256 не определены в RFC3826, поэтому перед их включением убедитесь, что ваш SNMP-сервер поддерживает их.

SNMP_PRIVACY_PASSPHRASE

Нет

Парольная фраза обеспечения конфиденциальности SNMPv3, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH _ PRIV.

SNMP_SECURITY_LEVEL

(SNMPv3) Уровень безопасности SNMPv3. Возможные значения: * 1 - NOAUTH_NOPRIV * 2 - AUTH_NOPRIV * 3 - AUTH_PRIV

ENGINE_INTERVAL_IN_SECONDS

300

Интервал (в секундах) между операциями мониторинга машины, на которой установлен Менеджер управления. Этот интервал измеряется с момента завершения мониторинга.

ENGINE_MONITOR_RETRIES

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

ENGINE_TIMEOUT_IN_SECONDS

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

IS_HTTPS_PROTOCOL

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в безопасном режиме.

SSL_PROTOCOL

TLS

Протокол, используемый коннектором конфигурации JBoss, когда включен SSL.

SSL_IGNORE_CERTIFICATE_ERRORS

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в защищенном режиме и ошибки SSL должны игнорироваться.

SSL_IGNORE_HOST_VERIFICATION

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в защищенном режиме и верификация имени хоста должна игнорироваться.

REPEAT_NON_RESPONSIVE_NOTIFICATION

false

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

ENGINE_PID

/var/lib/ovirt-engine/ovirt-engine.pid

Путь и имя PID-файла Менеджера управления.

5.4. Настройка Менеджера управления на отправку ловушек SNMP

Настройте Менеджер управления на отправку ловушек SNMP одному или нескольким внешним менеджерам SNMP. Ловушки SNMP содержат информацию о системных событиях; они используются для мониторинга ПО «zVirt Max». Количество и тип ловушек, отправляемых менеджеру SNMP, можно задать в Менеджере управления.

ПО «zVirt Max» поддерживает SNMP версий 2 и 3. SNMP версии 3 поддерживает следующие уровни безопасности:

NoAuthNoPriv

Ловушки SNMP отправляются без какой-либо авторизации или конфиденциальности.
AuthNoPriv

Ловушки SNMP отправляются с авторизацией по паролю, но без конфиденциальности.
AuthPriv

Ловушки SNMP отправляются с авторизацией по паролю и с конфиденциальностью.

Предварительные условия

Один или несколько внешних менеджеров SNMP настроены на получение ловушек.
IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. При желании задайте порт, через который Менеджер управления получает уведомления о ловушках. По умолчанию: UDP-порт 162.
SNMP Community (только для SNMP версии 2). Несколько менеджеров SNMP могут принадлежать одному сообществу. Системы управления и агенты могут взаимодействовать, только если они находятся в одном сообществе. Сообщество по умолчанию – public.
Идентификатор объекта-ловушки для оповещений. OID, который Менеджер управления предоставляет по умолчанию – 1.3.6.1.4.1.2312.13.1.1. Когда этот OID задан, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления.
Имя пользователя SNMP, для SNMP версии 3, уровни безопасности 1, 2 и 3.
Парольная фраза SNMP, для SNMP версии 3, уровни безопасности 2 и 3.
Парольная фраза обеспечения конфиденциальности SNMP, для SNMP версии 3, уровень безопасности 3.

Менеджер управления предоставляет следующие информационные базы управления (MIB): /usr/share/doc/ovirt-engine/mibs/OVIRT-MIB.txt и /usr/share/doc/ovirt-engine/mibs/REDHAT-MIB.txt. Прежде чем продолжать, загрузите MIB в менеджер SNMP.

Значения параметров конфигурации SNMP по умолчанию имеются в Менеджере управления в файле конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. Значения, приведенные в следующей процедуре, основаны на значениях по умолчанию или взятых для примера значениях, представленных в этом файле. Не изменяйте этот файл напрямую, так как системные изменения, такие как обновления, могут аннулировать любые внесенные в этот файл изменения. Вместо этого скопируйте этот файл в /etc/ovirt-engine/notifier/notifier.conf.d/ < integer > -snmp.conf, где < integer > – это число, указывающее приоритет, с которым должен выполняться этот файл.

Процедура

В Менеджере управления создайте файл конфигурации SNMP с именем < integer > -snmp.conf, где < integer > – это целое число, указывающее порядок обработки файлов. Например:

vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

Укажите менеджера(ов) SNMP, SNMP Community (только для 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 authpass.
```
SNMP_USERNAME=ovirtengine
SNMP_AUTH_PROTOCOL=MD5
SNMP_AUTH_PASSPHRASE=authpass
SNMP_SECURITY_LEVEL=2
```
Уровень безопасности 3, ловушки AuthPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP 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

Отправлять все события на 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/ <integer> -snmp.conf, где <integer> – число, указывающее приоритет, с которым должен выполняться файл. В этом файле есть комментарии по всем настройкам.

/etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

SNMP_MANAGERS="manager1.example.com manager2.example.com:162" (1)
SNMP_COMMUNITY=public (2)
SNMP_OID=1.3.6.1.4.1.2312.13.1.1 (3)
FILTER="include:*(snmp:)" (4)
SNMP_VERSION=3 (5)
SNMP_ENGINE_ID="80:00:00:00:01:02:05:05" (6)
SNMP_USERNAME=<username> (7)
SNMP_AUTH_PROTOCOL=MD5 (8)
SNMP_AUTH_PASSPHRASE=<authpass> (9)
SNMP_PRIVACY_PROTOCOL=AES128 (10)
SNMP_PRIVACY_PASSPHRASE=<privpass> (11)
SNMP_SECURITY_LEVEL=3 (12)

1	IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, `manager1.example.com` `manager2.example.com:164`
2	(только SNMP версии 2) строка по умолчанию для SNMP Community.
3	Идентификатор объекта-ловушки SNMP для исходящих уведомлений. `iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) redhat(2312) ovirt(13) engine(1) notifier(1)`
4	Алгоритм, используемый для определения триггеров и получателей уведомлений SNMP.
5	Версия SNMP. Поддерживаются ловушки SNMP версий 2 и 3. `2` = SNMPv2, `3` = SNMPv3.
6	(только SNMP версии 3) Идентификатор engine, используемый для ловушек SNMP.
7	(только SNMP версии 3) Имя пользователя, используемое для ловушек SNMP.
8	(только SNMP версии 3) Протокол авторизации SNMP. Поддерживаемые значения – `MD5` и `SHA`. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `2` (AUTH_NOPRIV) или `3` (AUTH_PRIV).
9	(только SNMP версии 3) Парольная фраза для авторизации по SNMP. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `2` (AUTH_NOPRIV) или `3` (AUTH_PRIV).
10	(только SNMP версии 3) Протокол обеспечения конфиденциальности SNMP. Поддерживаемые значения – `AES128`, `AES192` и `AES256`. Имейте в иду, что протоколы AES192 и AES256 не заданы в RFC3826, поэтому перед их включением убедитесь, что ваш SNMP-сервер поддерживает их. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `3` (AUTH_PRIV).
11	(только SNMP версии 3) Парольная фраза обеспечения конфиденциальности SNMP. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `3` (AUTH_PRIV).
12	(только SNMP версии 3) Уровень безопасности SNMP. `1` = NOAUTH_NOPRIV, `2` = AUTH_NOPRIV, `3` = AUTH_PRIV.

6. Утилиты

6.1. Инструмент переименования oVirt Engine

6.1.1. Инструмент переименования oVirt Engine

Когда команда engine-setup выполняется в чистой среде, она генерирует ряд сертификатов и ключей, которые используют FQDN Менеджера управления, сообщенное во время установки. Если FQDN Менеджера управления впоследствии потребуется изменить (например, из-за переноса машины с Менеджером управления в другой домен), то записи об FQDN должны быть обновлены, чтобы отразить новое имя. Команда ovirt-engine-rename автоматизирует эту задачу.

Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления в следующих местах:

/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

В процессе обновления прежний FQDN должен разрешаться с помощью DNS.

Если в процессе работы ovirt-engine-rename завершается с ошибкой:

[ ERROR ] Hostname is not valid: <OLD FQDN> did not resolve into an IP address

необходимо добавить прежний FQDN в файл /etc/hosts.

Команда ovirt-engine-rename не обновляет SSL-сертификаты для таких сервисов, как imageio-proxy или websocket-proxy. Сертификаты необходимо обновить вручную после выполнения ovirt-engine-rename.

После выполнения процедуры смены FQDN менеджера управления не удаляйте старое имя хоста из файла /etc/hosts, так как оно необходимо для корректной работы внутренних служб менеджера управления.

6.1.2. Синтаксис команды переименования oVirt Engine

Базовый синтаксис команды ovirt-engine-rename:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

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

--newname= [ new name ]

Позволяет указать новое FQDN для Менеджера управления без взаимодействия с пользователем.
--log= [ file ]

Позволяет указать путь и имя файла, в который должны быть записаны журналы операции переименования.
--config= [ file ]

Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования.
--config-append= [ file ]

Позволяет указать путь и имя файла конфигурации для подключения к операции переименования. Этот параметр можно использовать для указания пути и имени существующего файла ответов для автоматизации операции переименования.
--generate-answer= [ file ]

Позволяет указать путь и имя файла, в котором записаны ответы и значения, измененные командой ovirt-engine-rename.

6.1.3. Переименование Менеджера управления с помощью инструмента переименования oVirt Engine

Можно использовать команду ovirt-engine-rename для обновления записей об FQDN Менеджера управления.

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

Процедура

Подготовьте все DNS и другие относящиеся к делу записи для нового FQDN.
Обновите конфигурацию DHCP-сервера, если DHCP используется.
Обновите имя хоста в Менеджере управления.

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

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

При появлении запроса нажмите Ввод (Enter), чтобы остановить службу engine:
```
During execution engine service will be stopped (btn:[OK], Cancel)
 [ btn:[OK] ] :
```
При появлении запроса введите новое FQDN для Менеджера управления:
```
New fully qualified server name: new_engine_fqdn
```
Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления.

Для hosted engine выполните следующие дополнительные шаги:

Выполните следующую команду на каждом существующем узле с ролью hosted engine:
```
hosted-engine --set-shared-config fqdn new_engine_fqdn   --type=he_local
```
Эта команда изменяет FQDN в локальной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf, имеющейся на каждом узле с ролью hosted engine.
Выполните следующую команду на одном из узлов с ролью hosted engine:
```
# hosted-engine --set-shared-config fqdn_new_engine_fqdn  --type=he_shared
```
Эта команда изменяет FQDN в мастер-копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf в общем домене хранения.

Теперь все новые и существующие узлы с ролью hosted engine используют новое FQDN.

6.2. Инструмент настройки Engine

6.2.1. Инструмент настройки Engine

Инструмент настройки engine – это утилита командной строки для настройки глобальных параметров ПО «zVirt Max». Инструмент взаимодействует со списком сопоставлений "ключ-значение", которые хранятся в базе данных engine, и позволяет извлекать и задавать значения отдельных ключей, а также извлекать список всех доступных ключей и значений конфигурации. Кроме того, для каждого уровня конфигурации в ПО «zVirt Max» могут храниться разные значения.

6.2.2. Синтаксис команды engine-config

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

engine-config --help

Распространенные задачи:

Перечислить доступные ключи конфигураци
```
engine-config --list
```
Перечислить доступные значения конфигурации
```
engine-config --all
```
Извлечь значение ключа конфигурации
```
engine-config --get  KEY_NAME
```
Вместо KEY_NAME укажите имя нужного ключа, чтобы извлечь значение для заданной версии ключа. С помощью параметра --cver укажите версию конфигурации, для которой нужно извлечь значение. Если версия не указана, будут возвращены значения для всех существующих версий.
Задать значение ключа конфигурации
```
engine-config --set  KEY_NAME =KEY_VALUE --cver=VERSION
```
Вместо KEY_NAME укажите имя конкретного ключа, значение которого нужно задать, а вместо KEY_VALUE – значение, которое нужно задать. В средах, где имеется несколько версий конфигурации, необходимо указать VERSION.
Перезапустите службу ovirt-engine, чтобы загрузить изменения.
```
systemctl restart ovirt-engine.service
```

6.3. Инструмент USB Filter Editor

6.3.1. Установка инструмента USB Filter Editor

USB Filter Editor – это инструмент Windows, используемый для настройки файла политик usbfilter.txt. Правила политики, определенные в этом файле, разрешают или запрещают конкретным USB-устройствам автоматический сквозной доступ с клиентских машин на виртуальные машины, управляемые с помощью Менеджера управления. Файл политики находится в Менеджере управления здесь: /etc/ovirt-engine/usbfilter.txt Изменения, внесенные в политики фильтров USB, не вступят в силу, пока не будет перезапущена служба ovirt-engine на Менеджере управления.

На машине Windows извлеките установщик .msi из файла .zip и запустите установщик .msi.
Следуйте инструкциям мастера установки. Если не указано иное, то USB Filter Editor будет установлен по умолчанию в папку C: \ Program Files \ RedHat \ USB Filter Editor или C: \ Program Files(x86) \ RedHat \ USB Filter Editor в зависимости от версии Windows.
На рабочем столе будет создан ярлык USB Filter Editor.

Для импорта и экспорта политик фильтров из Менеджера управления используйте клиент Secure Copy (SCP). Инструмент Secure Copy для машин Windows называется WinSCP (http://winscp.net).

Используемая по умолчанию политика в отношении USB-устройств предоставляет виртуальным машинам базовый доступ к USB-устройствам. Чтобы разрешить использование дополнительных USB-устройств, обновите политику.

6.3.2. Интерфейс инструмента USB Filter Editor

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе.

Интерфейс инструмента Red Hat USB Filter Editor отобразит Класс (Class), Вендора (Vendor), Продукт (Product), Редакцию (Revision) и Действие (Action) для каждого USB-устройства. Для разрешенных USB-устройств в столбце Действие (Action) установлено значение Разрешить (Allow), для запрещенных – Блокировать (Block).

Таблица 7. Поля инструмента USB Editor
Имя	Описание
Класс (Class)	Тип USB-устройства (например, принтеры, контроллеры накопителей).
Вендор (Vendor)	Производитель выбранного типа устройства.
Продукт (Product)	Конкретная модель USB-устройства.
Редакция (Revision)	Редакция продукта.
Действие (Action)	Разрешить или блокировать конкретное устройство.

Правила политики в отношении USB-устройств обрабатываются в том порядке, в котором они перечислены. Кнопками Вверх (Up) и Вниз (Down) правила можно перемещать по списку. Универсальное правило Блокировать (Block) должно оставаться в самом низу списка, чтобы гарантировать, что будут запрещены все USB-устройства, если только они прямо не разрешены в инструменте USB Filter Editor.

6.3.3. Добавление политики в отношении USB

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Добавить (Add).
С помощью флажков Класс USB (USB Class), Идентификатор вендора (Vendor ID), Идентификатор продукта (Product ID) и Редакция (Revision) и списков укажите устройство.
Нажмите кнопку Разрешить (Allow), чтобы разрешить виртуальным машинам использовать USB-устройство, либо нажмите кнопку Блокировать (Block), чтобы запретить виртуальным машинам доступ к USB-устройству.
Нажмите OK, чтобы добавить выбранное правило фильтра в список, и закройте окно.

Пример. Добавление устройства

Ниже приводится пример того, как добавить Класс USB Smartcard, устройство EP-1427X-2 Ethernet Adapter производителя Acer Communications & Multimedia в список разрешенных устройств.

Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Политика в отношении USB добавлена в USB Filter Editor. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

Дополнительные ресурсы

Экспортирование политики в отношении USB

6.3.4. Удаление политики в отношении USB

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Выберите политику, которую нужно удалить.
Нажмите Удалить (Remove). Появится сообщение с предложением подтвердить удаление политики.
Нажмите Да (Yes), чтобы подтвердить удаление политики.
Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Политика в отношении USB удалена из USB Filter Editor. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

6.3.5. Поиск политик в отношении USB-устройств

Выполните поиск подключенных USB-устройств, чтобы разрешить или заблокировать их в инструменте USB Filter Editor.

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Поиск (Search). В окне Подключенные USB-устройства (Attached USB Devices) отображается список всех подключенных устройств.
Выберите устройство и нажмите Разрешить (Allow) или Блокировать (Block) соответственно. Дважды щелкните по выбранному устройству, чтобы закрыть окно. Правило политики для устройства добавлено в список.
Кнопками Вверх (Up) и Вниз (Down) измените положение нового правила политики в списке.
Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Поиск подключенных USB-устройств выполнен. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

6.3.6. Экспортирование политики в отношении USB

Чтобы обновленная политика в отношении USB-устройств вступила в силу, внесенные в нее изменения нужно экспортировать и выгрузить в Менеджер управления. Выгрузите политику и перезапустите службу ovirt-engine.

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Экспортировать (Export). Откроется окно Сохранить как (Save As).
Сохраните файл под именем usbfilter.txt.
Используя клиент Secure Copy (такой как WinSCP), выгрузите файл usbfilter.txt на сервер, где запущен Менеджер управления. Файл нужно поместить в следующий каталог на сервере: /etc/ovirt-engine/
Авторизовавшись в качестве root-пользователя на сервере с Менеджером управления, перезапустите службу ovirt-engine.
```
systemctl restart ovirt-engine.service
```

6.3.7. Импортирование политики в отношении USB

Чтобы изменить существующую политику в отношении USB-устройств, ее нужно сначала загрузить и импортировать в USB Filter Editor.

Процедура

Используя клиент Secure Copy (такой как WinSCP), загрузите файл usbfilter.txt с сервера, где запущен Менеджер управления. Файл находится в следующем каталоге на сервере: /etc/ovirt-engine/
Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.
Нажмите Импортировать (Import). Откроется окно Открыть (Open).
Откройте файл usbfilter.txt, загруженный с сервера.

6.4. Инструмент Engine Vacuum

6.4.1. Инструмент Engine Vacuum

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

Команда Engine Vacuum – engine-vacuum. Необходимо авторизоваться в системе как root-пользователь и ввести учетные данные администратора для ПО «zVirt Max».

Как альтернативный вариант, можно запустить инструмент Engine Vacuum командой 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.

(Yes, No)  [ No ] :

Опция Да (Yes) запускает инструмент Engine Vacuum в режиме полной очистки.

6.4.2. Режимы работы Engine Vacuum

Инструмент Engine Vacuum имеет два режима работы:

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

6.4.3. Синтаксис команды engine-vacuum

Базовый синтаксис команды engine-vacuum:

engine-vacuum

engine-vacuum  _option_

Запуск команды engine-vacuum без параметров выполняет стандартную очистку.

Команду engine-vacuum можно уточнить с помощью ряда параметров.

Общие параметры
- -h --help
  
  Выводит информацию о том, как использовать команду engine-vacuum.
- -a
  
  Запускает стандартную очистку, анализирует базу данных и обновляет статистику оптимизатора.
- -A
  
  Анализирует базу данных и обновляет статистику оптимизатора, не выполняя очистку.
- -f
  
  Запускает полную очистку.
- -v
  
  Задает режим детализации консольного вывода.
- -t table_name
  
  Выполняет очистку конкретной таблицы или таблиц.
  engine-vacuum -f -v -t vm_dynamic -t vds_dynamic

6.5. Инструмент сопоставления VDSM с именем сети

6.5.1. Сопоставление имен VDSM с именами логических сетей

Если имя логической сети длиннее 15 знаков или содержит знаки, отличные от ASCII, то система автоматически сгенерирует имя имя-идентификатор для использования на хосте (vdsm_name), состоящее из букв on и первых 13 знаков уникального идентификатора сети, например, ona1b2c3d4e5f6g.

Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имен логических сетей и их автоматически сгенерированных имен сетей, используйте инструмент сопоставления VDSM с именами сетей, расположенный в /usr/share/ovirt-engine/bin/.

Процедура

При первом запуске инструмента определите переменную среды PASSWORD, которая представляет собой пароль пользователя базы данных с доступом на чтение к базе данных Менеджера управления. Например, запустите:
```
export PASSWORD=DatabaseUserPassword
```
Запустите инструмент сопоставления VDSM с именем сети:
```
vdsm_to_network_name_map --user USER
```
где USER – пользователь базы данных с доступом на чтение к базе данных Менеджера управления, чей пароль назначен для переменной среды PASSWORD.

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

Дополнительные флажки

Можно запустить инструмент со следующими параметрами:

--host – имя хоста / IP-адрес сервера баз данных. Значение по умолчанию – localhost.
--port – номер порта сервера баз данных. Значение по умолчанию – 5432.
--database – имя базы данных. Значение по умолчанию – engine, представляющий собой базу данных Менеджера управления.
--secure – разрешает безопасное подключение к базе данных. По умолчанию инструмент запускается без безопасного подключения.