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

Версия zVirt: 4.2

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 .

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

  1. Переведите узел с ролью hosted engine в локальный режим обслуживания:

    1. На Портале администрирования нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите узел с ролью hosted engine .

    2. Нажмите Управление (Management)  Обслуживание (Maintenance) и OK. Для этого узла автоматически инициируется локальный режим обслуживания.

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

    1. На Портале администрирования нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите узел с ролью hosted engine .

    2. Нажмите Управление (Management)  Включить (Activate).

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

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

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

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

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

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

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

  1. Переведите все узлы с ролью hosted engine в глобальный режим обслуживания:

    1. На Портале администрирования нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите любой узел с ролью hosted engine .

    2. Нажмите Дополнительные действия (More Actions) , затем нажмите Включить глобальное обслуживание высокой доступности (Enable Global HA Maintenance).

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

    1. На Портале администрирования нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите любой узел с ролью hosted engine .

    2. Нажмите Дополнительные действия (More Actions) , затем нажмите Отключить глобальное обслуживание высокой доступности (Disable Global HA Maintenance).

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

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

    # hosted-engine --set-maintenance --mode=global
  2. После выполнения всех задач обслуживания выключите режим обслуживания:

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

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

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

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

  1. На узле с ролью 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
  2. Убедитесь, что SMTP-порт по умолчанию (порт 25) настроен:

    # hosted-engine --get-shared-config email.smtp-port --type=broker
    broker : 25, type : broker
  3. Укажите адрес электронной почты, который SMTP-сервер должен использовать для отправки уведомлений. Указать можно только один адрес.

    # hosted-engine --set-shared-config email.source-email _source@example.com_ --type=broker
  4. Укажите адрес электронной почты для получения уведомлений. Можно указать несколько адресов через запятую.

    # 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 на дополнительных хостах:

  1. Нажмите Ресурсы (Compute)  Кластеры (Clusters) и выберите кластер, содержащий узлы с ролью hosted engine .

  2. Нажмите Изменить (Edit).

  3. Откройте вкладку Политика планирования (Scheduling Policy).

  4. Нажмите plus big и выберите HeSparesCount.

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

  6. Нажмите OK.

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

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

Предварительные условия:
  • Все узлы с ролью hosted engine должны находиться в одном кластере.

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

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

  2. Нажмите Новый (New).

    Информацию о дополнительных настройках хоста см. в разделе Описание настроек и средств управления в окнах "Новый хост" и "Изменить хост".

  3. В выпадающем списке выберите Центр данных (Data Center) и Хост кластера (Host Cluster) для нового хоста.

  4. Введите имя и адрес нового хоста в поля Имя (Name) и FQDN/IP. В поле порт SSH (SSH Port) автоматически подставляется порт 22 – стандартный номер SSH-порта.

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

    • Укажите пароль root-пользователя, чтобы использовать аутентификацию по паролю.

    • Либо скопируйте ключ, отображаемый в поле Публичный ключ SSH (SSH PublicKey), в /root/.ssh/authorized_keys на хосте, чтобы использовать аутентификацию по открытому ключу.

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

  7. Откройте вкладку Hosted Engine.

  8. Выберите ДА в выпадающем списке.

  9. Нажмите OK.

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

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

Настоятельно рекомендуется при установке или переустановке операционной системы хоста сначала отключить все подключенные к хосту существующие хранилища, не относящиеся к ОС, чтобы избежать случайной инициализации их дисков и потенциальной потери данных.
Порядок действий:
  1. Нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите хост.

  2. Нажмите Управление (Management)  Обслуживание (Maintenance) и OK.

  3. Нажмите НастройкиПереустановить (Reinstall).

  4. Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).

  5. Нажмите OK.

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

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

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

  1. Подключитесь к одному из узлов с ролью hosted engine :

    $ ssh root@__host_address__
  2. Переведите hosted engine в глобальный режим обслуживания:

    # hosted-engine --set-maintenance --mode=global
  3. Проверьте, имеется ли уже запущенный экземпляр виртуальной машины с Менеджером управления:

    # hosted-engine --vm-status

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

    # ssh root@__host_address__
  4. Выключите виртуальную машину:

    # hosted-engine --vm-shutdown

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

    # hosted-engine --vm-poweroff
  5. Запустите виртуальную машину с Менеджером управления в режиме паузы:

    #hosted-engine --vm-start-paused
  6. Задайте временный пароль VNC:

    #hosted-engine --add-console-password

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

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

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

    После выполнения следующей команды появится меню загрузчика. Нужно войти в режим восстановления до того, как загрузчик продолжит нормальный процесс загрузки. Прежде чем продолжить выполнение этой команды, прочтите информацию о следующем шаге входа в режим восстановления.
    # /usr/bin/virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf resume HostedEngine
  9. Загрузите виртуальную машину с Менеджером управления в режиме восстановления.

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

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

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

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

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

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

  1. На Портале администрирования нажмите Ресурсы (Compute)  Хосты (Hosts) и выберите узел с ролью hosted engine .

  2. Нажмите Управление (Management)  Обслуживание (Maintenance) и OK.

  3. Нажмите НастройкиПереустановить (Reinstall).

  4. Откройте вкладку Hosted Engine и в выпадающем списке выберите Отменить развертывание (UNDEPLOY). Это действие останавливает службы ovirt-ha-agent и ovirt-ha-broker и удаляет файл конфигурации hosted engine.

  5. Нажмите OK.

  6. При желании нажмите Удалить (Remove). Откроется окно подтверждения Удалить хост(ы) (Remove Host(s)).

  7. Нажмите OK.

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

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

