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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переведите все узлы с ролью hosted engine в глобальный режим обслуживания:
1. На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts) и выберите любой узел с ролью hosted engine .
2. Нажмите Дополнительные действия (More Actions) , затем нажмите Включить глобальное обслуживание высокой доступности (Enable Global HA Maintenance).
После выполнения всех задач обслуживания выключите режим обслуживания:
1. На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts) и выберите любой узел с ролью hosted engine .
2. Нажмите Дополнительные действия (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 на общем хранилище, поэтому все хосты, развернутые после изменения конфигурации, используют эти значения. Чтобы применить новое значение на хосте, повторно разверните хост.

ha

Устанавливает значения в /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 . Обновляемые ключи: email.smtp-server, email.smtp-port, email.source-email, email.destination-emails и notify.state_transition.

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

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

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

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

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

Убедитесь, что SMTP-порт по умолчанию (порт 25) настроен:
```
# hosted-engine --get-shared-config email.smtp-port --type=broker
broker : 25, type : broker
```
Укажите адрес электронной почты, который SMTP-сервер должен использовать для отправки уведомлений. Указать можно только один адрес.
```
# hosted-engine --set-shared-config email.source-email _source@example.com_ --type=broker
```
Укажите адрес электронной почты для получения уведомлений. Можно указать несколько адресов через запятую.
```
# hosted-engine --set-shared-config email.destination-emails _destination1@example.com_,_destination2@example.com_ --type=broker
```

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

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

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

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

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

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

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

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

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

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

Порядок действий:

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

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

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

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

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

Порядок действий:

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

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

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

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

Подключитесь к одному из узлов с ролью 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.7. Удаление хоста из среды hosted engine

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

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

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

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

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

Подробную информацию см. в разделе Переименование Менеджера управления с помощью инструмента oVirt Engine Rename.

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

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

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

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

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

Развертывание менеджера управления в режиме Hosted Engine.
Развертывание менеджера управления в режиме Standalone.
Развертывание менеджера управления в режиме Standalone (all-in-one).

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

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

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

# engine-backup --mode=backup

# engine-backup --mode=restore

# engine-backup --mode=verify

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

Таблица 1. Основные параметры
Параметр	Описание
`--mode`	Определяет, будет ли команда выполнять операцию резервного копирования, восстановления или проверки резервной копии. Доступны три варианта: резервное копирование (`backup`), восстановление (`restore`) и проверка резервной копии (`verify`). Это обязательный параметр.
`--file`	Указывает путь и имя файла, в который будут делаться резервные копии в режиме резервного копирования, и путь и имя файла, из которого будут считываться данные резервной копии в режиме восстановления или проверки. Это обязательный параметр.
`--log`	Указывает путь и имя файла, в который будут записываться журналы операций резервного копирования или восстановления. Этот параметр обязателен в режимах резервного копирования и восстановления.
`--scope`	Определяет охват операции резервного копирования или восстановления. По умолчанию используется значение `all`.

Таблица 2. Значения параметра --scope
Значение	Описание
`all`	Полная резервная копия всех баз данных и файлов конфигурации Менеджера управления
`files`	Резервная копия только файлов в системе
`db`	Резервная копия только базы данных Менеджера управления
`dwhdb`	Резервная копия только базы данных Хранилища (DWH)
`cinderlibdb`	Резервная копия только базы данных Cinderlib
`grafanadb`	Резервная копия только базы данных Grafana

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

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

Таблица 3. Параметры базы данных Менеджера управления
Параметр	Описание
`--provision-db`	Создает базу данных PostgreSQL, куда будет выполнено восстановление из резервной копии базы данных Менеджера управления. Это обязательный параметр при восстановлении из резервной копии на удаленном хосте или новой установке, в которой еще не сконфигурирована база данных PostgreSQL.
`--change-db-credentials`	Позволяет указать другие учетные данные, чтобы восстановление базы данных Менеджера управления можно было выполнить с использованием учетных данных, отличных от тех, что хранятся в самой резервной копии. См. дополнительные параметры, необходимые для этого параметра, с помощью команды `engine-backup --help`.
`--restore-permissions` или `--no-restore-permissions`	Восстанавливает (или не восстанавливает) разрешения пользователей базы данных. Один из этих параметров обязателен при восстановлении резервной копии.

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

2.1.3. Резервное копирование и восстановление менеджера управления развёрнутого в режиме Hosted Engine.

Исходные данные

Первый центр данных. Имя - Default.
- Имя кластера - Default. В кластере два хоста: host1.example.com и host2.example.com.
- Имя домена хранения - hosted_storage. Тип iSCSI. В домене размещена ВМ - менеджер управления.
- Имя домена хранения - storage_nfs. Тип NFS. В нём размещены диски ВМ.
- На двух хостах добавлены обязательные сети VLAN 100, 101.
Второй центр данных. Имя - DataCenter2.
- Имя кластера - Cluster2. В кластере один хост: host3.example.com.
- Имя домена хранения - storage-nfs-datacenter2. Тип NFS.
- На хост добавлена обязательная сеть VLAN 102.

Адрес менеджера управления - https://manager.example.com/ovirt-engine/

2.1.3.1. Процедура резервного копирования

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

Рекомендуемый способ резервного копирования

Подключитесь по SSH к хосту, на котором в текущий момент работает ВМ HostedEngine.
Включите режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-status
в выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !!:
Подключитесь по SSH к ВМ HostedEngine.
Остановите сервис ovirt-engine:
```
systemctl stop ovirt-engine.service
```
Cоздайте эталонную резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Создайте ещё одну резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Запустите сервис ovirt-engine:
```
systemctl start ovirt-engine.service
```
Подключитесь по SSH к хосту, на котором в текущий момент работает ВМ HostedEngine.
Выйдите из режима глобального обслуживания
```
hosted-engine --set-maintenance --mode=none
```
Проверьте, что режим глобального обслуживания выключен:
hosted-engine --vm-status
В выводе не будет сообщения:
!! Cluster is in GLOBAL MAINTENANCE mode !!

2.1.3.2. Процедура восстановления

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

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

Требования для восстановления

Для восстановления, необходимы соблюсти ряд условий:

Исходные домены хранения должны быть доступны.
Режим multipath должен быть настроен. Рекомендуемые настройки для multipath.
Произведена настройка фильтра LVM по инструкции.
Произведена настройка IP адресов, маски подсети, DNS.
Выделено не менее 60 ГБ свободного пространства на диске.

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

Перед развертыванием необходимо подготовить новое (чистое) хранилище для менеджера управления. Так же, необходимо соблюсти условия, описанные в [инструкции](#requirements).

Подключитесь на хост ранее находившихся в кластере и подготовленный для размещения ВМ HostedEngine (в данном кластере ранее был расположен менеджер управления) и командой hosted-engine --vm-status проверьте, на каком из хостов запущен (находится в аварийном режиме) менеджер управления.
Подключитесь по SSH к этому хосту.
Включите режим глобального обслуживания и отключите менеджер управления:
```
hosted-engine --set-maintenance --mode=global
hosted-engine --vm-shutdown
```
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-status
в выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !!
Проверьте командой dnf update, что репозиторий zVirt включен и доступен.
Выполните установку пакета ovirt-engine-appliance из репозитория:
```
dnf install -y ovirt-engine-appliance
```
Скопируйте резервную копию backup.bck, созданную ранее, на хост.

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

hosted-engine --deploy --restore-from-file=backup.bck

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

[ INFO  ] Stage: Environment setup
        During customization use CTRL-D to abort.
        Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine.
        The provided engine backup file will be restored there,
        it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored.
        If a reference to this host is already contained in the backup file, it will be filtered out at restore time.
        The locally running engine will be used to configure a new storage domain and create a VM there.
        At the end the disk of the local VM will be moved to the shared storage.
        The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it.
        Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration.
        Are you sure you want to continue? (Yes, No)[Yes]:  - выбрать Yes;

[ INFO  ] skipping: [localhost]

        Renew engine CA on restore if needed?
        Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine.
        Renew CA if needed? (Yes, No)[No]:  - выбрать Yes;

[ INFO  ] skipping: [localhost]
        Pause the execution after adding this host to the engine?
        You will be able to connect to the restored engine in order to manually review and remediate its configuration.
        This is normally not required when restoring an up to date and coherent backup.
        Pause after adding the host? (Yes, No)[No]:  на данном этапе необходимо выбрать ответ исходя из конфигурации среды виртуализации.
        Если на хосте необходимо произвести дополнительные настройки (например, добавить неосновные сети VLAN) выберите - Yes, если в этом нет необходимости выберите - No.

Если на предыдущем шаге Pause after adding the host? был выбран вариант ответа Yes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке. В примере это адрес https://host2.example.com:6900/ovirt-engine/ к которому можно подключиться и произвести необходимые настройки, например добавить обязательные сети VLAN.

[ INFO  ] You can now connect to https://host2.example.com: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 -> localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]

После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера. После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

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

Перед развертыванием необходимо:

Соблюсти условия, описанные в инструкции.
Все исходные хранилища должны быть доступны (в случае недоступности хранилищ будет ошибка Cannot access the Storage Domain attached to the DataCenter).
Установить zVirt Node на хост в соответствии с разделом Установка хоста виртуализации;
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;

Далее необходимо выполнить следующие шаги:

Подключитесь на любой из хостов, ранее находившихся в кластере (в данном кластере ранее был расположен менеджер управления). Если они доступны, командой hosted-engine --vm-status проверьте, на каком из хостов запущен (находится в аварийном режиме) менеджер управления.
Подключитесь по SSH к этому хосту.
Включите режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=global
hosted-engine --vm-shutdown
```
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-status
в выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !!
Подключитесь по SSH на новый хост. Проверьте командой dnf update, что репозиторий zVirt включен и доступен.
Выполните установку пакета ovirt-engine-appliance из репозитория:
```
dnf install -y ovirt-engine-appliance
```
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и начните процедуру развертывания:
```
hosted-engine --deploy --restore-from-file=backup.bck
```

На вопрос о паузе после добавления хоста необходимо выбрать Yes.

[ INFO  ] skipping: [localhost]
        Pause the execution after adding this host to the engine?
        You will be able to connect to the restored engine in order to manually review and remediate its configuration.
        This is normally not required when restoring an up to date and coherent backup.
        Pause after adding the host? (Yes, No)[No]:  Yes

На вопрос … reinstalled from the engine to update their hosted-engine configuration необходимо выбрать Yes.

[ INFO  ] Stage: Environment setup
        During customization use CTRL-D to abort.
        Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine.
        The provided engine backup file will be restored there,
        it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored.
        If a reference to this host is already contained in the backup file, it will be filtered out at restore time.
        The locally running engine will be used to configure a new storage domain and create a VM there.
        At the end the disk of the local VM will be moved to the shared storage.
        The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it.
        Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration.
        Are you sure you want to continue? (Yes, No)[Yes]: Yes;

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

На вопрос о перевыпуске сертификат необходимо ответить Yes

[ INFO  ] skipping: [localhost]

        Renew engine CA on restore if needed?
        Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine.
        Renew CA if needed? (Yes, No)[No]: Yes;

В пункте, где необходимо указать путь к архиву с OVA файлом, оставьте рекомендуемое значение по умолчанию.
Введите пароль root для менеджера управления.
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя root, и укажите, следует ли разрешить доступ SSH для пользователя root.
Введите количество vCPU и объем ОЗУ.
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
Выберите способ получения IP-адреса: DHCP или Static. Если вы укажете Static , введите IP-адрес менеджера.
Укажите, следует ли добавлять записи для менеджера управления в /etc/hosts.
Укажите данные для отправки уведомлений по электронной почте.
Введите пароль для пользователя admin@internal.
Если на шаге Pause after adding the host? был выбран вариант ответа Yes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке. В примере это адрес https://host2.example.com:6900/ovirt-engine/ к которому можно подключиться и произвести необходимые настройки, например: добавить обязательные сети VLAN, запустить домены хранения.
[ INFO ] You can now connect to https://host2.example.com: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 -> localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]
После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера.
Выберите тип используемого хранилища и укажите данные для подключения.
Выберите размер диска менеджера управления.
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

Восстановление работы менеджера управления из резервной копии на новый хост, ранее не находившийся в кластере. При этом исходное master-хранилище (с менеджером управления) недоступно.

Перед развертыванием необходимо:

Соблюсти условия, описанные в пунктах 2-5 инструкции.
Установить zVirt Node на хост в соответствии с разделом Установка хоста виртуализации;
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;
Необходимо учесть, что будет создан новый Центр данных, новый Кластер. Хост, на который будет произведена установка возьмёт на себя обслуживание менеджера управления. Добавить новый менеджер управления в ранее созданные Центр данных, и Кластер невозможно.

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH на новый хост. Проверьте командой dnf update, что репозиторий zVirt включен и доступен.
Выполните установку пакета ovirt-engine-appliance из репозитория:
```
dnf install -y ovirt-engine-appliance
```
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и начните процедуру развертывания:
```
hosted-engine --deploy --restore-from-file=backup.bck
```
На вопрос об имени центра данных необходимо ввести новое (ранее не использовавшееся) имя центра данных.
```
--== VM CONFIGURATION ==--
Please enter the name of the datacenter where you want to deploy this hosted-engine host. [Default]:
```
На вопрос об имени кластера необходимо ввести новое (ранее не использовавшееся) имя кластера.
```
Please enter the name of the cluster where you want to deploy this hosted-engine host. [Default]:
```

На вопрос о паузе после добавления хоста необходимо выбрать Yes.

[ INFO  ] skipping: [localhost]
        Pause the execution after adding this host to the engine?
        You will be able to connect to the restored engine in order to manually review and remediate its configuration.
        This is normally not required when restoring an up to date and coherent backup.
        Pause after adding the host? (Yes, No)[No]:  Yes

На вопрос … reinstalled from the engine to update their hosted-engine configuration необходимо выбрать Yes.

[ INFO  ] Stage: Environment setup
        During customization use CTRL-D to abort.
        Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine.
        The provided engine backup file will be restored there,
        it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored.
        If a reference to this host is already contained in the backup file, it will be filtered out at restore time.
        The locally running engine will be used to configure a new storage domain and create a VM there.
        At the end the disk of the local VM will be moved to the shared storage.
        The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it.
        Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration.
        Are you sure you want to continue? (Yes, No)[Yes]: Yes;

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

На вопрос о перевыпуске сертификат необходимо ответить Yes

[ INFO  ] skipping: [localhost]

        Renew engine CA on restore if needed?
        Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine.
        Renew CA if needed? (Yes, No)[No]: Yes;

В пункте, где необходимо указать путь к архиву с OVA файлом, оставьте рекомендуемое значение по умолчанию.
Введите пароль root для менеджера управления.
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя root, и укажите, следует ли разрешить доступ SSH для пользователя root.
Введите количество vCPU и объем ОЗУ.
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
Выберите способ получения IP-адреса: DHCP или Static. Если вы укажете Static, введите IP-адрес менеджера.
Укажите, следует ли добавлять записи для менеджера управления в /etc/hosts.
Укажите данные для отправки уведомлений по электронной почте.
Введите пароль для пользователя admin@internal.

Если на шаге Pause after adding the host? был выбран вариант ответа Yes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке.

[ INFO  ] You can now connect to https://host2.example.com: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 -> localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]

После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера.

Выберите тип используемого хранилища и укажите его данные.
Выберите размер диска менеджера управления.
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
В результате развёртывания:
- группа хостов (обозначена 1) находившаяся в кластере Default и центре данных Default, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домен хранения вышел из строя);
- группа хостов (обозначена 2) находившаяся в кластере NewCluster2 и центре данных DataCenter2, может быть доступна / недоступна в зависимости от домен хранения;
- группа хостов (обозначена 3) находившаяся во вновь созданном кластере MyCluster2022 и центре данных MyDataCenter2022, будет доступна;
В результате развёртывания, домены хранения:
- группа доменов хранения (обозначена 1) находившаяся в кластере Default и центре данных Default, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домены хранения вышли из строя). Удалить данные домены хранения нельзя, т.к. недоступен хост SPM, выполнявший роль по управлению хранилищем;
- группа доменов хранения (обозначена 2) находившаяся в кластере NewCluster2 и центре данных DataCenter2, может быть доступна / недоступна в зависимости от домен хранения;
- группа доменов хранения (обозначена 3) находившаяся во вновь созданном кластере MyCluster2022 и центре данных MyDataCenter2022, будет доступна;

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

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

Перед развертыванием необходимо:

Соблюсти условия, описанные в инструкции.
Старое хранилище должно быть доступно (в случае недоступности хранилища будет ошибка Cannot access the Storage Domain attached to the DataCenter).
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;

Далее необходимо выполнить следующие шаги:

Подключитесь на любой из хостов, ранее находившихся в кластере (в данном кластере ранее был расположен менеджер управления). Если они доступны, командой hosted-engine --vm-status проверьте, на каком из хостов запущен менеджер управления.
Подключитесь по SSH к этому хосту.
Включите режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Проверьте, что режим глобального обслуживания включен:
```
hosted-engine --vm-status
```
Подключитесь по SSH к менеджеру управления, остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```

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

[root@manager-drp ~]# engine-cleanup
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
        Configuration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf, /etc/ovirt-engine-setup.conf.d/10-packaging.conf, /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
        Log file: /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
        Version: otopi-1.9.6 (otopi-1.9.6-1.el8)
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment customization
[ INFO  ] Stage: Setup validation
        During execution engine service will be stopped (OK, Cancel) [OK]: OK

В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
        All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/filename.bak --restore-permissions
```

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

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

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

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

Запустить engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

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]: Yes

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

    If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
    Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
    A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
    Are you sure you do not want to backup the DWH database?(Yes, No) [No]: No

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

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

        Please run the following command on the engine machine manager.my.local, for SSO to work:
        systemctl restart ovirt-engine
[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20221222141208-co86sp.log
[ INFO  ] Generating answer file /var/lib/ovirt-engine/setup/answers/20221222141507-setup.conf
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of setup completed successfully

2.1.3.3. Ошибки при восстановлении

Ошибка "codec can’t decode byte 0xd0 in position 0:"

Во время восстановления может возникнуть ошибка:

ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Environment customization': 'utf-8' codec can't decode byte 0xd0 in position 0: invalid continuation byte

Решение: Был введён недопустимый символ. Из таблицы ASCII символ 0xd0 - Р (на кириллице). Необходимо вводить символы только на латинице.

Ошибка "Unable to stop service libvirtd"

Во время восстановления может возникнуть ошибка:

ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:110 fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to stop service libvirtd: Job for libvirtd.service canceled.\n"}

Решение: перед началом повторной инсталляции не была выполнена процедура очистки предыдущей установки. Необходимо выполнить команду ovirt-hosted-engine-cleanup, перезагрузить сервер и повторно запустить процедуру развёртывания.

Ошибка "Your system is configured to use a proxy, please add an exception"

Во время восстановления может возникнуть ошибка:

2022-12-01 12:17:41,122+0300 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:106
{'results': [{'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for http://name.domain.ru/ with no_proxy directive.\n',
'_ansible_no_log': False, 'changed': False, 'url': 'http://name.domain.ru/', 'ansible_loop_var': 'url', '_ansible_item_label':
'http://name.domain.ru/'}, {'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for
https://name.domain.ru/ with no_proxy directive.\n', '_ansible_no_log': False, 'changed': False, 'url': 'https://name.domain.ru/',
'ansible_loop_var': 'url', '_ansible_item_label': 'https://name.domain.ru/'}], 'msg': 'All items completed', 'changed': False}

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

export no_proxy="FQDN-engine"

где FQDN-engine - полное доменное имя менеджера управления. Например mynewmanager.test.ru

Ошибка "Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service"

Во время восстановления может возникнуть ошибка:

Failed to restart abrtd.service: Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service. Probably contradicting requirement dependencies configured.
See system logs and 'systemctl status abrtd.service' for details.

Решение: необходимо остановить и запустить сервис:

systemctl stop abrtd.service
systemctl start abrtd.service

2.1.4. Резервное копирование в режиме Stand Alone

Исходные данные

Первый центр данных. Имя - Default.
- Хост с менеджером управления: manager.example.com.
- Имя кластера - Default. В кластере два хоста: host1.example.com и host2.example.com.
- Имя домена хранения - storage_iscsi. Тип iSCSI.
- Имя домена хранения - storage_nfs. Тип NFS.
- Два гипервизора с обязательными сетями VLAN 100, 101.
Второй центр данных. Имя - DataCenter2.
- Имя кластера - Cluster2. В кластере один хост: host3.example.com.
- Имя домена хранения - storage-nfs-datacenter2. Тип NFS.
- Гипервизор с обязательной сетью VLAN 102.

Адрес менеджера управления - https://manager.example.com/ovirt-engine/

2.1.4.1. Процедура резервного копирования

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

Рекомендуемый способ резервного копирования

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine:
```
systemctl stop ovirt-engine.service
```
Создайте эталонную резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.

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

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Результат выполнения:

# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"
fn_db_delete_config_value
---------------------------
(1 row)

Создайте ещё одну резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Запустите сервис ovirt-engine:
```
systemctl start ovirt-engine.service
```

2.1.4.2. Процедура восстановления

Из резервной копии на вновь созданный (чистый хост)
Из резервной копии до предыдущего состояния

Требования для восстановления.

Для восстановления, необходимы соблюсти ряд условий:

Исходные домены хранения должны быть доступны.
Режим multipath должен быть настроен. Рекомендуемые настройки для multipath.
Произведена настройка фильтра LVM по инструкции.
Произведена настройка IP адресов, маски подсети, DNS.
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления.

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

Подключитесь по SSH к хосту с установленным zVirt
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и и выполните обновление:
```
engine-backup --mode=restore --file=backup.bck --provision-all-databases
```
Выполните команду:
```
engine-setup --offline
```

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

Would you like to backup the existing database before upgrading it? (Yes, No) No
Are you sure you do not want to backup the DWH database? (Yes, No) Yes
One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details.
Renew certificates? (Yes, No) Yes

Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
```
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
```
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

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

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```
Выполните команду очистки БД менеджера управления:
```
engine-cleanup
```
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
        All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions
```

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

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

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

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Запустить engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

        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]:

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

        If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
        Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
        A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
        Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

В случае успешного выполнения необходимо перезапустить службу ovirt-engine и подключаться к менеджеру управления:
```
systemctl restart ovirt-engine.service
```

2.1.5. Резервное копирование в режиме Stand Alone All-in-One

Исходные данные

Первый центр данных. Имя - Default.
- Хост с менеджером управления: manager.example.com
- Имя кластера - Default. В кластере два хоста: host1.example.com и host2.example.com.
- Имя домена хранения - storage_iscsi. Тип iSCSI.
- Имя домена хранения - storage_nfs. Тип NFS.
- На двух хостах добавлены обязательные сети VLAN 100, 101.
Второй центр данных. Имя - DataCenter2.
- Имя кластера - Cluster2. В кластере один хост: host3.example.com.
- Имя домена хранения - storage-nfs-datacenter2. Тип NFS.
- На хост добавлена обязательная сеть VLAN 102.

Адрес менеджера управления - https://manager.example.com/ovirt-engine/

===== Процедура резервного копирования

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

Рекомендуемый способ резервного копирования

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine:
```
systemctl stop ovirt-engine.service
```
Cоздайте эталонную резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.

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

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Корректный результат выполнения:

# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"
fn_db_delete_config_value
---------------------------
(1 row)

Создайте ещё одну резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Запустите сервис ovirt-engine:
```
systemctl start ovirt-engine.service
```

2.1.5.1. Процедура восстановления

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

Требования для восстановления.

Для восстановления, необходимы соблюсти ряд условий:

Исходные домены хранения должны быть доступны.
Режим multipath должен быть настроен. Рекомендуемые настройки для multipath.
Произведена настройка фильтра LVM по инструкции.
Произведена настройка IP адресов, маски подсети, DNS.
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления.

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

Подключитесь по SSH к хосту с установленным zVirt
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и и выполните обновление:
```
engine-backup --mode=restore --file=backup.bck --provision-all-databases
```
Выполните команду:
```
engine-setup --offline
```

Would you like to backup the existing database before upgrading it? (Yes, No) - выбрать No
Are you sure you do not want to backup the DWH database? (Yes, No) - выбрать Yes
One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details.
Renew certificates? (Yes, No) - выбрать Yes

Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
```
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
```
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

Для возвращения хоста с Менеджером управления в кластер, необходимо зайти в веб-интерфейс Менеджера управления и перейти ко вкладке Ресурсы Хосты и добавить новый хост. Предыдущий хост нужно удалить из кластера.

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

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```
Выполните команду очистки БД менеджера управления:
```
engine-cleanup
```
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
    All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
    Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions
```

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

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

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

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Запустите engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

    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]:

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

    If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
    Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
    A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
    Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

В случае успешного выполнения необходимо перезапустить службу ovirt-engine и подключаться к менеджеру управления:
```
systemctl restart ovirt-engine.service
```

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

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

2.2. Перенос базы данных и службы Data Warehouse на отдельную машину

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

zVirt поддерживает установку базы данных и службы Data Warehouse и Grafana на одной машине, хотя можно установить каждый из этих компонентов на отдельных машинах.

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

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

Данный раздел предполагает, что новая машина развёрнута на основе дистрибутива Ред ОС.

2.2.1. Перенос базы данных Data Warehouse на отдельную машину

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

Порядок действий:

Создайте резервную копию базы данных и файлов конфигурации Data Warehouse в Менеджере управления:
```
# 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_
```
Восстановите базу данных Data Warehouse на новой машине. file_name – это файл резервной копии, скопированный из Менеджера управления.
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --provision-dwh-db --restore-permissions
```

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

2.2.2. Перенос службы Data Warehouse на отдельную машину

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

Обратите внимание, что эта процедура переносит только службу Data Warehouse. Информацию о том, как перенести базу данных Data Warehouse (ovirt_engine_history) перед переносом службы Data Warehouse, см. в разделе Перенос базы данных Data Warehouse на отдельную машину.

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

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

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

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

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

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

Порядок действий:

Остановите службу Data Warehouse:
```
# systemctl stop ovirt-engine-dwhd.service
```
Если база данных размещена на удаленной машине, предоставьте доступ вручную, изменив файл postgres.conf. Измените файл /var/lib/pgsql/data/postgresql.conf и скорректируйте строку listen_addresses, чтобы она выглядела так:
listen_addresses = '*'
Если этой строки нет или она закомментирована, то добавьте ее вручную.

Если база данных размещена на машине с Менеджером управления и была настроена во время чистой установки Менеджера управления, то доступ предоставляется по умолчанию.
Перезапустите службу postgresql:
```
# systemctl restart postgresql
```

2.2.2.2. Настройка новой машины со службой Data Warehouse

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

В случае переноса базы данных ovirt_engine_history и службы Data Warehouse на одну и ту же машину выполните перечисленные ниже действия, в противном случае перейдите к следующему шагу.
# sed -i '/^ENGINE_DB_/d' \ /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf # sed -i \ -e 's;^$OVESETUP_ENGINE_CORE/enable=bool$:True;\1:False;' \ -e '/^OVESETUP_CONFIG\/fqdn/d' \ /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf # sed -i 's/localhost/<mgr-fqdn>/' \ /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
где, <mgr-fqdn> - FQDN машины с менеджером управления
Выполните команду engine-setup, чтобы начать настройку Хранилища Data Warehouse на машине:
```
# 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 (OK, Cancel) [OK]:
```

Теперь служба Data Warehouse настроена на удаленной машине. Далее отключите службу Data Warehouse на машине с Менеджером управления.

2.2.2.3. Отключение службы Хранилища Data Warehouse на машине с Менеджером управления

Порядок действий:

Перезапустите Менеджер управления на машине с Менеджером управления:
```
# service ovirt-engine restart
```

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

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

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

Отключите службу Data Warehouse:
```
# systemctl disable ovirt-engine-dwhd.service
```

Удалите файлы Хранилища Data Warehouse:

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

Порядок действий:

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

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

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

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

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

Порядок действий:

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

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

Порядок действий:

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

Перенос доменов хранения между центрами данных в одной среде

Перенос доменов хранения между центрами данных в разных средах

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

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

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

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

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

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

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

Порядок действий:

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

POST /api/vms/`_{vm:id}_`/snapshots/ HTTP/1.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, расположенного под снимком.

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

Получите данные конфигурации виртуальной машины из атрибута data соответствующего снимка:
GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2) All-Content: true Accept: application/xml Content-type: application/xml
1. Получите данные конфигурации виртуальной машины из атрибута data соответствующего снимка:

GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2)
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}_"> (2)
<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 резервного копирования и восстановления. Эта процедура предполагает, что у вас есть резервирующая виртуальная машина, на которой установлено ПО, управлявшее предыдущей резервной копией.