2. Автоматизация задач конфигурирования с помощью 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

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

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

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

При развертывании с интегрированным Keycloak также будут созданы:

  • внутренний домен internalsso;

  • пользователь admin@zvirt - используется для доступа к порталам администрирования и keycloak, пользовательскому порталу, а также к REST API.

Инструкции, описанные в следующих разделах, применимы только при отсутствии интеграции с Keycloak. Если ваша среда использует интегрированный Keycloak, воспользуйтесь руководством по управлению.

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

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

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

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

  • ALD Pro

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

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

  • Подключить компьютер к домену

  • Изменить членство группы

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

Инструкции, описанные в этом разделе допустимо использовать только при отсутствии интеграции с keycloak.

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

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

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

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

Предварительные условия:
  • Нужно знать доменное имя DNS- или LDAP-сервера.

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

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

Порядок действий:
  1. В Менеджере управления установите пакет расширения LDAP:

    # dnf install ovirt-engine-extension-aaa-ldap-setup
  2. Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:

    # ovirt-engine-extension-aaa-ldap-setup
  3. Выберите тип 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:
  4. Нажмите 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]:
  5. Выберите метод политики 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:
  6. Выберите метод безопасного подключения, поддерживаемый 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.
  7. Введите отличительное имя (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:
  8. Введите базовое отличительное имя (DN):

    Please enter base DN (dc=example,dc=com) [dc=example,dc=com]: _ou=department-1,dc=example,dc=com_
  9. Выберите Yes, если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена. Продолжайте следовать инструкциям в разделе Настройка единого входа (Single Sign-On) для виртуальных машин в руководстве по управлению виртуальными машинами.

    Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
  10. Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано 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_
    login ad
    Рисунок 1. Страница входа на Портал администрирования
    Пользователи должны выбрать профиль из выпадающего списка при первом входе в систему. Информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.
  11. Проверьте работоспособность входа в систему, чтобы убедиться, что 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
  12. Убедитесь, что сведения о пользователе верны. Если они неверны, выберите 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]:
  13. Рекомендуется вручную проверить функцию поиска. Для поискового запроса выберите 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]:
  14. Выберите 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
  15. Перезапустите службу ovirt-engine. Созданный профиль теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы назначить учетным записям пользователей на LDAP-сервере соответствующие роли и разрешения, например, для входа на Пользовательский портал, см. раздел Администрирование пользовательских задач с Портала администрирования.

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

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

Предварительные условия:
  • Нужно знать имя леса Active Directory. Имя леса также называется именем корневого домена.

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

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

  • Если анонимный поиск не поддерживается, то в Active Directory должен быть доступен пользователь с разрешениями на просмотр всех пользователей и групп, чтобы его можно было использовать в качестве пользователя, формирующего поисковые запросы. Запишите отличительное имя (DN) пользователя, формирующего поисковые запросы. Не используйте пользователя с правами администратора для Active Directory.

  • Должна существовать хотя бы одна учетная запись (имя и пароль) для выполнения запросов на поиск и вход в Active Directory.

  • Если развернутый Active Directory охватывает несколько доменов, не забывайте об ограничении, описанном в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.

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

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

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

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

Порядок действий:
  1. В Менеджере управления установите пакет расширения LDAP:

    # dnf install ovirt-engine-extension-aaa-ldap
  2. Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для активных каталогов (ad) и других типов каталогов (simple). В этом примере используется простой шаблон конфигурации.

    # cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. /etc/ovirt-engine
  3. Переименуйте файлы конфигурации, чтобы они соотносились с именем профиля, который нужно сделать видимым для пользователей на страницах входа на Портал администрирования и Пользовательский портал:

    # 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
  4. Измените файл конфигурации свойств 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_
  5. Просмотрите конфигурационный файл аутентификации. Имя профиля, видимое для пользователей на страницах входа на Портал администрирования и Пользовательский портал, определяется посредством 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
  6. Просмотрите конфигурационный файл авторизации. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации 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
  7. Убедитесь, что для профиля конфигурации заданы соответствующие владелец и разрешения:

    # chown ovirt:ovirt /etc/ovirt-engine/aaa/_example_.properties
    # chmod 600 /etc/ovirt-engine/aaa/_example_.properties
  8. Перезапустите службу engine:

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

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

3.3.4. Удаление внешнего провайдера LDAP

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

Порядок действий:
  1. Удалите файлы конфигурации провайдера 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
  2. Перезапустите службу ovirt-engine:

    # systemctl restart ovirt-engine
  3. На Портале администрирования перейдите в Управление (Administration)  Пользователи (Users) выберите пользователей этого провайдера (тех, чьим Провайдером авторизации (Authorization provider) является profile1-authz) и нажмите Удалить (Remove).

3.4. Настройка 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

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

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

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

  • Пользователь, выполняющий действие;

  • Тип выполняемого действия;

  • Объект, над которым выполняется действие.

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

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

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

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

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

Инструкцию, описанную в этом разделе допустимо использовать только при отсутствии интеграции с keycloak.

Для zVirt версии 4.2 настоятельно рекомендуется использовать Keycloak. Подробнее см. в разделе Управление пользователями руководства по управлению Keycloak.

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

Порядок действий:
  1. В боковой панели нажмите Управление (Administration)  Пользователи (Users).

  2. Нажмите Создать (Create new)

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

    • Имя пользователя (User Name)

    • В выпадающем меню Роли пользователя (User Roles) выберите роль/роли пользователя

    • Имя (First Name)

    • Фамилию (Last Name)

    • E-mail

    • Пароль (Password)

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

      • Минимум 6 знаков.

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

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

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

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

3.6.2. Смена истекшего пароля пользователя.

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

password expired

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

  1. Нажмите ссылку Изменить пароль в уведомлении.

  2. В открывшейся странице в форме введите старый и новый пароли.

    password change
  3. Нажмите Сменить пароль.

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

password changed

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

  1. Подключитесь по SSH к менеджеру управления.

  2. Для разблокировки пользователя используйте утилиту ovirt-aaa-jdbc-tool:

    ovirt-aaa-jdbc-tool user unlock <username>

    <username> - имя пользователя, которого необходимо разблокировать.

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

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

Порядок действий:
  1. В боковой панели нажмите Управление (Administration)  Настройка (Configure). Откроется окно Настройка (Configure).

  2. Нажмите Системные разрешения (System Permissions).

  3. Нажмите Добавить (Add). Откроется окно Добавить системное разрешение (Add System Permission to User).

  4. Выберите профиль в разделе Поиск (Search). Профиль – это домен, в котором вы хотите искать. Введите имя или часть имени в текстовое поле и нажмите Поиск (GO). Либо нажмите Поиск (GO), чтобы просмотреть список всех пользователей и групп.

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

  6. Выберите соответствующую роль для назначения в разделе Роль для связи (Role to Assign). Роль UserRole предоставляет учетной записи пользователя разрешение авторизоваться на Пользовательском портале.

  7. Нажмите OK.

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

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

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

  2. Нажмите имя пользователя. Откроется подробное представление, при этом на вкладке Общее (General) обычно отображается общая информация, такая как имя домена, адрес электронной почты и статус пользователя.

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

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

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

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

Порядок действий:
  1. Найдите и нажмите на имя ресурса. Откроется подробное представление.

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

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

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

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

  2. Выберите пользователя для удаления. Убедитесь в том, что у него не запущена какая-либо виртуальная машина.

  3. Нажмите Удалить (Remove), затем нажмите OK.

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

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

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

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Активные сессии пользователя (Active User Sessions).

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

  3. Нажмите Завершить сессию (Terminate Session).

  4. Нажмите OK.

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

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

Порядок действий:
  1. В боковой панели нажмите Управление (Administration)  Пользователи (Users).

  2. Нажмите Настройки.

    user settings
  3. Задайте параметры:

    • Уведомление о попытках входа - выберите:

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

        login
      • Нет - при входе пользователя в систему уведомление не будет отображаться.

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

      notification
  4. Нажмите Сохранить.

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

Инструкцию, описанную в этом разделе допустимо использовать только при отсутствии интеграции с keycloak.

Для zVirt версии 4.2 настоятельно рекомендуется использовать Keycloak. Подробнее см. в руководстве по управлению Keycloak.

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

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

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

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

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

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

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

3.7.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-aaa-jdbc-tool settings show.

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

  1. На Портале администрирования нажмите Управление (Administration)  Провайдеры (Providers).

  2. Выберите ovirt-provider-ovn.

  3. Нажмите Изменить (Edit) и введите новый пароль в поле Пароль (Password).

  4. Нажмите Тестировать (Test), чтобы проверить, проходит ли успешно аутентификация с предоставленными учетными данными.

  5. После успешной проверки аутентификации нажмите ОК.

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

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

# engine-config --set UserSessionTimeOutInterval=_integer_

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

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

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

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

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

    # /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__
  2. Установите новый пароль с помощью скрипта ovirt-aaa-jdbc-tool, используя параметр --encrypted:

    # ovirt-aaa-jdbc-tool user password-reset __test1__ --password-valid-to="2025-08-01 12:00:00-0800" --encrypted
  3. Введите и подтвердите зашифрованный пароль:

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

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

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

# ovirt-aaa-jdbc-tool user show test1

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

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

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

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

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

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