Порядок действий:

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

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

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>  </data> <type>ovf</type> </configuration> </initialization> ... </vm>
1. Подключите диск к новой виртуальной машине:
  
  POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id="_{disk:id}_"> </disk>
Замените {vm:id} на идентификатор новой виртуальной машины[.underline], а не виртуальной машины, снимок которой вы сделали ранее.

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

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

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

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

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

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

Особенности

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

Ограничения

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

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

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

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

Поддерживаемые конфигурации дисков для инкрементного резервного копирования

|Тип хранилища | Политика выделения дискового пространства | Статус инкрементного резервного копирования | Формат виртуального диска

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

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

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

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

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

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

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

API инкрементного резервного копирования и восстановления описан в руководстве по REST API

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

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

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

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

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

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

Порядок действий:

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

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

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

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

Порядок действий:

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

===== Включение инкрементного резервного копирования с помощью API

Вы можете использовать запрос по 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>

Дополнительные ресурсы

Раздел DiskBackup enum в руководстве REST API

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

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

Порядок действий:

Выведите список дисков, подключенных к виртуальной машине. Например, для виртуальной машины с идентификатором 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>

Дополнительные ресурсы

Атрибут backup раздела Disk struct в руководстве REST API
Раздел DiskBackup enum в руководстве REST API