# ovirt-aaa-jdbc-tool user delete test1

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

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

  2. Убедитесь, что в среду добавлен другой пользователь с ролью SuperUser. Более подробные сведения см. в разделaх Создание пользователей и Назначение разрешений Пользовательского портала.

  3. Отключите пользователя 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. Типичные примеры представлены в настоящем разделе.

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

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

    # ovirt-aaa-jdbc-tool group add _group1_
  3. Добавьте пользователей в группу. Пользователи должны быть уже созданы.

    # ovirt-aaa-jdbc-tool group-manage useradd _group1_ --user=_test1_
    Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help.
  4. Посмотреть подробные сведения об учетной записи группы:

    # ovirt-aaa-jdbc-tool group show _group1_
  5. Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

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

    # ovirt-aaa-jdbc-tool group add _group1_
  3. Создайте вторую группу:

    # ovirt-aaa-jdbc-tool group add _group1-1_
  4. Добавьте вторую группу в первую группу:

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

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

Модуль query позволяет запрашивать информацию о пользователях и группах. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool query --help.

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

  2. Выведите список с информацией обо всех учетных записях.

    • Данные по всем учетным записям пользователей:

      # ovirt-aaa-jdbc-tool query --what=user
    • Данные по всем учетным записям групп:

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

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

  2. Отфильтруйте данные учетной записи с помощью параметра --pattern.

    • Выведите список данных учетных записей пользователей с именами, начинающимися со знака j.

      # ovirt-aaa-jdbc-tool query --what=user --pattern="name=_j*_"
    • Выведите список групп, у которых указан атрибут департамента marketing:

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

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

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

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

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

Порядок действий:
  1. Авторизуйтесь на той машине, на которой установлен Менеджер управления.

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

    # ovirt-aaa-jdbc-tool settings show
  3. Измените необходимые настройки:

    • В этом примере заданная по умолчанию длительность сеанса после авторизации изменена на 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.

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

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

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

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

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

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

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

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

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

Таблица 1. Виды квот
Тип квоты Определение

Квота на ресурсы среды выполнения (Run-time Quota)

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

Квота хранения (Storage Quota)

Эта квота ограничивает объем доступного хранилища.

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

Таблица 2. Режимы квот
Режим квотирования Описание

Принудительный (Enforced)

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

Аудит (Audit)

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

Выключенный (Disabled)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3. Учет квот

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

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

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

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

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

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

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

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