===== Запуск полного резервного копирования с помощью API

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

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

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

Порядок действий:

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 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) при следующем инкрементном резервном копировании.
Дополнительные ресурсы
Метод add службы VmBackups в руководстве REST API

===== Запуск инкрементного резервного копирования с помощью API

После завершения полного резервного копирования данного виртуального диска последующие инкрементные резервные копии этого диска будут содержать только изменения, внесенные с момента последнего резервного копирования. Используйте значение идентификатора конечной контрольной точки (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) при следующем инкрементном резервном копировании.
Дополнительные ресурсы
Метод add службы VmBackups в руководстве REST API

===== Получение информации о резервной копии с помощью API

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

Метод 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>

Дополнительные ресурсы

Метод list службы VmBackups в руководстве REST API

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

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

Метод 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>

Дополнительные ресурсы

Метод list службы VmBackupDisks в руководстве REST API

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

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

Порядок действий:

Чтобы завершить резервное копирование диска с идентификатором 456 на виртуальной машине с идентификатором 123, отправьте запрос следующего вида:
```
POST /vms/123/backups/456/finalize
```
Дополнительные ресурсы
finalize POST в руководстве REST API.

===== Создание объекта 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>

Дополнительные ресурсы

Метод add для создания объекта imagetransfer в руководстве REST API.

===== Создание объекта 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>

Дополнительные ресурсы

Метод add для создания объекта imagetransfer в руководстве REST API.

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

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

Порядок действий:

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 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>

Дополнительные ресурсы

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

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

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

Порядок действий:

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 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>

Дополнительные ресурсы

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

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

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

Порядок действий:

Отправьте запрос с указанием виртуальной машины и контрольной точки. Например, укажите виртуальную машину с идентификатором 123 и контрольную точку с идентификатором 456 как показано ниже:
```
DELETE /vms/123/checkpoints/456/
```
Дополнительные ресурсы
метод remove службы VmCheckpoint в руководстве REST API.

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

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

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

Таблица 4. Методы API imageio Image, используемые при инкрементном резервном копировании и восстановлении
Запрос API (API request)	Описание
`OPTIONS /images/{ticket-id} HTTP/1.1`	Выводит параметры сервера, чтобы можно было узнать, какие функции поддерживает сервер.
`GET /images/{ticket-id}/extents`	Выводит информацию о содержимом и выделении образа диска или о блоках, которые изменились во время инкрементного резервного копирования. Эта информация называется экстент (extent).
`GET /images/{ticket-id}/extent?context=dirty`	Программа, выполняющая передачу образа, должна загрузить изменения из резервной копии. Эти изменения называются ожидающие записи экстенты (dirty extents).
`PUT /images/{ticket-id}`	Приложение резервного копирования создает новый диск или снимок существующего диска для хранения восстановленных данных.

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

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

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