Порядок действий:
  1. Нажмите Ресурсы (Compute)  Центры данных (Data Centers) и выберите центр данных.

  2. Нажмите Изменить (Edit).

  3. В выпадающем списке Режим квотирования (Quota Mode) измените режим квотирования на Принудительный (Enforced).

  4. Нажмите OK.

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

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Квота (Quota).

  2. Нажмите Новая (Add).

  3. Заполните поля Имя (Name) и Описание (Description).

  4. Выберите Центр данных (Data Center).

  5. В разделе Память и ЦП (Memory & CPU) используйте зеленый бегунок, чтобы задать Пороговое значение для кластера (Cluster Threshold).

  6. В разделе Память и ЦП (Memory & CPU) используйте синий бегунок, чтобы задать Допустимое превышение для кластера (Cluster Grace).

  7. Кнопкой-переключателем выберите Все кластеры (All Clusters) или Указанные кластера (Specific Clusters). Если вы выбрали Указанные кластера (Specific Clusters), то отметьте флажками кластеры, которые хотите добавить в политику квотирования.

  8. Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).

    1. В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо Ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали Ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле MiB.

    2. В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).

    3. Нажмите OK в окне Изменить квоту (Edit Quota).

  9. В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).

  10. В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).

  11. Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Указанные домены хранения (Specific Storage Domains). Если вы выбрали Указанные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.

  12. Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).

    1. В поле Квота хранилища (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле GiB.

    2. Нажмите OK в окне Изменить квоту (Edit Quota).

  13. Нажмите OK в окне Новая квота (New Quota).

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

Таблица 3. Пороговые значения квот и допустимые превышения
Параметр Определение

Пороговое значение для кластера

Объем ресурсов кластера, доступных каждому центру данных.

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

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

Пороговое значение для хранилища

Объем ресурсов хранилища, доступных каждому центру данных.

Допустимое превышение для хранилища

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

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

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

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

  1. Нажмите Ресурсы (Compute)  Виртуальные машины (Virtual Machines) и выберите виртуальную машину.

  2. Нажмите Изменить (Edit).

  3. Перейдите на вкладку Выделение ресурсов (Resource Allocation).

  4. Из выпадающего списка Квота (Quota) выберите квоту, которую виртуальная машина будет потреблять.

  5. Нажмите OK.

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

  1. Нажмите Ресурсы (Compute)  Виртуальные машины (Virtual Machines).

  2. Нажмите на имя виртуальной машины. Откроется подробное представление.

  3. Откройте вкладку Диски (Disks) и выберите диск, который собираетесь ассоциировать с квотой.

  4. Нажмите Изменить (Edit).

  5. Из выпадающего списка Квота (Quota) выберите квоту, которую диск будет потреблять.

  6. Нажмите OK.

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

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Квота (Quota).

  2. Нажмите на имя целевой квоты. Откроется подробное представление.

  3. Откройте вкладку Потребители (Consumers).

  4. Нажмите Добавить (Add).

  5. В поле Поиск (Search) введите имя пользователя, которого хотите ассоциировать с квотой.

  6. Нажмите Поиск (GO).

  7. Поставьте флажок рядом с именем пользователя.

  8. Нажмите OK.

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

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Квота (Quota) и выберите квоту.

  2. Нажмите Изменить (Edit).

  3. Измените поля согласно потребностям.

  4. Нажмите OK.

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Квота (Quota) и выберите квоту.

  2. Нажмите Удалить (Remove).

  3. Нажмите OK.

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

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

Порядок действий:
  1. Нажмите Ресурсы (Compute)  Виртуальные машины (Virtual Machines).

  2. Нажмите Создать (New) или выберите виртуальную машину и нажмите Изменить (Edit).

  3. Откройте вкладку Выделение ресурсов (Resource Allocation).

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

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

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

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

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

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

  2. Нажмите Управление (Administration)  Пользователи (Users) и выберите пользователя.

  3. Нажмите на Имя пользователя (User Name), чтобы открыть подробное представление.

  4. На вкладке Уведомления о событиях (Event Notifier) нажмите Управление событиями (Manage Events).

  5. Нажмите на кнопку Развернуть все (Expand All) или специальные кнопки расширения cont arrow, чтобы просмотреть события.

  6. Поставьте необходимые флажки.

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

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

  9. На машине с Менеджером управления скопируйте 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
  10. Измените 90-email-notify.conf и удалите всё, кроме раздела EMAIL Notifications.

  11. Введите корректные переменные электронной почты, как в примере ниже. Этот файл переопределяет значения в оригинальном файле 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.
  12. Включите и перезапустите сервис ovirt-engine-notifier, чтобы внесенные изменения вступили в силу:

    # systemctl daemon-reload
    # systemctl enable ovirt-engine-notifier.service
    # systemctl restart ovirt-engine-notifier.service

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

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

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

Порядок действий:
  1. Нажмите Управление (Administration)  Пользователи (Users).

  2. Нажмите на Имя пользователя (User Name). Откроется подробное представление.

  3. Откройте вкладку Уведомления о событиях (Event Notifier), чтобы увидеть список событий, о которых пользователь получает уведомления по электронной почте.

  4. Нажмите Управление событиями (Manage Events).

  5. Нажмите кнопку Развернуть все (Expand All) или специальные кнопки расширения cont arrow, чтобы просмотреть события.

  6. Снимите необходимые флажки, чтобы удалить уведомления для этого события.

  7. Нажмите OK.

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

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

Файл содержит следующие переменные:

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

    Значение по умолчанию: Нет

  • JBOSS_HOME - местонахождение сервера приложений, используемого Менеджером управления. Значение по умолчанию: /usr/share/ovirt-engine-wildfly

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

    Значение по умолчанию: /etc/ovirt-engine

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

    Значение по умолчанию: /var/log/ovirt-engine

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

    Значение по умолчанию: /usr/share/ovirt-engine

  • NOTIFIER_MALLOC_ARENA_MAX - количество пулов памяти, которые могут быть созданы glibc и позже использованы malloc.

    Значение по умолчанию:1

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

    Значение по умолчанию:`${ENGINE_USR}/modules/tools:${ENGINE_USR}/modules/common`

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

    Значение по умолчанию: Нет

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

    Значение по умолчанию: 30

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

    Значение по умолчанию: 1

  • LOG_LEVEL - уровень журналирования.

    Допустимые значения:

    • FINE

    • INFO

    • WARNING

    • SEVERE

    Значение по умолчанию: INFO

Конфигурация сервиса уведомлений (Notification Service Configuration)
  • INTERVAL_IN_SECONDS - интервал (в секундах) между ситуациями отправки сообщений подписчикам.

    Значение по умолчанию: 120

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

    Значение по умолчанию: 30

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

    Значение по умолчанию: 7

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

    Значение по умолчанию: 30

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

    Значение по умолчанию: Нет

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

    Значение по умолчанию: 0

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

    Значения по умолчанию:

    • Фильтры отправки событий жизненного цикла engine через AMQP:

      FILTER="include:VDC_START(amqp:VirtualInfrastructureVdcIntegrity) ${FILTER}"
      FILTER="include:VDC_STOP(amqp:VirtualInfrastructureVdcIntegrity) ${FILTER}"
    • Фильтры отправки событий жизненного цикла хостов через AMQP:

      FILTER="include:VDS_RECOVER(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:VDS_FAILURE(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:VDS_MAINTENANCE(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:USER_VDS_RESTART(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:USER_VDS_START(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:USER_VDS_STOP(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:SYSTEM_VDS_RESTART(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
      FILTER="include:SYSTEM_SSH_HOST_RESTART(amqp:VirtualInfrastructureVdsIntegrity) ${FILTER}"
    • Фильтры отправки событий жизненного цикла виртуальных машин через AMQP:

      FILTER="include:USER_STARTED_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_REBOOT_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_STOP_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_PAUSE_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_REBOOT_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_SUSPEND_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_RESUME_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_INITIATED_SHUTDOWN_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_INITIATED_RUN_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_RESUME_VM(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_INITIATED_RUN_VM_AND_PAUSE(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:USER_STOPPED_VM_INSTEAD_OF_SHUTDOWN(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:VM_DOWN(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
      FILTER="include:VM_FAILURE(amqp:VirtualInfrastructureVmIntegrity) ${FILTER}"
Конфигурация AMQP-транспорта
  • AMQP_ENABLE - использование AMPQ в качестве транспортного протокола при рассылке внутренних событий. Значение по умолчанию: true

  • AMQP_URI - URI для подключюения к брокеру RabbitMQ. Значение по умолчанию: amqp://admin:admin@127.0.0.1:5672/

  • AMQP_RETRIES_LIMIT - количество повторных попыток отправки сообщения. Значение по умолчанию: 2

  • AMQP_INTEGRITY_CONTROL_VDC_HOST_ID - идентификатор хоста для сообщений контроля целостности самого engine. Значение по умолчанию: VDC_HOST

  • AMQP_INTEGRITY_CONTROL_EXCHANGE_NAME - наименование RabbitMQ exchange для отправки сообщений контроля целостности. Значение по умолчанию: integrity_daemon_ex

Конфигурация email уведомлений (EMAIL Notifications)
  • MAIL_SERVER - адрес почтового сервера SMTP. Обязательный параметр.

    Значение по умолчанию: Нет

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

    Значение по умолчанию: 25

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

    Значение по умолчанию: Нет

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

    Значение по умолчанию: ${SENSITIVE_KEYS},MAIL_PASSWORD

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

    Значение по умолчанию: Нет

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

    Значение по умолчанию: none

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

    Значение по умолчанию: false

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

    Значение по умолчанию: Нет

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

    Значение по умолчанию: Нет

  • MAIL_SEND_INTERVAL - число SMTP-сообщений, которые должны отправляться в каждый IDLE_INTERVAL.

    Значение по умолчанию: 1

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

    Значение по умолчанию: 4

  • MAIL_MERGE_LOG_TYPES - список типов событий, разделённых запятыми, которые необходимо объединять в одном сообщении.

    Значение по умолчанию: Нет

  • MAIL_MERGE_MAX_TIME_DIFFERENCE - максимально допустимая разница во времени регистрации (в миллисекундах) для двух объединяемых событий. Если разница во времени регистрации двух событий превышает указанное в параметре, события не будут объединены.

    Значение по умолчанию: 5000

  • MAIL_LOCALE - код языка, на который нужно переводить уведомления. На данный момент поддерживается только два значения en (английский) и ru (русский). По умолчанию код не указан, что соответствует en.

    Значение по умолчанию: Нет

Конфигурация уведомлений с помощью ловушек snmp (SNMP_TRAP Notifications)
  • SNMP_MANAGERS - IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, manager1.example.com manager2.example.com:164

    Значение по умолчанию: Нет

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

    Значение по умолчанию: public

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

    Значение по умолчанию: 1.3.6.1.4.1.2312.13.1.1

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

    Значение по умолчанию: 2

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

    Значение по умолчанию: Нет

  • SNMP_USERNAME - имя пользователя, используемое для ловушек SNMPv3.

    Значение по умолчанию: Нет

  • SNMP_AUTH_PROTOCOL - протокол авторизации SNMPv3. Возможные значения: MD5, SHA

    Значение по умолчанию: Нет

  • SNMP_AUTH_PASSPHRASE - парольная фраза, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH_NOPRIV и AUTH_PRIV (только SNMP версии 3).

    Значение по умолчанию: Нет

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

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

    Значение по умолчанию: Нет

  • SNMP_PRIVACY_PASSPHRASE - парольная фраза обеспечения конфиденциальности SNMPv3, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH_PRIV.

    Значение по умолчанию: Нет

  • SNMP_SECURITY_LEVEL - уровень безопасности SNMPv3.

    Возможные значения:

    • 1 - NOAUTH_NOPRIV

    • 2 - AUTH_NOPRIV

    • 3 - AUTH_PRIV

    Значение по умолчанию: 1

Конфигурация мониторинга Менеджера (Engine Monitoring Configuration)
  • ENGINE_INTERVAL_IN_SECONDS - интервал (в секундах) между операциями мониторинга машины, на которой установлен Менеджер управления. Этот интервал измеряется с момента завершения мониторинга.

    Значение по умолчанию: 300

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

    Значение по умолчанию: 3

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

    Значение по умолчанию: 30

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

    Значение по умолчанию: false

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

    Значение по умолчанию: TLS

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

    Значение по умолчанию: false

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

    Значение по умолчанию: false

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

    Значение по умолчанию: false

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

    Значение по умолчанию: /var/lib/ovirt-engine/ovirt-engine.pid

  • SENSITIVE_KEYS - пароли для подключения к внешним сервисам.

    Значения по умолчанию:

    • Пароль для хранилища доверенных сертификатов, содержащего сертификат внешнего сервера OIDC.

      "${SENSITIVE_KEYS},EXTERNAL_OIDC_HTTPS_PKI_TRUST_STORE_PASSWORD"
    • Пароль клиента, который будет использоваться для внешнего сервера OIDC.

      "${SENSITIVE_KEYS},EXTERNAL_OIDC_CLIENT_SECRET"
    • Детали подключения к базе данных Keycloak

      "${SENSITIVE_KEYS},KEYCLOAK_DB_PASSWORD"

5.4. Настройка Менеджера управления на отправку ловушек 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\> – это число, указывающее приоритет, с которым должен выполняться этот файл.

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

    # vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf
    Скопируйте настройки SNMP по умолчанию из файла конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. В этом файле есть комментарии по всем настройкам.
  2. Укажите менеджера(ов) 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
  3. Укажите, какую версию SNMP следует использовать: 2 (по умолчанию) или 3:

    SNMP_VERSION=3
  4. Укажите значение для SNMP_ENGINE_ID. Например:

    SNMP_ENGINE_ID="80:00:00:00:01:02:05:05"
  5. В случае 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
  6. Определите, какие события следует отправлять менеджеру 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.

  7. Сохраните файл.

  8. Запустите службу 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.

6. Утилиты

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

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

Хотя команда ovirt-engine-rename создает новый сертификат для веб-сервера, на котором выполняется Менеджер управления, она не влияет на сертификат для Менеджера управления или центр сертификации. В связи с этим существует определенный риск при использовании команды ovirt-engine-rename. Поэтому всегда, когда возможно, рекомендуется изменять FQDN Менеджера управления путем запуска engine-cleanup и engine-setup.
Во время процесса обновления старое имя хоста должно быть разрешимо. Если работа инструмента переименования oVirt Engine завершается с ошибкой и выдачей сообщения [ ERROR ] Host name is not valid: <OLD FQDN> did not resolve into an IP address, то добавьте старое имя хоста в файл /etc/hosts, используйте инструмент переименования oVirt Engine и затем удалите старое имя хоста из файла /etc/hosts.

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

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

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

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

Таблица 4. Параметры команды ovirt-engine-rename**
Параметр Описание

--newname=[new name]

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

--log=[file]

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

--config=[file]

Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования.

--config-append=[file]

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

--generate-answer=[file]

Позволяет указать путь и имя файла, в который записываются ответы и значения, измененные командой ovirt-engine-rename.

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

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

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

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

  2. Если используется DHCP, обновите конфигурацию DHCP-сервера.

  3. Обновите имя хоста в Менеджере управления.

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

    # /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename
  5. При появлении запроса нажмите Ввод (Enter), чтобы остановить службу engine:

    During execution engine service will be stopped (OK, Cancel) [OK]:
  6. При появлении запроса введите новое FQDN для Менеджера управления:

    New fully qualified server name:__new_engine_fqdn__

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

Для hosted engine выполните следующие дополнительные шаги:

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

  2. Выполните следующую команду на одном из узлов с ролью hosted engine :

    # hosted-engine --set-shared-config fqdn __new_engine_fqdn__ --type=he_shared

    Эта команда изменяет FQDN в мастер-копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf в общем домене хранения.

Теперь все новые и существующие узлы с ролью hosted engine используют новое FQDN.

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

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

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

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

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

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

6.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 в режиме полной очистки.

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

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

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

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

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

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

  • Полная очистка

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

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

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

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

# engine-vacuum
# engine-vacuum _option_

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

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

Таблица 5. Общие параметры
Параметр Описание

-h, --help

Выводит информацию о том, как использовать команду engine-vacuum.

-a

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

-A

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

-f

Запускает полную очистку.

-v

Задает режим детализации консольного вывода.

-t table_name

Выполняет очистку конкретной таблицы или таблиц. Например:

# engine-vacuum -f -v -t vm_dynamic -t vds_dynamic

6.4. Инструмент Log Collector

6.4.1. Инструмент Log Collector

Перед началом работы с Log Collector необходимо на машину с Менеджером управления установить пакет ovirt-log-collector

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

Команда сбора журналов: ovirt-log-collector. Необходимо авторизоваться в системе Менеджера управления как root-пользователь и ввести учетные данные администратора для среды zVirt. Команда ovirt-log-collector -h отображает информацию об использовании, включая список всех действительных опций для команды ovirt-log-collector.

6.4.2. Синтаксис команды ovirt-log-collector

Базовый синтаксис команды сбора журналов:

# ovirt-log-collector _options_  list _all|clusters|datacenters_
# ovirt-log-collector _options_ collect

Поддерживаются два режима работы: вывести список (list) и собрать (collect).

  • Параметр вывести список (list) выводит список хостов, кластеров или центров данных, подключенных к Менеджеру управления. Вы можете фильтровать сбор журналов по перечисленным объектам.

  • Параметр собрать (collect) выполняет сбор журналов из Менеджера управления. Собранные журналы помещаются в архивный файл в каталоге /tmp/logcollector. Команда ovirt-log-collector присваивает каждому журналу свое имя файла.

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

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

Таблица 6. Общие параметры
Параметр Описание

--version

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

-h, --help

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

--conf-file=PATH

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

--local-tmp=PATH

Задает PATH в качестве каталога для сохранения журналов. Каталог по умолчанию – /tmp/logcollector.

--ticket-number=TICKET

Задает TICKET в качестве зарегистрированной заявки (или номера инцидента), которую нужно ассоциировать с SOS-отчетом.

--upload=FTP_SERVER

Задает FTP_SERVER в качестве приемника для извлеченных журналов, отправляемых по FTP.

Не используйте эту опцию, если это не рекомендовано представителем службы поддержки zVirt.

--log-file=PATH

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

--quiet

Задает тихий режим, сводя консольный вывод к минимуму. По умолчанию тихий режим выключен.

-v, --verbose

Задает режим детализации консольного вывода. По умолчанию режим детализации выключен.

--time-only

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

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

В соответствии с этими параметрами выполняется фильтрация при сборе журналов и указывается подробная информация об аутентификации для Менеджера управления.

Эти параметры можно комбинировать для получения определенных команд. Например, ovirt-log-collector --user=admin@internal --cluster ClusterA,ClusterB --hosts "SalesHost" указывает *admin@internal в качестве пользователя и ограничивает сбор журналов только хостами SalesHost в кластерах A и B.

Параметр Описание

--no-hypervisors

Исключает хосты виртуализации из сбора журналов.

--one-hypervisor-per-cluster

Собирает журналы одного хоста (SPM, если он есть) из каждого кластера.

-u USER, --user=USER

Задает имя пользователя для авторизации. USER указывается в формате user@domain, где user – имя пользователя, а domain – используемый домен служб каталогов. Пользователь должен существовать в службах каталогов и быть известен Менеджеру управления.

-r FQDN, --engine=FQDN

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

-c CLUSTER, --cluster=CLUSTER

Собирает журналы с хостов виртуализации в указанном кластере (CLUSTER) в дополнение к журналам из Менеджера управления. Охватываемые кластер(ы) следует указать в списке имен кластеров или паттернов сопоставления (match patterns) через запятую.

-d DATACENTER, --data-center=DATACENTER

Собирает журналы с хостов виртуализации в указанном центре данных (DATACENTER) в дополнение к журналам из Менеджера управления. Охватываемые центр(ы) данных следует указать в списке имен кластеров или паттернов сопоставления (match patterns) через запятую.

-H HOSTS_LIST, --hosts=HOSTS_LIST

Собирает журналы с хостов виртуализации в указанном списке хостов (HOSTS_LIST) в дополнение к журналам из Менеджера управления. Охватываемые хосты следует указать в списке имен хостов, FQDN или IP-адресов через запятую. Паттерны сопоставления (match patterns) тоже подходят.

Конфигурация SSH

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

Параметр Описание

--ssh-port=PORT

Задает PORT в качестве порта, который следует использовать для SSH-подключений к хостам виртуализации.

-k KEYFILE, --key-file=KEYFILE

Задает KEYFILE в качестве открытого SSH-ключа, который следует использовать для доступа к хостам виртуализации.

--max-connections=MAX_CONNECTIONS

Задает MAX_CONNECTIONS в качестве максимального количества параллельных SSH-подключений для журналов от хостов виртуализации. Значение по умолчанию = 10.

Параметры базы данных PostgreSQL

Имя пользователя базы данных и имя базы данных должны быть указаны с использованием параметров pg-user и dbname, если они были изменены относительно значений по умолчанию.

Если база данных находится не на локальном хосте, то используйте параметр pg-dbhost. Для сбора удаленных журналов используйте необязательный параметр pg-host-key. Чтобы удаленный сбор журналов был успешным, на сервере баз данных должен быть установлен SOS-плагин PostgreSQL.

Параметр Описание

--no-postgresql

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

--pg-user=USER

Задает USER в качестве имени пользователя, которое следует использовать для подключения к серверу баз данных. Значение по умолчанию = postgres.

--pg-dbname=DBNAME

Задает DBNAME в качестве имени базы данных, которое следует использовать для подключения к серверу баз данных. Значение по умолчанию = engine.

--pg-dbhost=DBHOST

Задает DBHOST в качестве имени хоста для сервера баз данных. Значение по умолчанию = localhost.

--pg-host-key=KEYFILE

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

6.4.3. Основные сведения об использовании сборщика журналов (Log Collector)

Когда команда ovirt-log-collector выполняется без указания дополнительных параметров, по умолчанию она собирает все журналы из Менеджера управления и подключенных к нему хостов. Она также собирает журналы баз данных, если только не добавлен параметр --no-postgresql. В следующем примере сборщик журналов запускается для сбора всех журналов из Менеджера управления и трех подключенных хостов.

Пример 11. Использование сборщика журналов
# ovirt-log-collector
INFO: Gathering oVirt Engine information...
INFO: Gathering PostgreSQL the oVirt Engine database and log files from localhost...
Please provide REST API password for the admin@internal oVirt Engine user (CTRL+D to abort):
About to collect information from 3 hypervisors. Continue? (Y/n):
INFO: Gathering information from selected hypervisors...
INFO: collecting information from 192.168.122.250
INFO: collecting information from 192.168.122.251
INFO: collecting information from 192.168.122.252
INFO: finished collecting information from 192.168.122.250
INFO: finished collecting information from 192.168.122.251
INFO: finished collecting information from 192.168.122.252
Creating compressed archive...
INFO Log files have been collected and placed in /tmp/logcollector/sosreport-rhn-account-20110804121320-ce2a.tar.xz.
The MD5 for this file is 6d741b78925998caff29020df2b2ce2a and its size is 26.7M