Инструкции для альтернативных установок и информацию об использовании Ansible см. в Документации по Ansible.

Набор oVirt Ansible (oVirt Ansible Collection) предоставляет модули, роли и плагины для управления различными частями инфраструктуры zVirt. Модули используются для обеспечения связи между Ansible и Менеджером управления. Роли Ansible делают возможным метод модульного исполнения кода Ansible, разбивая большие плейбуки на более мелкие файлы для многократного использования, которые можно использовать совместно с другими пользователями.

Информацию по использованию Ansible для автоматизации работы zVirt смотрите в документе Введение в автоматизацию работы zVirt с помощью Ansible

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

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

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

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

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

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

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

389ds
389ds RFC-2307 Schema
Active Directory
IBM Security Directory Server
IBM Security Directory Server RFC-2307 Schema
IPA
Novell eDirectory RFC-2307 Schema
OpenLDAP RFC-2307 Schema
OpenLDAP Standard Schema
Oracle Unified Directory RFC-2307 Schema
RFC-2307 Schema (Generic)
RHDS
RHDS RFC-2307 Schema
iPlanet

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

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

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

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

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

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

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

Пример для Active Directory см. в инструкции Использование 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 выполните процедуру, описанную в инструкции Использование 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, не вводя ничего.

Введите отличительное имя (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, если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена. Продолжайте следовать инструкциям в разделе Настройка единого входа (Single Sign-On) для виртуальных машин в руководстве по управлению виртуальными машинами.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```

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

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

Please specify profile name that will be visible to users: _example.com_

Рисунок 1. Страница входа на Портал администрирования

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

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

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-20171004101225-mmneib.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

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

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

2.4.4. Подключение 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. Дополнительную информацию см. в разделе Настройка шифрованной связи между Менеджером управления и LDAP-сервером.
Если анонимный поиск не поддерживается, то в Active Directory должен быть доступен пользователь с разрешениями на просмотр всех пользователей и групп, чтобы его можно было использовать в качестве пользователя, формирующего поисковые запросы. Запишите отличительное имя (DN) пользователя, формирующего поисковые запросы. Не используйте пользователя с правами администратора для Active Directory.
Должна существовать хотя бы одна учетная запись (имя и пароль) для выполнения запросов на поиск и вход в Active Directory.
Если развернутый Active Directory охватывает несколько доменов, не забывайте об ограничении, описанном в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.

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

2.4.5. Настройка внешнего провайдера 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

Пример 1. Пример профиля: раздел 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.example.com_

# Search user and its password.
#
vars.user = uid=search,cn=users,cn=accounts,dc=_example_,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-сервера и используйте его для создания открытого файла хранилища ключей. Раскомментируйте следующие строки и укажите полный путь к открытому файлу хранилища ключей и пароль для доступа к файлу.

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

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

# 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
Пример 3. Пример конфигурационного файла аутентификации
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

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

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

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

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

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

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

Процедуру по настройке LDAP и Kerberos для единого входа (SSO) смотрите в инструкции Настройка менеджера управления для аутентификации с помощью SSO через LDAP и Kerberos на веб-портале zVirt

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

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

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

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

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

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

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

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

2.7.1. Создание пользователей

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

Порядок действий:

В боковой панели нажмите Управление (Administration) Пользователи (Users).
Нажмите Создать (Create new)

В окне Создание локального пользователя (Create Internal User) введите следующие данные:

Имя пользователя (User Name)
В выпадающем меню Роли пользователя (User Roles) выберите роль/роли пользователя
Имя (First Name)
Фамилию (Last Name)
E-mail

Пароль (Password)

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

Минимум 6 знаков.
При изменении пароля нельзя снова использовать три предыдущих пароля.
Пароль не должен содержать следующие специальные символы ! ? " ' , + < > [ ] { } | \ / ~ : ; `

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

Нажмите Сохранить (Save)

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

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

Порядок действий:

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

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

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

Порядок действий:

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

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

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

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

Порядок действий:

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

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

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

Порядок действий:

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

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

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

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

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

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

Порядок действий:

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

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

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

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

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

2.8.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

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

2.8.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 password-reset test1 --password-valid-to="2025-08-01 12:00:00-0800"
Password:
updating user test1...
user updated successfully

Минимум 6 знаков.
При изменении пароля нельзя снова использовать три предыдущих пароля.
Пароль не должен содержать следующие специальные символы ! ? " ' , + < > [ ] { } | \ / ~ : ; `

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

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

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

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

# engine-config --set UserSessionTimeOutInterval=_integer_

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

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

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

# ovirt-aaa-jdbc-tool user show test1

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

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

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

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

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

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

# ovirt-aaa-jdbc-tool user delete test1

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

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

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

Порядок действий:

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

ovirt-aaa-jdbc-tool user edit username --flag=-disabled
==== Управление группами

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

Создание группы

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

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте новую группу:
```
# ovirt-aaa-jdbc-tool group add _group1_
```
Добавьте пользователей в группу. Пользователи должны быть уже созданы.
# ovirt-aaa-jdbc-tool group-manage useradd _group1_ --user=_test1_
Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help.
Посмотреть подробные сведения об учетной записи группы:
```
# ovirt-aaa-jdbc-tool group show _group1_
```
Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.

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

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

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте первую группу:
```
# ovirt-aaa-jdbc-tool group add _group1_
```
Создайте вторую группу:
```
# ovirt-aaa-jdbc-tool group add _group1-1_
```
Добавьте вторую группу в первую группу:
```
# ovirt-aaa-jdbc-tool group-manage groupadd _group1_ --group=_group1-1_
```
Добавьте первую группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.

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

Модуль 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_"

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

Чтобы изменить настройки учетной записи по умолчанию, используйте модуль 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 test1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3. Учет квот

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

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

Пример 5. Пример учета

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

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

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

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

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

Порядок действий:

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

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

3.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).
1. В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо Ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали Ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле MiB.
2. В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).
3. Нажмите OK в окне Изменить квоту (Edit Quota).
В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).
В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).
Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Указанные домены хранения (Specific Storage Domains). Если вы выбрали Указанные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
1. В поле Квота хранилища (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле GiB.
2. Нажмите OK в окне Изменить квоту (Edit Quota).
Нажмите OK в окне Новая квота (New Quota).

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

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

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

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

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

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

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

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

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

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

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

Порядок действий:

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

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

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

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

Порядок действий:

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

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

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

Порядок действий:

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

3.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.

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

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

4.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. Выбранные события отображаются для этого пользователя на вкладке Уведомления о событиях (Event Notifier).

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

Файл конфигурации службы уведомлений о событиях находится в /usr/share/ovirt-engine/services/ovirt-engine-notifier/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-файла Менеджера управления.

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

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

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

NoAuthNoPriv (1) - Ловушки SNMP отправляются без какой-либо авторизации или конфиденциальности.
AuthNoPriv (2) - Ловушки SNMP отправляются с авторизацией по паролю, но без конфиденциальности.
AuthPriv (3) - Ловушки 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:
Примеры
Пример 6. Отправлять все события на SNMP-профиль, заданный по умолчанию
FILTER="include:*(snmp:) ${FILTER}"
Пример 7. Отправлять все события со степенью серьезности ОШИБКА (ERROR) или ОПОВЕЩЕНИЕ (ALERT) на SNMP-профиль, заданный по умолчанию
FILTER="include:*:ERROR(snmp:) ${FILTER}" FILTER="include:*:ALERT(snmp:) ${FILTER}"
Пример 8. Отправлять события для VDC_START на указанный адрес электронной почты
FILTER="include:__VDC_START__(snmp:__mail@example.com__) ${FILTER}"
Пример 9. Отправлять события для всего, кроме 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 либо в переопределяющем файле.

Пример 10. Пример файла конфигурации 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.

5. Утилиты

5.1. Инструмент переименования oVirt Engine Rename

5.1.1. Инструмент переименования oVirt Engine Rename

Когда команда 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, так как оно необходимо для корректной работы внутренних служб менеджера управления.

5.1.2. Синтаксис команды переименования oVirt Engine Rename

Базовый синтаксис команды ovirt-engine-rename:

# /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

Команда также может принимать некоторые параметры.

Таблица 9. Параметры команды `ovirt-engine-rename`**
Параметр	Описание
`--newname=[new name]`	Позволяет указать новое FQDN для Менеджера управления без взаимодействия с пользователем.
`--log=[file]`	Позволяет указать путь и имя файла, в который должны быть записаны журналы операции переименования.
`--config=[file]`	Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования.
`--config-append=[file]`	Позволяет указать путь и имя файла конфигурации для подключения к операции переименования. Этот параметр можно использовать для указания пути и имени существующего файла ответов для автоматизации операции переименования.
`--generate-answer=[file]`	Позволяет указать путь и имя файла, в который записываются ответы и значения, измененные командой `ovirt-engine-rename`.

5.1.3. Переименование Менеджера управления с помощью инструмента oVirt Engine Rename

Можно использовать команду 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 (OK, Cancel) [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.

5.2. Инструмент Engine-config

5.2.1. Инструмент Engine-config

Инструмент Engine-config – это утилита командной строки для настройки глобальных параметров среды zVirt. Инструмент взаимодействует со списком сопоставлений "ключ-значение", которые хранятся в базе данных engine, и позволяет извлекать и задавать значения отдельных ключей, а также извлекать список всех доступных ключей и значений конфигурации. Кроме того, для каждого уровня конфигурации в среде zVirt могут храниться разные значения.

Чтобы извлечь или задать значение ключа конфигурации, не нужно запускать ни Менеджер управления, ни WildFly. Поскольку сопоставления "ключ-значение" конфигурации хранятся в базе данных engine, их можно обновлять при работающей службе postgresql. Затем изменения применяются при перезапуске службы ovirt-engine.

5.2.2. Синтаксис команды engine-config

Можно запустить инструмент engine-config с машины, на которой установлен Менеджер управления. Для получения подробной информации об использовании смотрите справку для команды:

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

5.3. Инструмент Engine Vacuum

5.3.1. Инструмент Engine Vacuum

Инструмент Engine Vacuum поддерживает базы данных PostgreSQL, обновляя таблицы, удаляя неиспользуемые строки и тем самым позволяя повторно использовать дисковое пространство. Информацию о команде VACUUM и ее параметрах см. в документации на PostgreSQL.

Команда Engine Vacuum – engine-vacuum. Необходимо авторизоваться в системе как root-пользователь и ввести учетные данные администратора для среды zVirt.

Как альтернативный вариант, можно запустить инструмент 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.
See https://www.postgresql.org/docs/12/static/sql-vacuum.html
(Yes, No) [No]:

Опция Yes запускает инструмент Engine Vacuum в режиме полной очистки.

5.3.2. Режимы работы Engine Vacuum

Инструмент Engine Vacuum имеет два режима работы:

Стандартная очистка

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

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

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

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

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

5.3.3. Синтаксис команды engine-vacuum

Базовый синтаксис команды engine-vacuum:

# engine-vacuum
# engine-vacuum _option_

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

Команду engine-vacuum можно уточнить с помощью ряда параметров.

Таблица 10. Общие параметры
Параметр	Описание
`-h`, `--help`	Выводит информацию о том, как использовать команду engine-vacuum.
`-a`	Запускает стандартную очистку, анализирует базу данных и обновляет статистику оптимизатора.
`-A`	Анализирует базу данных и обновляет статистику оптимизатора, не выполняя очистку.
`-f`	Запускает полную очистку.
`-v`	Задает режим детализации консольного вывода.
`-t table_name`	Выполняет очистку конкретной таблицы или таблиц. Например: `# engine-vacuum -f -v -t vm_dynamic -t vds_dynamic`

5.4. Инструмент сопоставления VDSM с именем сети

Если имя логической сети длиннее 15 знаков или содержит знаки, отличные от ASCII, то система автоматически сгенерирует имя имя-идентификатор для использования на хосте (vdsm_name), состоящее из букв on и первых 13 знаков уникального идентификатора сети, например, ona1b2c3d4e5f6g. Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имен логических сетей и их автоматически сгенерированных имен сетей, используйте инструмент сопоставления VDSM с именами сетей, расположенный в /usr/share/ovirt-engine/bin/.

Порядок действий:

При первом запуске инструмента определите переменную среды PASSWORD, которая представляет собой пароль пользователя базы данных с доступом на чтение к базе данных Менеджера управления. Например, запустите:
```
# export PASSWORD=_DatabaseUserPassword_
```
Запустите инструмент сопоставления VDSM с именем сети:
# /usr/share/ovirt-engine/bin/vdsm_to_network_name_map --user USER
где USER – пользователь базы данных с доступом на чтение к базе данных Менеджера управления, чей пароль назначен для переменной среды PASSWORD.

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

Дополнительные параметры

Можно запустить инструмент со следующими параметрами:

--host – имя хоста/IP-адрес сервера баз данных. Значение по умолчанию – localhost.
--port – номер порта сервера баз данных. Значение по умолчанию – 5432.
--database – имя базы данных. Значение по умолчанию – engine, представляющий собой базу данных Менеджера управления.
--secure – разрешает безопасное подключение к базе данных. По умолчанию инструмент запускается без безопасного подключения.