Руководство администратора

Версия zVirt: 3.2

Аннотация

В этом документе содержится информация и процедуры для администраторов zVirt 3.0 и выше.

1. Администрирование и обслуживание системы управления виртуализацией zVirt

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

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

1.1. Глобальная конфигурация

Чтобы получить доступ к глобальной конфигурации откройте Управление (Administration) Настройка (Configure). В окне Настройка (Configure) можно настроить ряд глобальных ресурсов для системы управления виртуализацией zVirt , например, роли, системные разрешения, политики планирования, типы экземпляров и пулы MAC-адресов. В этом окне можно настроить способ взаимодействия пользователей с ресурсами в системе, а также окно служит центром для настройки параметров, применимых к нескольким кластерам.

1.1.1. Роли

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

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

1.1.1.1. Создание новой роли

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

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

Нажмите Управление (Administration) Настройка (Configure). Откроется окно Настройка (Configure) . Вкладка Роли (Roles) выбрана по умолчанию и отображает список имеющихся по умолчанию ролей Пользователя и Администратора, а также любых дополнительно созданных ролей.
Нажмите Новая (New).
Введите имя и описание новой роли в поля Имя (Name) и Описание (Description).
Выберите Администратор (Admin) или Пользователь (User) в качестве Типа учетной записи (Account Type).
Нажимайте кнопки Развернуть все (Expand All) или Свернуть все (Collapse All), чтобы показать больше или меньше разрешений для объектов в списке Выберите опции для разрешенных действий (Check Boxes to Allow Action). Вы также можете развернуть или свернуть список опций каждого объекта.
Для каждого объекта выберите или удалите действия, которые хотите разрешить или запретить для настраиваемой роли.
Нажмите OK, чтобы закрыть окно, сохранить изменения и новая роль появилась в списке ролей или нажмите Закрыть (Cancel), чтобы закрыть окно без создания новой роли.

1.1.1.2. Изменение или копирование роли

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

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

Нажмите Управление (Administration) Настройка (Configure). Откроется окно Настройка (Configure) , в котором отображается список ролей Пользователя и Администратора по умолчанию, а также любых дополнительно созданных ролей.
Выберите роль, которую хотите изменить.
Нажмите Изменить (Edit) или Копировать (Copy). Откроется окно Изменить роль (Edit Role) или Копировать роль (Copy Role).
При необходимости измените имя и описание роли в полях Имя (Name) и Описание (Description).
Нажимайте кнопки Развернуть все (Expand All) или Свернуть все (Collapse All), чтобы показать больше или меньше разрешений для объектов в списке. Вы также можете развернуть или свернуть список опций каждого объекта.
Для каждого из объектов выберите или удалите действия, которые хотите разрешить или запретить для изменяемой роли.
Нажмите OK, чтобы закрыть окно и сохранить внесенные изменения или Закрыть (Close), чтобы закрыть окно без сохранения внесённых данных.

1.1.1.3. Примеры ролей пользователей и авторизации

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

Пример 1. Разрешения в кластере

Варвара работает системным администратором в бухгалтерии. Все виртуальные ресурсы ее отдела организованы в кластере (cluster) zVirt под названием Otdel-3. Ей назначена роль администратора кластера (ClusterAdmin) в кластере бухгалтерии Otdel-3. С такой ролью она может управлять всеми виртуальными машинами в кластере, т.к. виртуальные машины – это дочерние объекты кластера. Управление виртуальными машинами включает изменение, добавление или удаление виртуальных ресурсов, например, дисков, и создание моментальных снимков. У неё нет прав на управление ресурсами за пределами кластера. Поскольку ClusterAdmin – это роль администратора, она может использовать портал администрирования или пользовательский портал для управления этими ресурсами.

Пример 2. Разрешения пользователя для управления виртуальной машиной

Иван работает разработчиком программного обеспечения в бухгалтерии. Он использует виртуальные машины для сборки и тестирования своего ПО. Варвара создала для него виртуальный рабочий стол под названием ivandesktop и назначила ему роль UserVmManage на виртуальной машине ivandesktop. У него есть доступ только к этой виртуальной машине через Пользовательский портал. Поскольку у него есть права Пользователя, управляющего ВМ (UserVmManager), он может вносить изменения в виртуальную машину. Поскольку Пользователь, управляющий ВМ (UserVmManager) – это роль пользователя, он не может использовать Портал администрирования.

Пример 3. Разрешения ключевого пользователя в центре данных

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

Хотя у неё есть своя машина для работы офис-менеджера, она хочет создать отдельную виртуальную машину для запуска приложения по подбору персонала. Ей выдана роль с расширенными правами пользователя (PowerUserRole) в центре данных, в котором будет находиться её новая виртуальная машина. Дело в том, что для создания новой виртуальной машины ей нужно внести изменения в несколько компонентов центра данных, в том числе создать виртуальный диск в домене хранения.

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

Пример 4. Разрешения сетевого администратора

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

Пример 5. Разрешения для дополнительно созданных ролей

Багатар работает в ИТ-отделе и отвечает за управление учетными записями пользователей в zVirt. Ему необходимо разрешение на добавление учетных записей пользователей и назначение им соответствующих ролей и разрешений. Он сам не использует виртуальные машины и не должен иметь доступ к администрированию хостов, виртуальных машин, кластеров или центров данных. Готовой роли, предоставляющей ему такой специфический набор разрешений, не существует. Необходимо создать дополнительную роль, в которой будет определен набор разрешений, подходящих для должности Багатара.

Рисунок 1. Дополнительная роль Пользователя с правами управления пользователями (UserManager)

Дополнительная роль пользователя с правами управления пользователями (UserManager), показанная на рисунке выше, позволяет управлять пользователями, разрешениями и ролями. Эти действия собраны в объекте верхнего уровня иерархии Система (System), показанной на Иерархия объектов zVirt. Это означает, что они применяются ко всем прочим объектам в системе. Роль создана с настройками типа учетной записи Администратор (Admin). Следовательно, когда Багатар назначена эта роль, он может воспользоваться как Порталом администрирования, так и Пользовательским порталом.

1.1.2. Системные разрешения

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

Рисунок 2. Разрешения и роли

Рисунок 3. Иерархия объектов zVirt

1.1.2.1. Свойства пользователей

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

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

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

Роль администратора: позволяет получать доступ к Порталу администрирования (Administration Portal) для управления физическими и виртуальными ресурсами. Роль администратора предоставляет разрешения на выполнение действий на пользовательском портале, но никак не влияет на то, что пользователь может там увидеть.
Роль пользователя: позволяет получать доступ к Пользовательскому порталу (VM Portal) для управления и обращения к виртуальным машинам и шаблонам. То, что пользователь может увидеть на пользовательском портале, зависит от его роли. Разрешения, предоставленные пользователю с ролью администратора, отображаются в действиях, доступных для этого пользователя в пользовательском портале.

1.1.2.3. Описание ролей пользователей

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

Таблица 1. Основные пользовательские роли zVirt
Роль	Права	Примечания
UserRole	Может получать доступ к виртуальным машинам и пулам и использовать их.	Может авторизовываться на Пользовательском портале, использовать выделенные виртуальные машины и пулы, просматривать информацию о виртуальных машинах и их состоянии.
PowerUserRole	Может создавать виртуальные машины и шаблоны и управлять ими.	В окне Настройка (Configure) назначьте эту роль пользователю для всей среды, либо только для отдельных центров данных или кластеров. Например, если роль с расширенными правами пользователя (PowerUserRole) применяется на уровне центра данных, то пользователь в этой роли может создавать виртуальные машины и шаблоны центре данных.
UserVmManager	Системный администратор виртуальной машины.	Может управлять виртуальными машинами, создавать и использовать моментальные снимки. Пользователю, который создает виртуальную машину через пользовательский портал, автоматически назначается роль пользователя, управляющего ВМ (UserVmManager) для этой машины.

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

Таблица 2. Дополнительные пользовательские роли zVirt
Роль	Права	Примечания
UserTemplateBasedVm	Ограниченные права - только на использование шаблонов.	Может использовать шаблоны для создания виртуальных машин.
DiskOperator	Пользователь виртуального диска.	Может использовать, просматривать и изменять виртуальные диски. Наследует разрешения на использование виртуальной машины, к которой подключен виртуальный диск.
VmCreator	Может создавать виртуальные машины на пользовательском портале.	Эта роль применяется не к отдельной виртуальной машине. Применяйте эту роль ко всей среде в окне Настройка (Configure). Либо эту роль можно применять к конкретным центрам данных или кластерам. Применяя эту роль к кластеру, нужно также применить роль Создателя диска (DiskCreator) ко всему центру данных или к конкретным доменам хранения.
TemplateCreator	Может создавать, изменять, управлять и удалять шаблоны виртуальных машин в пределах выделенных ресурсов.	Эта роль применяется не к отдельному шаблону. Применяйте ее ко всей среде в окне Настройка (Configure). Либо эту роль можно применять к конкретным центрам данных, кластерам или доменам хранения.
DiskCreator	Может создавать, изменять, удалять и управлять виртуальными дисками в назначенных кластерах или центрах данных.	Эта роль применяется не к отдельному виртуальному диску. Применяйте ее ко всей среде в окне Настройка (Configure). Либо эту роль можно применять к конкретным центрам данных или доменам хранения.
TemplateOwner	Может изменять и удалять шаблон, выдавать пользователям разрешения на применение шаблона и управлять этими разрешениями.	Эта роль автоматически назначается пользователю, создавшему шаблон. Другие пользователи, у которых нет разрешений владелец шаблона (TemplateOwner) в отношении шаблона, не могут просматривать или использовать этот шаблон.
VnicProfileUser	Пользователь логической сети и сетевого интерфейса для виртуальной машины и шаблона.	Может подключать сетевые интерфейсы к конкретным логическим сетям и отключать их.

1.1.2.4. Описание ролей администратора

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

Таблица 3. Основные роли системных администраторов zVirt
Роль	Права	Примечания
SuperUser	Системный администратор среды zVirt.	Обладает всеми разрешениями для всех объектов и уровней, может управлять всеми объектами во всех центрах данных.
ClusterAdmin	Администратор кластера.	Обладает административными разрешениями в отношении всех объектов в конкретном кластере.
DataCenterAdmin	Администратор центра данных.	Обладает административными разрешениями в отношении всех объектов в конкретном центре данных, за исключением хранилища.

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

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

Таблица 4. Дополнительные роли системных администраторов zVirt
Роль	Права	Примечания
TemplateAdmin	Администратор шаблона виртуальной машины.	Может создавать, удалять и конфигурировать домены хранения и параметры сети для шаблонов, а также перемещать шаблоны между доменами.
StorageAdmin	Администратор хранилища.	Может создавать, удалять, конфигурировать назначенный домен хранения, а также управлять этим доменом.
HostAdmin	Администратор хоста.	Может подключать, удалять, конфигурировать конкретный хост или управлять им.
NetworkAdmin	Администратор сети.	Может конфигурировать сеть отдельного центра данных или кластера и управлять такой сетью. Сетевой администратор центра данных или кластера наследует сетевые разрешения на работу с виртуальными пулами в кластере.
VmPoolAdmin	Системный администратор виртуального пула.	Может создавать, удалять и конфигурировать виртуальный пул, назначать и удалять пользователей виртуального пула, а также выполнять базовые операции с виртуальными машинами в пуле.
GlusterAdmin	Администратор хранилища Gluster.	Может создавать, удалять и конфигурировать тома хранения Gluster, а также управлять ими.
VmImporterExporter	Администратор импорта и экспорта виртуальной машины.	Может импортировать и экспортировать виртуальные машины, а также просматривать все виртуальные машины и шаблоны, которые экспортировали другие пользователи.

1.1.2.5. Назначение роли администратора или пользователя ресурсу

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

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

Найдите и щелчком мыши выберите имя ресурса, чтобы увидеть подробные сведения о нем.
Откройте вкладку Разрешения (Permissions), чтобы вывести список назначенных пользователей с информацией о роли каждого из них и унаследованных разрешениях для выбранного ресурса.
Нажмите Добавить (Add).
Введите реальное или пользовательское имя существующего пользователя в текстовое поле и нажмите Поиск (GO). Выберите пользователя из появившегося списка возможных совпадений.
Выберите роль из выпадающего списка Роль для связи (Role to Assign).
Нажмите OK.

Теперь унаследованные разрешения этой роли будут активированы для пользователя в отношении этого ресурса.

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

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

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

1.1.2.6. Удаление роли администратора или пользователя из ресурса

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

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

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

1.1.2.7. Управление системными разрешениями для центра данных

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

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

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

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

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

Системного администратора центра данных можно сменить, удалив существующего системного администратора и добавив нового.

1.1.2.8. Описание ролей администратора центра данных

В таблице ниже описаны роли и права администратора при администрировании центра данных.

Таблица 5. Роли системных администраторов zVirt
Роль	Права	Примечания
DataCenterAdmin	Администратор центра данных	Может использовать, создавать, удалять и управлять всеми физическими и виртуальными ресурсами в пределах одного определенного центра данных, за исключением хранилища, но включая кластеры, хосты, шаблоны и виртуальные машины.
NetworkAdmin	Администратор сети	Может конфигурировать сеть конкретного центра данных и управлять ею. Сетевой администратор центра данных также наследует сетевые разрешения на работу с виртуальными машинами в пределах центра данных.

1.1.2.9. Управление системными разрешениями для кластера

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

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

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

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

Системного администратора кластера можно сменить, удалив существующего системного администратора и добавив нового.

1.1.2.10. Описание ролей администратора кластера

В таблице ниже описаны роли и права администратора при администрировании кластера.

Таблица 6. Роли системных администраторов zVirt
Роль	Права	Примечания
ClusterAdmin	Администратор кластера	Может использовать, создавать, удалять и управлять всеми физическими и виртуальными ресурсами в пределах одного определенного кластера, включая хосты, шаблоны и виртуальные машины. Может конфигурировать свойства сети в пределах кластера, например, определять отображаемые сети или обозначать сеть как обязательную или необязательную. При этом у администратора кластера (ClusterAdmin) нет прав, чтобы подключать и отключать сети от кластера, для этого необходимы права администратора сети (NetworkAdmin).
NetworkAdmin	Администратор сети	Может конфигурировать и управлять сетью конкретного кластера. Администратор сети кластера также наследует сетевые разрешения для виртуальных машин в кластере.

1.1.2.11. Управление системными разрешениями для сети

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

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

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

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

1.1.2.12. Описание ролей администратора сети и пользователя

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

Таблица 7. Роли администратора сети и пользователя zVirt
Роль	Права	Примечания
NetworkAdmin	Администратор сети для центра данных, кластера, хоста, виртуальной машины или шаблона. Пользователю, который создает сеть, автоматически назначаются разрешения администратора сети (NetworkAdmin) в созданной сети.	Может конфигурировать и управлять сетью конкретного центра данных, кластера, хоста, виртуальной машины или шаблона. Администратор сети центра данных или кластера наследует сетевые разрешения на работу с виртуальными пулами в кластере. Чтобы сконфигурировать зеркаллирование портов в сети виртуальных машин, примените роль администратора сети (NetworkAdmin) к сети и роль пользователя, управляющего ВМ (UserVmManager) к виртуальной машине.
VnicProfileUser	Пользователь логической сети и сетевого интерфейса для виртуальной машины и шаблона.	Может подключать сетевые интерфейсы к конкретным логическим сетям и отключать их.

1.1.2.13. Управление системными разрешениями для хоста

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

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

Изменять конфигурацию хоста.
Настраивать логические сети.
Удалять хост.

Системного администратора хоста также можно сменить, удалив существующего системного администратора и добавив нового.

1.1.2.14. Описание ролей администраторов хоста

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

Таблица 8. Роли системного администратора zVirt
Роль	Права	Примечания
HostAdmin	Администратор хоста	Может конфигурировать, управлять и удалять конкретный хост. Может также выполнять связанные с сетью операции на конкретном хосте.

1.1.2.15. Управление системными разрешениями для домена хранения

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

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

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

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

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

1.1.2.16. Описание ролей администратора хранилища

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

Таблица 9. Роли системного администратора zVirt
Роль	Права	Примечания
StorageAdmin	Администратор хранилища	Может создавать, удалять, конфигурировать и управлять конкретным доменом хранения.
GlusterAdmin	Администратор хранилища Gluster	Может создавать, удалять, конфигурировать и управлять томами хранения Gluster.

1.1.2.17. Управление системными разрешениями для пула ВМ

Администратор пула ВМ – это системная административная роль для пулов ВМ в центре данных. Эту роль можно применять к конкретным пулам ВМ, к центру данных или ко всей среде виртуализации; это позволяет различным пользователям управлять определенными ресурсами пула ВМ.

Роль администратора пула ВМ разрешает выполнять следующие действия:

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

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

1.1.2.18. Описание ролей администратора пула (набора) ВМ

В приведенной ниже таблице описаны роли и права администратора, применимые к администрированию пула (набора) ВМ.

Таблица 10. Роли системного администратора zVirt
Роль	Права	Примечания
VmPoolAdmin	Роль системного администратора виртуального пула.	Может создавать, удалять и конфигурировать виртуальный пул, назначать и удалять пользователей виртуального пула, а также выполнять базовые операции на виртуальной машине.
ClusterAdmin	Администратор кластера	Может использовать, создавать, удалять и управлять всеми пулами ВМ в конкретном кластере.

1.1.2.19. Управление системными разрешениями для виртуального диска

В менеджере управления по умолчанию предусмотрены две роли пользователей виртуальных дисков, но ни одной роли администратора виртуальных дисков. Одна из этих ролей – создатель диска (DiskCreator), позволяющая администрировать виртуальные диски через пользовательской портал. Эту роль можно применять к конкретным виртуальным машинам, центру данных, конкретному домену хранения или ко всей среде виртуализации; это позволяет различным пользователям управлять различными виртуальными ресурсами.

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

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

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

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

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

Таблица 11. Роли системного администратора zVirt
Роль	Права	Примечания
DiskOperator	Пользователь виртуального диска.	Может использовать, просматривать и изменять виртуальные диски. Наследует разрешения на использование виртуальной машины, к которой подключен виртуальный диск.
DiskCreator	Может создавать, изменять, удалять и управлять виртуальными дисками в назначенных кластерах или центрах данных.	Эта роль применяется не к отдельному виртуальному диску. Применяйте ее к пользователю для всей среды в разделе Управление (Administration) Пользователи (Users). Либо эту роль можно применять к конкретным центрам данных, кластерам или доменам хранения.

1.1.3. Политики планирования

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

Менеджер управления предоставляет пять политик планирования по умолчанию: Обслуживание кластера (Cluster_Maintenance), Равномерное распределение (Evenly_Distributed), Не назначена (None), Энергосбережение (Power Saving) и Равномерное распределение ВМ (VM_Evenly_Distributed). Вы также можете задать новые политики планирования, обеспечивающие необходимый контроль над распределением виртуальных машин. Независимо от политики планирования виртуальная машина не запустится на хосте с перегруженным процессором. По умолчанию ЦП хоста считается перегруженным, если его загрузка превышает 80% в течение 5 минут, но эти значения можно изменить с помощью политик планирования. Дополнительные сведения о свойствах каждой политики планирования приведены ниже.

Рисунок 4. Политика планирования "Равномерное распределение" (Evenly_Distributed)

Политика планирования Равномерное распределение (Evenly_Distributed) распределяет загрузку ОЗУ и ЦП равномерно между всеми хостами в кластере. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если параметры CpuOverCommitDurationMinutes, HighUtilization или MaxFreeMemoryForOverUtilized этого хоста достигли заданных значений.

Политика планирования Равномерное распределение ВМ (VM_Evenly_Distributed) распределяет виртуальные машины равномерно между хостами, исходя из количества виртуальных машин. Кластер считается несбалансированным, если на любом из хостов запущено больше виртуальных машин, чем указано в параметре HighVmCount, и есть хотя бы один хост, количество виртуальных машин на котором выходит за предельное значение параметра MigrationThreshold.

Рисунок 5. Политика планирования "Энергосбережение (Power Saving)"

Политика планирования Энергосбережение (Power Saving) распределяет загрузку ОЗУ и ЦП по подмножеству доступных хостов, чтобы снизить энергопотребление на недогруженных хостах. Если на некоторых хостах загрузка ЦП находится ниже "нижнего значения загрузки" дольше заданного интервала времени, то, чтобы их питание можно было отключить, все виртуальные машины переносятся с них на другие хосты. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если загрузка этого хоста достигла заданного "верхнего значения загрузки".

Задайте политику Не назначена (None), чтобы запретить разделение нагрузки или питания между хостами для работающих виртуальных машин. Этот режим выбран по умолчанию. Когда виртуальная машина запущена, ресурсы памяти и загрузка ЦП равномерно распределяются между всеми хостами в кластере. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если параметры CpuOverCommitDurationMinutes, HighUtilization или MaxFreeMemoryForOverUtilized этого хоста достигли заданных значений.

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

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

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

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

Нажмите Управление (Administration) Настройка (Configure).
Нажмите вкладку Политика планирования (Scheduling Policies).
Нажмите Новая (New).
Введите Имя (Name) и Описание (Description) для политики планирования.
Сконфигурируйте модули фильтров:
- В разделе Модули фильтров (Filter Modules) из панели Выключенные фильтры (Disabled Filters) перетащите в панель Включенные фильтры (Enabled Filters) модули фильтров, которые хотите применить к политике планирования.
- Кроме того, в целях базовой оптимизации можно конкретный модуль фильтров задать как Первый (First), чтобы присвоить ему высший приоритет, или как Последний (Last), чтобы присвоить ему низший приоритет. Чтобы присвоить приоритет, правой кнопкой нажмите любой модуль фильтра, наведите указатель мыши на пункт Местоположение (Position) и выберите Первый (First) или Последний (Last).
Настройте модули веса:
- В разделе Вес модулей (Weights Modules) из панели Выключенные веса (Disabled Weights) перетащите в панель Включенные веса и факторы (Enabled Weights & Factors) веса, которые хотите применить к политике планирования.
- Нажатием кнопок и слева от включенных модулей веса увеличивайте или уменьшайте вес этих модулей.
Задайте политику балансировки нагрузки:
- В разделе Балансировщик нагрузки (Load Balancer) в раскрывающемся меню выберите политику балансировки нагрузки, которую хотите применить к политике планирования.
- В разделе Свойства (Properties) в раскрывающемся меню выберите свойство балансировки нагрузки, которое хотите применить к политике планирования, и в текстовом поле справа от свойства укажите значение.
- Чтобы добавить или удалить дополнительные свойства, нажимайте кнопки и .
Нажмите OK.

1.1.3.2. Описание настроек в окнах "Новая политика планирования" (New Scheduling Policy) и "Редактировать политику расписания" (Edit Scheduling Policy)

В следующей таблице описываются параметры, настраиваемые в окнах "Новая политика планирования" (New Scheduling Policy) и "Редактировать политику расписания" (Edit Scheduling Policy).

Таблица 12. Настройки в окнах "Новая политика планирования" (New Scheduling Policy) и "Редактировать политику расписания" (Edit Scheduling Policy)
Имя поля	Описание
Имя (Name)	Имя политики планирования. Это имя, используемое для обозначения политики планирования в менеджере управления.
Описание (Description)	Описание политики планирования. Это поле является рекомендованным, но не обязательным.
Модули фильтров (Filter Modules)	Набор фильтров для управления хостами, на которых может запускаться виртуальная машина в кластере. Включение фильтра отфильтрует хосты, не отвечающие условиям, заданным этим фильтром, как описано ниже: `ClusterInMaintenance`: Запускаемые на хосте виртуальные машины, не сконфигурированные для обеспечения высокой доступности, отфильтровывают хост. `CpuPinning`: Хосты, не соответствующие определению закреплённого ЦП". `Migration`: Предотвращение миграции на тот же самый хост. `CPUOverloaded`: Хосты, на которых использование ЦП превышает заданное пороговое значение HighUtilization для интервала, заданного параметром CpuOverCommitDurationMinutes. `PinToHost`: Хосты, отличные от хоста, за которым закреплена виртуальная машина. `CPU-Level`: Хосты, не соответствующие топологии ЦП виртуальной машины. `VmAffinityGroups`: Хосты, не соответствующие правилам сходства, заданным для виртуальной машины. `NUMA`: Хосты, у которых нет узлов NUMA, на которых можно разместить узлы vNUMA виртуальных машин (в плане ресурсов). `InClusterUpgrade`: Хосты, работающие под управлением более ранней версии ОС, чем ОС хоста, на котором сейчас работает виртуальная машина. `MDevice`: Хосты, которые не предоставляют требуемое устройство-посредник (mDev). `Memory`: Хосты, у которых недостаточно оперативной памяти для работы виртуальной машины. * `CPU`: Хосты, у которых количество процессоров меньше количества, выделенного виртуальной машине. `HostedEnginesSpares`: Резервирование пространства для виртуальной машины с менеджером управления на конкретном количестве узлов с ролью hosted engine. `Swap`: Хосты, которые не меняются местами в пределах порогового значения. `VM leases ready`: Хосты, не поддерживающие виртуальные машины, сконфигурированные с арендой хранилища. `VmToHostsAffinityGroups`: Группа хостов, которые не соответствуют условиям, заданным для виртуальной машины, входящей в группу сходства. Например - виртуальные машины в группе сходства должны работать на одном из хостов в группе или на отдельном хосте, исключенном из группы. `HostDevice`: Хосты, которые не поддерживают хост-устройства, необходимые для виртуальной машины. `HA`: Принуждает виртуальную машину с менеджером управления в среде hosted engine работать только на хостах с положительной оценкой высокой доступности. `Emulated-Machine`: Хосты, которые не имеют надлежащей поддержки эмуляции машин. `HugePages`: Хосты, которые не соответствуют требуемому количеству больших страниц (Huge Pages), необходимому для оперативной памяти виртуальной машины. `Migration-Tsc-Frequency`: Хосты, на которых нет виртуальных машин с той же частотой счетчика метки времени (Time Stamp Counter, TSC), что у хоста, на котором сейчас работает виртуальная машина. `Network`: Хосты, на которых не установлены сети, требуемые сетевой картой виртуальной машины, или на которых не установлена «сеть отображения» кластера. `Label`: Хосты, не имеющие необходимых меток сходства. `Compatibility-Version`: Хосты, которые не поддерживают корректную версию совместимости с кластером.
Вес модулей (Weights Modules)	Набор весовых коэффициентов для управления относительным приоритетом факторов, учитываемых при определении хостов в кластере, на которых может работать виртуальная машина: `VmAffinityGroups`: Присваивает хостам веса в соответствии с группами сходства, заданными для виртуальных машин. Этот модуль веса определяет вероятность того, что виртуальные машины в группе сходства будут работать на одном и том же хосте или на разных хостах в соответствии с параметрами этой группы сходства. `InClusterUpgrade`: Присваивает хостам веса в соответствии с их версией операционной системы. Вес налагает больше штрафов на хосты с более ранними версиями операционных систем, чем на хосты с той же версией ОС, что и на хосте, на котором сейчас работает виртуальная машина. Это гарантирует, что приоритет всегда будет отдаваться хостам с более новыми версиями ОС. `OptimalForCpuEvenDistribution`: Присваивает хостам веса в соответствии с их использованием ЦП, отдавая приоритет хостам с более низкой загрузкой ЦП. `CPU for high performance VMs`: Предпочтение отдается хостам с большим или равным количеством сокетов, ядер и потоков, чем на виртуальной машине. `HA`: Присваивает хостам веса в соответствии с их оценкой высокой доступности. `OptimalForCpuPowerSaving`: Присваивает хостам веса в соответствии с их использованием ЦП, отдавая приоритет хостам с более высокой загрузкой ЦП. `OptimalForMemoryPowerSaving`: Присваивает хостам веса в соответствии с их использованием оперативной памяти, отдавая приоритет хостам с меньшим объемом доступной оперативной памяти. `CPU and NUMA pinning compatibility`: Присваивает хостам веса в соответствии с совместимостью по закреплению. Если для виртуальной машины определены как vNUMA, так и закрепление, этот модуль веса отдает предпочтение хостам, у которых закрепление ЦП не конфликтует с закреплением vNUMA. `VmToHostsAffinityGroups`: Присваивает хостам веса в соответствии с группами сходства, заданными для виртуальных машин. Этот модуль веса определяет вероятность того, что виртуальные машины в группе сходства будут работать на одном из хостов в группе или на отдельном хосте, исключенном из группы. `OptimalForEvenGuestDistribution`: Присваивает хостам веса в соответствии с количеством виртуальных машин, работающих на этих хостах. `OptimalForHaReservation`: Присваивает хостам веса в соответствии с их оценкой высокой доступности. `OptimalForMemoryEvenDistribution`: Присваивает хостам веса в соответствии с использованием ими оперативной памяти, отдавая приоритет хостам с большим объемом доступной оперативной памяти. `Fit VM to single host NUMA node`: Присваивает хостам веса в зависимости от того, умещается ли виртуальная машина в один узел NUMA. Если для виртуальной машины не задан виртуальный узел vNUMA, то этот модуль веса отдает предпочтение хостам, которые могут уместить виртуальную машину в один физический узел NUMA. `PreferredHosts`: Предпочтительные хосты имеют приоритет при настройке виртуальной машины.
Балансировщик нагрузки (Load Balancer)	В раскрывающемся меню можно выбрать требуемый модуль балансировки нагрузки. Модули балансировки нагрузки определяют логику, используемую для переноса виртуальных машин с хостов с высокой нагрузкой на хосты с меньшей нагрузкой.
Свойства (Properties)	В раскрывающемся меню можно добавлять или удалять свойства модулей балансировки нагрузки и эта возможность доступна только в том случае, если выбрать модуль балансировки нагрузки для политики планирования. Никакие свойства не заданы по умолчанию, и доступные свойства зависят от выбранного модуля балансировки нагрузки. Для добавления модулю балансировки нагрузки или удаления из него дополнительных свойств используйте кнопки и .

1.1.4. Типы экземпляров

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

Поддержка типов экземпляров признана устаревшей и будет удалена в одном из будущих релизов.

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

Таблица 13. Предопределенные типы экземпляров
Имя	Размер ОЗУ	Кол-во vCPU
Минимальный (Tiny)	512 МБ	1
Малый (Small)	2 ГБ	1
Средний (Medium)	4 ГБ	2
Большой (Large)	8 ГБ	2
Сверхбольшой (XLarge)	16 ГБ	4

Администраторы также могут создавать, изменять и удалять типы экземпляров на вкладке Типы экземпляров (Instance Types) окна Настройка (Configure).

Поля в окнах Новая виртуальная машина (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine), привязанные к типу экземпляра, обозначены значком цепи рядом с ними link . Если значение одного из этих полей изменится, то виртуальная машина будет отключена от типа экземпляра, который изменится на Пользовательский (Custom), а значок цепи будет выглядеть разорванным unlink . Однако, если значение снова станет прежним, целостность цепи будет восстановлена, а тип экземпляра вернется к изначально выбранному.

1.1.4.1. Создание типов экземпляров

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

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Типы экземпляров (Instance Types).
Нажмите Новый (New).
В поля Имя (Name) и Описание (Description) введите имя и описание типа экземпляра.
Нажмите Показать расширенные настройки (Show Advanced Options) и сконфигурируйте настройки типа экземпляра. Настройки в окне Новый тип экземпляра (New Instance Type) аналогичны настройкам в окне Создать виртуальную машину (New Virtual Machine) и отличаются лишь соответствующими полями.
Нажмите OK.

Новый тип экземпляра появится на вкладке Типы экземпляров (Instance Types) в окне Настройка (Configure), и его можно будет выбрать из выпадающего списка Тип экземпляра (Instance Type) при создании или изменении виртуальной машины.

1.1.4.2. Изменение типов экземпляров

Администраторы могут изменять существующие типы экземпляров в окне Настройка (Configure).

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Типы экземпляров (Instance Types).
Выберите тип экземпляра, который нужно изменить.
Нажмите Изменить (Edit).
Измените настройки нужным образом.
Нажмите OK.

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

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

1.1.4.3. Удаление типов экземпляров

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Типы экземпляров (Instance Types).
Выберите тип экземпляра, который нужно удалить.
Нажмите Удалить (Remove).
Если имеются какие-либо виртуальные машины, основанные на типе экземпляра, который подлежит удалению, то появится окно предупреждения со списком подключенных виртуальных машин. Чтобы продолжить удаление типа экземпляра, поставьте флажок в поле Подтвердить операцию (Approve Operation). В противном случае нажмите Отмена (Cancel).
Нажмите OK.

Тип экземпляра удален из списка Типы экземпляров (Instance Types) и больше не может использоваться при создании новой виртуальной машины. Любые виртуальные машины, которые были подключены к удаленному типу экземпляра, будут подключены к типу Пользовательский (Custom) (без типа экземпляра).

1.1.5. Пулы MAC-адресов

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

Несколько кластеров могут использовать один и тот же пул MAC-адресов, но каждому кластеру назначается один пул MAC-адресов. zVirt создает пул MAC-адресов по умолчанию, который используется, если не назначен другой пул MAC-адресов. Дополнительные сведения о назначении пулов MAC-адресов кластерам см. в разделе Создание нового кластера.

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

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

1.1.5.1. Создание пулов MAC-адресов

Вы можете создавать новые пулы MAC-адресов.

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Пулы MAC-адресов (MAC Address Pools).
Нажмите Добавить (Add).
Введите имя и описание нового пула MAC-адресов в поля Имя (Name) и Описание (Description).

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

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

Введите необходимые диапазоны MAC-адресов в поле Диапазоны MAC-адресов (MAC Address Ranges). Для ввода нескольких диапазонов нажмите кнопку "+" рядом с полями Из (From) и В (To).
Нажмите OK

1.1.5.2. Изменение пулов MAC-адресов

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

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Пулы MAC-адресов (MAC Address Pools).
Выберите пул MAC-адресов, который нужно отредактировать.
Нажмите Изменить (Edit).

Измените поля Имя (Name), Описание (Description), Разрешить дубликаты (Allow Duplicates) и Диапазоны MAC-адресов (MAC Address Ranges) нужным образом.

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

Нажмите OK.

1.1.5.3. Удаление пулов MAC-адресов

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

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

Нажмите Управление (Administration) Настройка (Configure).
Откройте вкладку Пулы MAC-адресов (MAC Address Pools).
Выберите пул MAC-адресов, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

1.2. Экран мониторинга (Dashboard)

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

По умолчанию информация на экране мониторинга обновляется каждые 15 минут из Xранилища данных (Data Warehouse, DWH), каждые 15 секунд с помощью API менеджера управления или при каждом обновлении экрана мониторинга. Экран мониторинга обновляется, когда пользователь возвращается с другой страницы или обновляет экран вручную. Экран мониторинга не обновляется автоматически. Информацию об инвентарной карточке учета предоставляет API менеджера управления, а информацию об использовании ресурсов предоставляет Хранилище (DWH). Экран мониторинга реализован как компонент плагина пользовательского интерфейса, который автоматически устанавливается и обновляется вместе с менеджером управления.

Рисунок 6. Экран мониторинга

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

Для использования экрана мониторинга требуется установить и настроить Хранилище (DWH).

1.2.2. Глобальный перечень ресурсов

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

Рисунок 7. Глобальный перечень ресурсов

В заголовке отображается количество ресурсов данного типа, а под заголовком - их статус. По щелчку на заголовке ресурса откроется соответствующая страница в менеджере управления. Для кластеров (Clusters) статус всегда отображается как N/A.

Таблица 14. Статус ресурса
Значок	Статус
	Ни один из этих ресурсов не был добавлен в zVirt.
	Показывает количество ресурсов, имеющих статус предупреждения. По щелчку на значке откроется соответствующая страница с поиском, который охватывает только ресурсы со статусом предупреждения. Поиск ограничен по-разному для каждого ресурса: * Центры данных (Data Centers): Поиск охватывает только центры данных, которые не работают или не отвечают. * Тома Gluster (Gluster Volumes): Поиск охватывает только тома Gluster, которые находятся в процессе включения/выключения питания, приостановлены, переносятся, ожидают, или временно не работают. * Хосты (Hosts): Поиск охватывает только хосты, которые не назначены, находятся в режиме обслуживания, в состоянии установки, перезагрузки, подготовки к обслуживанию, ожидания утверждения или подключения. * Домены хранения (Storage Domains): Поиск охватывает только домены хранения, которые не инициализированы, не подключены, неактивны, находятся в режиме обслуживания, готовятся к обслуживанию, отключаются или активируются. * Виртуальные машины (Virtual Machines): Поиск охватывает только виртуальные машины, которые находятся в процессе включения/выключения питания, приостановлены, переносятся, ожидают, или временно не работают. * События (Events): Поиск охватывает только события со степенью критичности "предупреждение".
	Показывает количество ресурса во включенном состоянии. По щелчку на значке откроется соответствующая страница с поиском, который охватывает только включенные ресурсы.
	Показывает количество ресурса в выключенном состоянии. По щелчку на значке откроется соответствующая страница с поиском, который охватывает только ресурсы в выключенном состоянии. Поиск ограничен по-разному для каждого ресурса: * Центры данных (Data Centers): Поиск охватывает только центры данных, которые не инициализированы, находятся в режиме обслуживания или в выключенном состоянии. * Тома Gluster (Gluster Volumes): Поиск охватывает только отключенные или неактивные тома Gluster. * Хосты (Hosts): Поиск охватывает только хосты, которые не отвечают, имеют ошибки, имеют ошибки установки, не работоспособны, инициализируются или выключены. * Домены хранения (Storage Domains): Поиск охватывает только домены хранения, которые отключены или неактивны. * Виртуальные машины (Virtual Machines): Поиск охватывает только виртуальные машины, которые выключены, не отвечают или перезагружаются.
	Показывает количество событий со статусом "оповещение". По щелчку на значке откроется страница События (Events), где поиск будет охватывать только события со степенью критичности "оповещение".
	Показывает количество событий со статусом "ошибка". По щелчку на значке откроется страница События (Events), где поиск будет охватывать только события со степенью критичности "ошибка".
	Показывает количество событий со статусом "Событие безопасности". По щелчку на значке откроется страница События (Events), где поиск будет охватывать только события со степенью критичности "Безопасность".

1.2.3. Глобальное использование ресурсов

Раздел Использование ресурсов (Global Utilization) показывает, как система использует ресурсы ЦП, оперативной памяти и хранилища.

Рисунок 8. Использование ресурсов

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

1.2.3.1. Самые используемые ресурсы

Рисунок 9. Самые используемые ресурсы (оперативная память)

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

1.2.4. Использование кластера

В разделе Использование кластера (Cluster Utilization) на тепловой карте показано использование таких ресурсов кластера, как ЦП и оперативная память.

Рисунок 10. Использование кластера

1.2.4.1. ЦП

Тепловая карта использования ресурсов ЦП для конкретного кластера, показывающая среднее использование ресурсов ЦП за последние 24 часа. При наведении указателя мыши на тепловую карту отображается имя кластера. Нажмите на тепловую карту, чтобы перейти в раздел Ресурсы (Compute) Хосты (Hosts) и просмотреть результаты поиска в конкретном кластере, отсортированные по использованию ресурсов ЦП. Использование ресурсов ЦП кластером рассчитывается по формуле среднего использования ресурсов ЦП хостом в кластере. Для расчета берутся средние значения использования ресурсов ЦП каждым хостом за последние 24 часа и по ним находится усредненное значение использования ресурсов ЦП по всему кластеру.

1.2.4.2. Память

Тепловая карта использования оперативной памяти для конкретного кластера, показывающая среднее использование оперативной памяти за последние 24 часа. При наведении указателя мыши на тепловую карту отображается имя кластера. Нажмите на тепловую карту, чтобы перейти в раздел Ресурсы (Compute) Хосты (Hosts) и просмотреть результаты поиска в конкретном кластере, отсортированные по использованию ресурсов оперативной памяти. Использование оперативной памяти кластером рассчитывается по формуле общего использования оперативной памяти в кластере в ГБ. Для расчета берутся средние значения использования ресурсов оперативной памяти каждым хостом за последние 24 часа и по ним находится усредненное значение использования ресурсов оперативной памяти по всему кластеру.

1.2.5. Использование хранилища

В разделе Использование хранилища (Storage Utilization) на тепловой карте показано использование ресурсов хранилища.

Рисунок 11. Использование хранилища

Тепловая карта показывает среднее использование ресурсов хранилища за последние 24 часа. Использование ресурсов хранилища кластером рассчитывается по формуле общего использования ресурсов хранилища в кластере. Для расчета берутся средние значения использования ресурсов хранилища каждым хостом за последние 24 часа и по ним находится усредненное значение использования ресурсов хранилища по всему кластеру. При наведении указателя мыши на тепловую карту отображается имя домена хранения. Нажмите на тепловую карту, чтобы перейти в раздел Хранилище (Storage) Домены хранения (Domains) и просмотреть домены хранения, отсортированные по объему использования.

1.3. Поиск

1.3.1. Как устроен поиск в zVirt

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

1.3.2. Синтаксис и примеры поиска

Синтаксис поисковых запросов в ресурсах zVirt выглядит следующим образом:

result type: {criteria} [sortby sort_spec]

где result type: - не редактируемая визуальная часть, зависит от того, где находится администратор. Для Ресурсы (Compute) Виртуальные машины (Virtual Machines) будет равна Vms:, для Ресурсы (Compute) Хосты (Hosts) - Hosts: и т.д. Служит напоминанием о типе возвращаемого результата, в примерах ниже его вводить не надо.

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

1.3.2.1. Примеры синтаксиса

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

Таблица 15. Примеры поисковых запросов
Пример	Результат
`Hosts: Vms.status = up page 2`	Выводит страницу 2 списка всех хостов, на которых запущены виртуальные машины.
`Vms: domain = qa.company.com`	Выводит список всех виртуальных машин, запущенных в конкретном домене.
`Vms: name = sz`	Выводит список всех виртуальных машин, содержащих в названии символы `sz`
`Events: severity > normal sortby time`	Отображает список всех событий, критичность которых превышает нормальную, отсортированных по времени.

1.3.3. Автозаполнение поиска

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

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

Hosts: Vms.status = down

Таблица 16. Примеры поисковых запросов с автозаполнением
Ввод	Отображаемые элементы	Действие
`Hosts:` `Space`	Все свойства хостов	Наберите v
`Hosts: v`	Все свойства хостов, начинающиеся с буквы `v`	Выберите `Vms` или наберите Vms
`Hosts: Vms`	Все свойства виртуальных машин	Наберите s
`Hosts: Vms.s`	Все свойства виртуальных машин, начинающиеся с буквы `s`	Выберите `status` или наберите status
`Hosts: Vms.status`	`=` и `!=`	Выберите или наберите знак =
`Hosts: Vms.status =`	Все значения статусов	Выберите или наберите down (выключен)

1.3.4. Разные типы результатов поиска

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

Vms для списка виртуальных машин
Host для списка хостов
Pools для списка пулов
Template для списка шаблонов
Events для списка событий
Users для списка пользователей и групп пользователей
Cluster для списка кластеров
DataCenter для списка центров данных
Storage для списка доменов хранения
Disk для списка дисков
Volumes для списка томов Gluster.

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

1.3.5. Критерии поиска

Критерии поиска можно указать в запросе после двоеточия. Синтаксис {criteria} выглядит следующим образом:

<prop><operator><value>

или

<obj-type><prop><operator><value>

1.3.5.1. Примеры

В таблице ниже описаны единицы синтаксиса:

Таблица 17. Примеры критериев поиска
Единица	Описание	Значения	Пример	Примечание
prop	Свойство искомого ресурса Может также быть свойством типа ресурса (см. `obj-type`)) или тегом (tag) (пользовательский тег).	Сужает поиск до объектов с определенным свойством. Например, для поиска объектов со свойством статус (status).	Status	-
obj-type	Тип ресурса, который может быть ассоциирован с искомым ресурсом.	Это системные объекты, например, центры данных и виртуальные машины.	Users	-
operator	Операторы сравнения.	`=` `!=` (не равно) `>` `<` `>=` `⇐`	—	Варианты значений зависят от свойства.
value	То, с чем сравнивается выражение.	`Строка (String)` `Целое число (Integer)` `Рейтинг (Rancking)` `Дата (Date) (формат согласно региональным настройкам)`	Иванов 256 обычный	В строках можно применять шаблоны подстановки. "" (в кавычках без пробелов между ними) можно обозначить неинициированную (пустую) строку. В двойные кавычки заключают строку или дату с пробелами

1.3.6. Поиск: несколько критериев и шаблонов подстановки

Шаблоны подстановки можно использовать в единице синтаксиса <value> для строк. Например, чтобы найти всех пользователей, начинающихся с буквы m, введите m*.

Можно задать поиск по двум критериям с помощью логических операторов И (AND) и ИЛИ (OR).

Пример 6. несколько критериев и шаблонов подстановки

Vms: users.name = m* AND status = Up

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

Vms: users.name = m* AND tag = "paris-loc"

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

Когда задается два критерия без И (AND) или ИЛИ (OR), то подразумевается оператор И (AND). Оператор И (AND) выполняется перед оператором ИЛИ (OR), а оператор ИЛИ (OR) – перед подразумеваемым оператором И (AND).

1.3.7. Поиск: определение порядка поиска

Порядок сортировки выданной информации можно задать, используя команду сортировать по sortby. Можно установить и направление сортировки (asc – по возрастанию, desc – по убыванию).

Пример 7. определение порядка поиска

events: severity > normal sortby time desc

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

1.3.8. Поиск для центров данных

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

Таблица 18. Поиск для центров данных
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Clusters.clusters-prop	Зависит от типа свойства	Свойство кластеров, ассоциированных с центром данных. Свойство по умолчанию - `name`
Storage.storage-prop	Зависит от типа свойства	Свойство доменов хранения, ассоциированных с центром данных. Свойство по умолчанию - `name`
Network.network-prop	Зависит от типа свойства	Свойство сетей, ассоциированных с центром данных. Свойство по умолчанию - `name`
name	Строка	Имя центра данных.
description	Строка	Описание центра данных.
local	Логический	true если тип хранилища `локальный` и false, если тип хранилища `общий`
status	Список	Доступность центра данных.
comment	Строка	Комментарий к центру данных
compatibility_version	Строка	Версия совместимости центра данных
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример 8. Поиск для центров данных

Datacenter: Storage.type = nfs and status != up

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

Datacenter: Storage.name = domain1 and status = up

По запросу в примере будет выдан центр данных c включенным хранилищем с именем domain1. Запись запроса равносильна:

Datacenter: Storage = domain1 and status = up

1.3.9. Поиск для кластеров

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

Таблица 19. Поиск для кластеров
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Datacenter.datacenter-prop	Зависит от типа свойства	Свойство центра данных, куда входит кластер. Свойство по умолчанию - `name`
Storage.storage-prop	Зависит от типа свойства	Свойство доменов хранения, ассоциированных с кластером. Свойство по умолчанию - `name`
Cluster_network.network-prop	Зависит от типа свойства	Свойство сетей, ассоциированных с кластером. Свойство по умолчанию - `network_name`
name	String (Строка)	Уникальное имя, определяющее кластеры в сети.
description	String (Строка)	Описание кластера.
comment	Строка	Комментарий к центру данных
architecture	Список	Архитектура хостов кластера
compatibility_level	String (Строка)	Версия совместимости
cpu_type	String (Строка)	Тип процессора хостов кластера
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример 9. Поиск для кластеров

Clusters: architecture = x86 or name = Default

По запросу в примере будет выдан список кластеров, которые объединяют хосты на архитектуре x86 или имеют название Default.

1.3.10. Поиск для хостов

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

Таблица 20. Поиск для хостов
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Vms.Vms-prop	Зависит от типа свойства	Свойство виртуальных машин, ассоциированных с хостом.
Templates.templates-prop	Зависит от типа свойства	Свойство шаблонов, ассоциированных с хостом.
Events.events-prop	Зависит от типа свойства	Свойство событий, ассоциированных с хостом.
Users.users-prop	Зависит от типа свойства	Свойство пользователей, ассоциированных с хостом.
Storage.storage-prop	Зависит от типа свойства	Свойство хранилищ, ассоциированных с хостом.
Nic.nic-prop	Зависит от типа свойства	войство vNIC, ассоциированных с хостом.
name	String (Строка)	Имя хоста.
comment	Строка	Комментарий к хосту
status	List (Список)	Доступность хоста.
external_status	String (Строка)	Статус состояния хоста по данным внешних систем и подключаемых модулей.
cluster	String (Строка)	Кластер, к которому относится хост.
address	String (Строка)	Уникальное имя, определяющее хост в сети.
cpu_usage	Integer (Целое число)	Процент использования вычислительной мощности.
mem_usage	Integer (Целое число)	Процент использования оперативной памяти.
network_usage	Integer (Целое число)	Процент использования сети.
load	Integer (Целое число)	Очередь готовых к выполнению задач в очереди выполнения (run-queue) на каждом процессоре в конкретном разрезе времени.
version	Integer (Целое число)	Номер версии операционной системы.
cpus	Integer (Целое число)	Количество ЦП на хосте.
memory	Integer (Целое число)	Объем доступной оперативной памяти.
cpu_speed	Integer (Целое число)	Тактовая частота ЦП.
cpu_model	String (Строка)	Тип ЦП.
active_vms	Integer (Целое число)	Количество виртуальных машин, работающих на текущий момент.
migrating_vms	Integer (Целое число)	Количество виртуальных машин, находящихся в процессе миграции.
committed_mem	Integer (Целое число)	Процент выделенной памяти.
tag	String (Строка)	Тег, назначенный хосту.
type	String (Строка)	Тип хоста.
datacenter	String (Строка)	Центр данных, к которому относится хост.
architecture	String (Строка)
update_available	String (Строка)
ha_score	String (Строка)
spm_id	String (Строка)
hw_id	String (Строка)
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 10. Поиск для хостов

Hosts: cluster = Default and Vms.os = rhel6

По запросу в примере будет выдан список хостов, которые входят в кластер Default и где размещаются виртуальные машины на базе операционной системы Red Hat Enterprise Linux 6.

1.3.11. Поиск для сетей

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

Таблица 21. Поиск для сетей
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Cluster_network.clusternetwork-prop	Зависит от типа свойства	Свойство кластера, ассоциированного с сетью.
Host_Network.hostnetwork-prop	Зависит от типа свойства	Свойство хоста, ассоциированного с сетью.
Provider.hostnetwork-prop	Зависит от типа свойства	Свойство провайдера, ассоциированного с сетью.
name	String (Строка)	Имя, которое определяет сеть.
description	String (Строка)	Ключевые слова или текстовое описание сети, которые можно дополнительно использовать при создании сети.
comment	Строка	Комментарий к сети
vlanid	Integer (Целое число)	Идентификатор VLAN сети.
stp	String (Строка)	Показывает, включен или выключен STP-протокол для сети.
mtu	Integer (Целое число)	Максимальный размер передаваемого блока данных для логической сети.
vmnetwork	String (Строка)	Показывает, используется ли сеть исключительно для трафика виртуальных машин.
datacenter	String (Строка)	Центр данных, к которому подключена сеть.
label	String (Строка)
provider_name	String (Строка)
qos_name	String (Строка)
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 11. Поиск для сетей

Network: mtu > 1500 and vmnetwork = true

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

1.3.12. Поиск для хранилищ

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

Таблица 22. Поиск для хранилищ
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Hosts.hosts-prop	Зависит от типа свойства	Свойство хостов, ассоциированных с хранилищем.
Clusters.clusters-prop	Зависит от типа свойства	Свойство кластеров, ассоциированных с хранилищем.
name	String (Строка)	Уникальное имя, определяющее хранилище в сети.
status	String (Строка)	Статус домена хранения.
shared_status	String (Строка)
external_status	String (Строка)	Статус состояния домена хранения по данным внешних систем и подключаемых модулей.
datacenter	String (Строка)	Центр данных, к которому относится хранилище.
type	String (Строка)	Тип хранилища
free-size	Integer (Целое число)	Объем (ГБ) свободного места в хранилище.
used-size	Integer (Целое число)	Объем (ГБ) занятого места в хранилище.
total_size	Integer (Целое число)	Общий объем (ГБ) доступного места в хранилище.
committed	Integer (Целое число)	Объем (ГБ) выделенного места в хранилище.
comment	String (Строка)	Комментарий к хранилищу.
description
wipe_after_delete
discard_after_delete
low_space_threshold (%)
critical_space_threshold (gb)
backup
sortby	String (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 12. Поиск для хранилищ

Storage: free_size > 6 GB and total_size < 20 GB

По запросу в примере будет выдан список хранилищ со свободным местом больше 6 ГБ или с общим объемом имеющегося места меньше 20 ГБ.

1.3.13. Поиск для дисков

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

С помощью фильтров Тип Диска (Disk Type) и Тип содержимого (Content Type) можно уменьшить количество отображаемых виртуальных дисков.

Таблица 23. Поиск для дисков
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Datacenters.datacenters-prop	Зависит от типа свойства	Свойство центра данных, ассоциированного с диском.
Storages.storages-prop	Зависит от типа свойства	Свойство хранилища, ассоциированного с диском.
alias или name	String (Строка)	Имя, которое определяет хранилище в сети.
description	String (Строка)	Ключевые слова или текстовое описание диска, которые можно дополнительно использовать при создании диска.
provisioned_size	Integer (Целое число)	Виртуальный объем диска в байтах.
size	Integer (Целое число)	Объем диска.
actual_size	Integer (Целое число)	Фактический объем, выделенный для диска.
creation_date	Integer (Целое число)	Дата создания диска.
bootable	String (Строка)	Показывает, можно ли с диска загрузить операционную систему. Допустимы следующие значения: 0, 1, yes (да) или no (нет)
shareable	String (Строка)	Показывает, можно ли подключить диск к нескольким виртуальным машинам одновременно. Допустимы следующие значения: 0, 1, yes (да) или no (нет)
format	String (Строка)	Формат диска. Возможны значения unused (не используется), unassigned (не назначен), cow (расширенный) или raw (сырой).
status	String (Строка)	Статус диска. Возможны значения unassigned (не назначен ВМ), ok (в порядке), locked (заблокирован), invalid (недействителен) или illegal (недопустим).
disk_type	String (Строка)	Тип диска. Возможны значения image (образ) или lun (логический номер устройства).
disk_content_type
allocation_policy
number_of_vms	String (Строка)	Количество виртуальных машин, к которым подключен диск.
vm_names	String (Строка)	Имя виртуальной машины или машин, к которым подключен диск.
quota	String (Строка)	Имя квоты, установленной для виртуального диска.
id
wipe_after_delete
last_modified
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 13. Поиск для дисков

Disks: format = cow and provisioned_size > 8

По запросу в примере будет выдан список виртуальных дисков формата QCOW с выделенным дисковым пространством больше 8 ГБ.

1.3.14. Поиск для томов

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

Таблица 24. Поиск для томов
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Cluster	Строка	Имя кластера, ассоциированного с томом.
Cluster.cluster-prop	Зависит от типа свойства (например, имя, описание, комментарий, архитектура)	Свойство кластеров, ассоциированных с томом.
name	String (Строка)	Имя, которым определяется том.
type	String (Строка)	Возможны значения distribute (распределенный), replicate (реплицированный), distributed_replicate (распределенно-реплицированный), stripe (чередующийся) или distributed_stripe (распределенно-чередующийся).
transport_type	Integer (Целое число)	Возможны значения протокол управления передачей (TCP) или удаленный прямой доступ к памяти (RDMA).
replica_count	Integer (Целое число)	Количество реплик.
stripe_count	Integer (Целое число)	Количество полос.
status	String (Строка)	Статус тома. Возможны значения Up (Включен) или Down (Выключен).
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 14. Поиск для томов

Volume: transport_type = rdma and stripe_count >= 2

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

1.3.15. Поиск для виртуальных машин

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

На текущий момент параметры поиска не поддерживают свойства Network Label (Метка сети), Custom Emulated Machine (Пользовательская эмулируемая машина) и Custom CPU Type (Пользовательский тип ЦП).

Таблица 25. Поиск для виртуальных машин
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Hosts.hosts-prop	Зависит от типа свойства	Свойство хостов, ассоциированных с виртуальной машиной.
Templates.templates-prop	Зависит от типа свойства	Свойство шаблонов, ассоциированных с виртуальной машиной.
Events.events-prop	Зависит от типа свойства	Свойство событий, ассоциированных с виртуальной машиной.
Users.users-prop	Зависит от типа свойства	Свойство пользователей, ассоциированных с виртуальной машиной.
Storage.storage-prop	Зависит от типа свойства	Свойство устройств хранения, ассоциированных с виртуальной машиной.
Vnic.vnic-prop	Зависит от типа свойства	Свойство vNIC, ассоциированных с виртуальной машиной.
name	String (Строка)	Имя виртуальной машины.
comment	String (Строка)	Комментарий к виртуальной машине.
status	List (Список)	Доступность виртуальной машины.
ip	Integer (Целое число)	IP-адрес виртуальной машины.
on_host
fqdn
uptime	Integer (Целое число)	Сколько минут виртуальная машина уже работает.
domain	String (Строка)	Домен (обычно домен Active Directory), в котором сгруппированы эти машины.
os	String (Строка)	Операционная система, выбранная при создании виртуальной машины.
creationdate	Date (Дата)	Дата создания виртуальной машины.
address	String (Строка)	Уникальное имя, определяющее виртуальную машину в сети.
cpu_usage	Integer (Целое число)	Процент использования вычислительной мощности CPU.
mem_usage	Integer (Целое число)	Процент использования оперативной памяти.
network_usage	Integer (Целое число)	Процент использования сети.
memory	Integer (Целое число)	Максимальная заданная память.
guaranteed_memory
migration_progress_percent
apps	String (Строка)	Приложения, установленные в настоящий момент на виртуальной машине.
cluster	List (Список)	Кластер, которому относится виртуальная машина.
pool	List (Список)	Пул виртуальных машин, к которому относится виртуальная машина.
loggedinuser	String (Строка)	Имя пользователя, авторизованного в настоящий момент на виртуальной машине.
tag	List (Список)	Теги, к которым относится виртуальная машина.
datacenter	String (Строка)	Центр данных, к которому относится виртуальная машина.
type	List (Список)	Тип виртуальной машины (сервер или рабочая станция).
quota	String (Строка)	Имя квоты, ассоциированной с виртуальной машиной.
id
description	String (Строка)	Ключевые слова или текстовое описание виртуальной машины, которые дополнительно были использованы при создании виртуальной машины.
architecture
custom_emulated_machine
custom_cpu_type
compatibility_level
custom_compatibility_level
created_by_user_id
next_run_configuration_exists	Bool (Логическая константа)	Есть ли изменения конфигурации, внесенные в виртуальную машину и ожидающие подтверждения.
has_illegal_images
bios_type
k8s_namespace
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 15. Поиск для виртуальных машин

Vms: template.name = Win* and user.name = ""

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

Vms: cluster = Default and os = windows7

По запросу в примере будет выдан список виртуальных машин, которые относятся к кластеру Default и работают на базе Windows 7.

1.3.16. Поиск для пулов

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

Таблица 26. Поиск для пулов
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
name	String (Строка)	Имя пула.
description	String (Строка)	Описание пула.
comment	String (Строка)	Комментарий к пулу.
type	List (Список)	Тип пула.
cluster
datacenter
architecture
assigned_vm_count
running_vm_count
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 16. Поиск для пулов

Pools: type = automatic

По запросу в примере будет выдан список пулов типа automatic (автоматический).

1.3.17. Поиск для шаблонов

В таблице ниже описаны все возможности поиска для шаблонов.

Таблица 27. Поиск для шаблонов
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Vms.Vms-prop	String (Строка)	Свойство виртуальных машин, ассоциированных с шаблоном.
Hosts.hosts-prop	String (Строка)	Свойство хостов, ассоциированных с шаблоном.
Events.events-prop	String (Строка)	Свойство событий, ассоциированных с шаблоном.
Users.users-prop	String (Строка)	Свойство пользователей, ассоциированных с шаблоном.
Storage
Vnic
name	String (Строка)	Имя шаблона.
comment	String (Строка)	Комментарий к шаблону.
domain	String (Строка)	Домен шаблона.
os	String (Строка)	Тип операционной системы.
creationdate	Integer (Целое число)	Дата создания шаблона. Дата указана в формате месяц/день/год (mm/dd/yy) .
childcount	Integer (Целое число)	Количество виртуальных машин, созданных по шаблону.
mem	Integer (Целое число)	Заданная память.
description	String (Строка)	Описание шаблона.
status	String (Строка)	Статус шаблона.
sealed
cluster	String (Строка)	Кластер, ассоциированный с шаблоном.
datacenter	String (Строка)	Центр данных, ассоциированный с шаблоном.
quota	String (Строка)	Квота, ассоциированная с шаблоном.
architecture
version_name
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 17. Поиск для шаблонов

Template: Events.severity >= normal and Vms.uptime > 0

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

1.3.18. Поиск для пользователей

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

Таблица 28. Поиск для пользователей
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Vms.Vms-prop	Зависит от типа свойства	Свойство виртуальных машин, ассоциированных с пользователем.
Hosts.hosts-prop	Зависит от типа свойства	Свойство хостов, ассоциированных с пользователем.
Templates.templates-prop	Зависит от типа свойства	Свойство шаблонов, ассоциированных с пользователем.
Events.events-prop	Зависит от типа свойства	Свойство событий, ассоциированных с пользователем.
name	String (Строка)	Имя пользователя.
lastname	String (Строка)	Фамилия пользователя.
username или login	String (Строка)	Уникальное имя пользователя.
directory
department	String (Строка)	Департамент, к которому относится пользователь.
group	String (Строка)	Группа, к которой относится пользователь.
tag	String (Строка)	Тег, к которому относится пользователь.
pool	String (Строка)	Пул, к которому относится пользователь.
type
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 18. Поиск для пользователей

Users: Events.severity > normal and Vms.status = up or Vms.status = pause

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

1.3.19. Поиск в событиях

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

Таблица 29. Поиск в событиях
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Vms.Vms-prop	Зависит от типа свойства	Свойство виртуальных машин, ассоциированных с событием.
Hosts.hosts-prop	Зависит от типа свойства	Свойство хостов, ассоциированных с событием.
Templates.templates-prop	Зависит от типа свойства	Свойство шаблонов, ассоциированных с событием.
Users.users-prop	Зависит от типа свойства	Свойство пользователей, ассоциированных с событием.
Clusters.clusters-prop	Зависит от типа свойства	Свойство кластеров, ассоциированных с событием.
Volumes.Volumes-prop	Зависит от типа свойства	Свойство томов, ассоциированных с событием.
type	List (Список)	Тип события.
severity	List (Список)	Критичность события: normal/warning/error/security/alert (нормальное/предупреждение/ошибка/безопасность/тревога)
message	String (Строка)	Описание типа события.
time	List (Список)	Время и дата события.
usrname	String (Строка)	Имя пользователя, ассоциированного с событием.
event_host	String (Строка)	Хост, ассоциированный с событием.
event_vm	String (Строка)	Виртуальная машина, ассоциированная с событием.
event_template	String (Строка)	Шаблон, ассоциированный с событием.
event_storage	String (Строка)	Хранилище, ассоциированное с событием.
event_datacenter	String (Строка)	Центр данных, ассоциированный с событием.
event_volume	String (Строка)	Том, ассоциированный с событием.
correlation_id	Integer (Целое число)	Идентификатор события.
origin
custom_event_id
custom_event_id
sortby	List (Список)	Сортирует результаты поиска по одному из свойств ресурса.
page	Integer (Целое число)	Отображаемый номер страницы результатов.

Пример 19. Поиск в событиях

Events: Vms.name = testdesktop and Hosts.name = gonzo.example.com

По запросу в примере будет выдан список событий, которые произошли на виртуальной машине с именем testdesktop, когда та работала на хосте gonzo.example.com.

1.4. Закладки

1.4.1. Сохранение строки запроса в виде закладки

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

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

Введите нужный поисковый запрос в строку поиска и выполните поиск.
Нажмите кнопку Закладка (Bookmark) () справа от строки поиска. Откроется окно Новая закладка (New Bookmark).
В поле Имя (Name) введите имя закладки.
При необходимости измените поле Строка поиска (Search string).
Нажмите OK.

Нажмите значок Закладки (Bookmarks) () в верхней панели, чтобы найти и выбрать закладку.

1.4.2. Изменение закладки

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

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

Нажмите значок Закладки (Bookmarks) () в верхней панели.
Выберите закладку и нажмите Изменить (Edit).
При необходимости измените поля Имя (Name) и Строка поиска (Search string).
Нажмите OK.

1.4.3. Удаление закладки

Когда закладка больше не нужна, удалите ее.

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

Нажмите значок Закладки (Bookmarks) () в верхней панели.
Выберите закладку и нажмите Удалить (Remove).
Нажмите OK.

1.5. Метки

1.5.1. Использование меток для пользовательской настройки взаимодействий с zVirt

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

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

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

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

1.5.2. Создание метки

Создавайте метки, чтобы с их помощью фильтровать результаты поиска.

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

Нажмите значок Метки (Tags) () в верхней панели.
Нажмите Добавить (Add), чтобы создать новую метку, либо выберите метку и нажмите Новый (New), чтобы создать подчиненную метку.
Введите Имя (Name) и Описание (Description) новой метки.
Нажмите OK.

1.5.3. Изменение метки

Вы можете изменить имя и описание метки.

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

Нажмите значок Метки (Tags) () в верхней панели.
Выберите метку, которую вы хотите изменить, и нажмите Изменить (Edit).
При необходимости измените поля Имя (Name) и Описание (Description).
Нажмите OK.

1.5.4. Удаление метки

Когда метка больше не нужна, удалите её.

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

Нажмите значок Метки (Tags) () в верхней панели.
Выберите метку, которую хотите удалить, и нажмите Удалить (Remove). Появится предупреждение о том, что удаление метки также удалит все подчиненные метки.
Нажмите OK.

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

1.5.5. Добавление меток к объектам и удаление меток с объектов

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

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

Выберите объект(ы), на которых вы хотите назначить/удалить метки.
Нажмите Дополнительные действия (More Actions) (), затем – Назначить метки (Assign Tags).
Установите флажок, чтобы назначить метку объекту, либо снимите флажок, чтобы снять назначение метки с объекта.
Нажмите OK.

Указанная метка теперь добавляется или удаляется как пользовательское свойство выбранного объекта(-ов).

1.5.6. Поиск объектов с помощью меток

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

Объекты с метками, соответствующими указанным критериям, перечислены в списке результатов.

Если вы ищете объекты, используя метку (tag) в качестве свойства и оператор неравенства (!=), например, Host: Vms.tag!=server1, то список результатов не будет включать в себя объекты без тегов.

1.5.7. Пользовательская настройка хостов с помощью меток

Вы можете использовать метки для хранения информации о ваших хостах. Затем вы можете искать хосты по меткам. Дополнительные сведения о поиске см. в разделе Поиск.

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Дополнительные действия (More Actions) (), затем – Назначить метки(Assign Tags).
Установите флажки напротив применимых меток.
Нажмите OK.

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

2. Администрирование ресурсов

2.1. Политики QoS (quality of service - «качество обслуживания»)

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

2.1.1. Политика QoS хранилища

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

2.1.1.1. Создание политики QoS хранилища

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
В разделе Хранилище (Storage), нажмите Новая (New).
Введите Имя QoS (QoS Name) и Описание (Description) для политики QoS.
Укажите QoS для Пропускная способность (Throughput), нажав на одну из кнопок-переключателей:
- Нет (None)
- Всего (Total) - Введите максимальное разрешенное значение общей пропускной способности в поле Мбайт/с (MB/s).
- Чтение/запись (Read/Write) - Введите максимальное разрешенное значение пропускной способности для операций чтения в левом поле Мбайт/с (MB/s) и максимальное разрешенное значение пропускной способности для операций записи в правом поле Мбайт/с (MB/s).
Укажите QoS для операций ввода/вывода (IOps), нажав на одну из кнопок-переключателей:
- Нет
- Всего (Total) - Введите максимальное разрешенное количество операций ввода/вывода в секунду в поле IOps.
- Чтение/запись (Read/Write) - Введите максимальное разрешенное количество операций ввода в секунду в левом поле IOps и максимальное разрешенное количество операций вывода в секунду в правом поле IOps.
Нажмите OK.

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

2.1.1.2. Удаление политики QoS хранилища

Существующую политику QoS хранилища можно удалить.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
Под Хранилищем (Storage) выберите политику QoS хранилища и нажмите Удалить (Remove).
Нажмите OK.

Если какой-либо из профилей дисков был основан на этой политике, то политика QoS хранилища для этих профилей автоматически задается как [unlimited].

2.1.2. Политика QoS сети виртуальных машин

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

2.1.2.1. Создание политики QoS сети виртуальных машин

Политика QoS сети виртуальных машин создается для регулирования сетевого трафика с помощью профиля виртуальной сетевой карты (vNIC).

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
В разделе Сеть ВМ (VM Network) нажмите Новая (New). Откроется окно Новая политика QoS сети (New Network QoS).
Введите Имя (Name) для политики QoS сети виртуальных машин.
Введите ограничения для Входящий (Inbound) и Исходящий (Outbound) сетевого трафика.
Нажмите OK.

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

2.1.2.2. Описание настроек в окнах "Новая политика QoS сети (New Network QoS)" и "Изменить QoS сети (Edit Network QoS)"

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

Таблица 30. Настройки политики QoS сети виртуальных машин
Название поля	Описание
Центр данных (Data Center)	Центр данных, к которому добавляется политика QoS сети виртуальных машин. Данное поле настраивается автоматически в соответствии с выбранным центром данных.
Имя (Name)	Имя, используемое для представления политики QoS сети виртуальных машин в Менеджере.
Входящий (Inbound)	Настройки для применения к входящему трафику. Установите или уберите флажок Входящий (Inbound) для включения или выключения этих настроек. Средняя (Average): Средняя скорость входящего трафика. Максимальная (Peak): Скорость входящего трафика во время пиковых нагрузок. Скачкообразная (Burst): Скорость входящего трафика во время скачков нагрузки.
Исходящий (Outbound)	Настройки для применения к исходящему трафику. Установите или уберите флажок Исходящий (Outbound) для включения или выключения этих настроек. Средняя (Average): Средняя скорость исходящего трафика. Максимальная (Peak): Скорость исходящего трафика во время пиковых нагрузок. Скачкообразная (Burst): Скорость исходящего трафика во время скачков нагрузки.

Чтобы изменить максимальное значение, разрешенное в полях Средняя (Average), Максимальная (Peak) или Скачкообразная (Burst), используйте команду engine-config для изменения значения конфигурационных ключей MaxAverageNetworkQoSValue (по-умолчанию 17179 Мб/с), MaxPeakNetworkQoSValue (по-умолчанию 34359 Мб/с) или MaxBurstNetworkQoSValue (по-умолчанию 10240 Мб/с). Для сохранения изменений перезапустите службу ovirt-engine.

Пример 20. Изменение максимального значения NetworkQoSValue

# engine-config -s MaxAverageNetworkQoSValue=2048
# systemctl restart ovirt-engine

2.1.2.3. Удаление политики QoS сети виртуальных машин

Существующую политику QoS сети виртуальных машин можно удалить.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
Под Сеть ВМ (VM Network) выберите политику QoS сети виртуальных машин и нажмите Удалить (Remove).
Нажмите OK.

2.1.3. Политика QoS сети хоста

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

2.1.3.1. Создание политики QoS сети хоста

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
В разделе Сеть хоста(Host Network), нажмите Новая (New).
Введите Имя QoS (QoS Name) и описание для политики QoS.
Введите необходимые значения для Общие веса (Weighted Share), Ограничение скорости (Мб/с) (Rate Limit) и Подтверждённая скорость (Мб/с) (Committed Rate).
Нажмите OK.

2.1.3.2. Описание настроек в окнах "Новая политика QoS сети хоста (New Host Network Quality of Service)" и "Изменить политику QoS сети хоста (Edit Host Network Quality of Service)"

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

Таблица 31. Настройки политики QoS сети хоста
Название поля	Описание
Центр данных (Data Center)	Центр данных, к которому добавляется политика QoS сети хоста. Данное поле настраивается автоматически в соответствии с выбранным центром данных.
Имя QoS (QoS Name)	Имя, используемое для представления политики QoS сети хоста в Менеджере.
Описание (Description)	Описание политики QoS сети хоста.
Исходящий (Outbound)	Настройки для применения к исходящему трафику. Общие веса (Weighted Share): Означает, какая часть пропускной способности логического канала связи должна быть выделена для конкретной сети относительно других сетей, подключенных к тому же логическому каналу. Точная доля зависит от суммарного количества долей всех сетей на этом канале связи. По умолчанию это число в диапазоне 1-100. Ограничение скорости (Мб/с) (Rate Limit): Максимальная полоса пропускания для использования сетью. Подтверждённая скорость (Мб/с) (Committed Rate): Минимальная полоса пропускания, требуемая для сети. Требуемая Подтверждённая скорость не гарантируется и будет варьироваться в зависимости от сетевой инфраструктуры и Подтверждённой скорости, требуемой для других сетей на том же логическом канале связи.

Чтобы изменить максимальное значение, разрешенное в полях Ограничение скорости (Мб/с) (Rate Limit) или Подтверждённая скорость (Мб/с) (Committed Rate), используйте команду engine-config для изменения значения конфигурационного ключа MaxAverageNetworkQoSValue (по-умолчанию 17179 Мб/с). Для сохранения изменения требуется перезапустить службу ovirt-engine.

Пример 21. Изменение максимального значения NetworkQoSValue

# engine-config -s MaxAverageNetworkQoSValue=2048
# systemctl restart ovirt-engine

2.1.3.3. Удаление политики QoS сети хоста

Политику QoS сети хоста можно удалить.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
Под Сеть хоста (Host Network) выберите политику QoS сети хоста и нажмите Удалить (Remove).
При появлении запроса нажмите OK.

2.1.4. Политика QoS ЦП

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

2.1.4.1. Создание политики QoS ЦП

Создайте политику QoS ЦП

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
Под ЦП (CPU), нажмите Новая (New).
Введите Имя QoS (QoS Name) и Описание (Description) для политики QoS.
Введите в поле Ограничение (%) (Limit (%)) максимальную вычислительную мощность, которая разрешается политикой QoS ЦП. Не вводите символ %.
Нажмите OK.

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

2.1.4.2. Удаление политики QoS ЦП

Политику QoS ЦП можно удалить.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
В разделе ЦП (CPU) выберите политику QoS ЦП и нажмите Удалить (Remove).
Нажмите OK.

Если какой-либо из профилей ЦП был основан на той политике, то политика QoS ЦП для этих профилей автоматически задается как [unlimited].

2.2. Центры данных

2.2.1. Введение в центры данных

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

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

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

Рисунок 12. Центр данных

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

2.2.2. Менеджер пула хранения (SPM)

Менеджер пула хранения (Storage Pool Manager, SPM) – роль, назначаемая одному из хостов центра данных для управления доменами хранения центра данных. SPM может выполняться на любом хосте центра данных, которому менеджер управления назначит эту роль. SPM не мешает стандартной работе хоста: на хосте, работающем как SPM, по-прежнему могут размещаться виртуальные ресурсы.

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

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

2.2.3. Приоритет SPM

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

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

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

На Портале администрирования выберите Ресурсы (Compute) Хосты (Hosts).
Выберите нужный хост и нажмите Изменить (Edit).
Перейдите на вкладку SPM.
Выберите нужный приоритет.
Нажмите OK

2.2.4. Задачи, относящиеся к центрам данных

2.2.4.1. Создание нового центра данных

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

После установки Версии совместимости (Compatibility Version) вы не сможете уменьшить номер версии. Возврат к более старым версиям не поддерживается.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите Новый (New).
Введите Имя (Name) и Описание (Description) центра данных.
В выпадающих меню выберите Тип хранилища (Storage Type), Версия совместимости (Compatibility Version) и Режим квотирования (Quota Mode) для центра данных.
Нажмите OK, чтобы создать центр данных и открыть окно Помощник по созданию Центра данных (Data Center - Guide Me).
Окно Помощник по созданию Центра данных(Data Center - Guide Me) содержит список сущностей, которые нужно сконфигурировать для центра данных. Сконфигурируйте эти сущности или отложите конфигурирование, нажав Настроить позже (Configure Later). Чтобы возобновить конфигурирование, выберите центр данных и нажмите Дополнительные действия (More Actions) (), а затем нажмите Помощник (Guide Me).

Новый центр данных останется в состоянии Неинициализированный (Uninitialized), пока для него не будут сконфигурированы кластер, хост и домен хранения. Чтобы сконфигурировать их, используйте Помощник (Guide Me).

2.2.4.2. Описание настроек в окнах "Новый центр данных (New Data Center)" и "Изменить центр данных (Edit Data Center)"

В приведенной ниже таблице описаны настройки центра данных, отображаемые в окнах Новый центр данных (New Data Center) и Изменить центр данных (Edit Data Center). При нажатии кнопки OK система подсвечивает некорректно введенные значения оранжевым цветом, не давая принять изменения. Кроме того, поля снабжены подсказками, которые указывают ожидаемые значения или диапазон значений.

Таблица 32. Свойства центра данных
Поле	Описание (действие)
Имя (Name)	Имя центра данных. В этом текстовом поле должно быть не больше 40 знаков. Имя должно быть уникальным и представлять собой любую комбинацию латинских букв в верхнем и нижнем регистре, цифр, дефисов и знаков подчеркивания.
Описание (Description)	Описание центра данных. Это поле является рекомендованным, но не обязательным.
Тип хранилища (Storage Type)	Выберите тип хранилища: Общий (Shared) или Локальный (Local). К одному центру данных можно добавлять домены хранения разных типов (iSCSI, NFS, FC, POSIX и Gluster), однако локальные и общие домены нельзя смешивать. После инициализации центра данных тип хранилища можно изменить, подробнее смотри в Изменение типа хранилища центра данных.
Версия совместимости (Compatibility Version)	Версия zVirt. После обновления версии менеджера управления можно оставить прежние версии хостов, кластеров и центров данных. Перед тем как обновлять уровень совместимости (Compatibility Level) центра данных, убедитесь, что обновлены все хосты и затем кластеры.
Режим квотирования (Quota Mode)	Квота – это инструмент ограничения ресурсов, предоставляемый с zVirt. Выберите один из следующих вариантов: Выключено (Disabled): Выберите, чтобы отключить квоту Аудит (Audit): Выберите, чтобы изменить настройки квоты Принудительно (Enforced): Выберите, чтобы включить квоту
Комментарий (Comment)	Необязательный комментарий о центре данных в виде неформатированного текста.

2.2.4.3. Повторная инициализация центра данных: Процедура восстановления

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

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

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers) и выберите центр данных.
Убедитесь, что все домены хранения, подключенные к центру данных, находятся в режиме обслуживания.
Нажмите Дополнительные действия (More Actions) , затем нажмите Переинициализировать центр данных (Re-Initialize Data Center).
В окне Переинициализировать центр данных (Data Center Re-Initialize) перечислены все доступные (отключенные, находящиеся в режиме обслуживания) домены хранения. С помощью кнопки-переключателя выберите домен хранения, который нужно добавить к центру данных.
Установите флажок в поле Подтвердить операцию (Approve operation).
Нажмите OK.

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

2.2.4.4. Удаление центра данных

Для удаления центра данных требуется активный хост. Удаление центра данных не влечет за собой удаления ассоциированных ресурсов.

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

Убедитесь, что домены хранения, подключенные к центру данных, находятся в режиме обслуживания.
Нажмите Ресурсы (Compute) Центры данных (Data Centers) и выберите центр данных, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

2.2.4.5. Принудительное удаление центра данных

Центр данных перейдет в состояние Не отвечает (Non Responsive), если будет поврежден подключенный домен хранения или если хост перейдет в состояние Не отвечает (Non Responsive). В обоих случаях удалить центр данных действием Удалить (Remove) будет невозможно.

Для выполнения действия Удалить принудительно (Force Remove) активный хост не требуется. При этом навсегда удаляется и подключенный домен хранения.

Перед принудительным удалением (Force Remove) центра данных может потребоваться уничтожить (Destroy) поврежденный домен хранения (см. Уничтожение домена хранения)

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers) и выберите центр данных, который нужно удалить.
Нажмите Дополнительные действия (More Actions) , затем – Удалить принудительно (Force Remove).
Установите флажок в поле Подтвердить операцию (Approve operation).
Нажмите ОК.

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

2.2.4.6. Изменение типа хранилища центра данных

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

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

Тип хранилища можно изменить из общего в локальный (Shared to Local) только для центра данных, который содержит один кластер с одним хостом.
Нельзя изменить тип хранилища из локального в общий (Local to Shared) для центра данных, который не содержит локального домена хранения.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers) и выберите центр данных, который нужно изменить.
Нажмите Изменить (Edit).
Измените значение Тип хранилища (Storage Type) на необходимое.
Нажмите OK.

2.2.4.7. Изменение версии совместимости центра данных

У центров данных zVirt есть версия совместимости (для zVirt 3.2 - будет версия 4.6). Все кластеры в таком центре данных должны поддерживать требуемый уровень совместимости.

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

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

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

На портале администрирования нажмите Ресурсы (Compute) Центры данных (Data Centers).
Выберите центр данных, который нужно изменить, и нажмите Изменить (Edit).
Измените значение Версия совместимости (Compatibility Version) на необходимое.
Нажмите OK. Откроется диалог подтверждения Изменить версию совместимости центра данных (Change Data Center Compatibility Version).
Нажмите OK для подтверждения.

2.2.5. Центры данных и домены хранения

2.2.5.1. Подключение существующего домена данных к центру данных

Откреплённые (Unattached) домены данных можно подключить к центру данных. К одному центру данных можно добавлять общие домены хранения разных типов (iSCSI, NFS, FC, POSIX и Gluster).

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Хранилище (Storage), чтобы увидеть список доменов хранения, уже подключенные к центру данных.
Нажмите Прикрепить домен данных (Attach Data).
Установите флажок для домена данных, который нужно подключить к центру данных. Можно установить несколько флажков, чтобы подключить несколько доменов данных.
Нажмите OK.

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

2.2.5.2. Подключение существующего домена ISO к центру данных

Откреплённый (Unattached) домен ISO можно подключить к центру данных. Домен ISO должен иметь такой же Тип хранилища (Storage Type), что и центр данных.

К центру данных можно подключить только один домен ISO.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Хранилище (Storage), чтобы увидеть список доменов хранения, уже подключенных к центру данных.
Нажмите Прикрепить ISO-домен (Attach ISO).
Выберите соответствующий домен ISO кнопкой-переключателем.
Нажмите OK.

Домен ISO подключен к центру данных и автоматически активирован.

2.2.5.3. Подключение существующего домена экспорта к центру данных

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

Откреплённый (Unattached) домен экспорта можно подключить к центру данных. К центру данных можно подключить только один домен экспорта.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Хранилище (Storage), чтобы увидеть список доменов хранения, уже подключенных к центру данных.
Нажмите Прикрепить экспорт-домен (Attach Export).
Выберите соответствующий домен экспорта кнопкой-переключателем.
Нажмите OK.

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

2.2.5.4. Отключение домена хранения от центра данных

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

Данные (такие как виртуальные машины и шаблоны) остаются подключенными к домену хранения.

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

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Хранилище (Storage), чтобы увидеть список доменов хранения, подключенных к центру данных.
Выберите домен хранения, который нужно отключить. Если домен хранения Активен (Active), нажмите Обслуживание (Maintenance).
Нажмите OK, чтобы перейти в режим обслуживания.
Нажмите Отсоединить (Detach).
Нажмите OK.

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

2.3. Кластеры

2.3.1. Введение в кластеры

Кластер – логическая группа хостов с общими доменами хранения и ЦП одного типа (Intel или AMD). Если модели ЦП хостов относятся к разным поколениям, то используются только те функции, которые присутствуют во всех моделях.

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

Количество хостов и количество виртуальных машин, относящихся к кластеру, отображаются в списке результатов поиска как Количество хостов (Host Count) и Количество ВМ (VM Count) соответственно.

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

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

Рисунок 13. Кластер

2.3.2. Задачи, относящиеся к кластеру

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

2.3.2.1. Создание нового кластера

Центр данных может содержать несколько кластеров, а кластер может содержать несколько хостов. Все хосты в кластере должны иметь одинаковую архитектуру ЦП. Чтобы оптимизировать типы ЦП, создавайте хосты до создания кластера. После создания кластера хосты можно сконфигурировать, нажав кнопку Помощник (Guide Me).

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите Новый (New).
В выпадающем списке выберите Центр данных (Data Center), к которому будет относиться кластер.
В поле Имя (Name) введите имя кластера.
В поля Описание (Description) и Комментарий (Comment) введите описание кластера и, при необходимости добавьте комментарий.
В выпадающем списке Сеть управления (Management Network) выберите сеть, чтобы назначить роль сети управления.
Выберите Архитектура ЦП (CPU Architecture). При выборе x86_64 разблокируется выбор Тип чипсета/ПО (Chipset/Firmware Type).
В качестве Типа ЦП (CPU Type) выберите самое старое семейство ЦП среди хостов, которые войдут в кластер. Типы ЦП перечисляются от самого старого к самому новому.
В выпадающем списке выберите Тип чипсета/ПО (Chipset/Firmware Type) для создаваемых виртуальных машин и шаблонов в кластере.
Установите флажок Изменить существующие ВМ/шаблоны с чипсетом I440fx на чипсет Q35 с BIOS (Change existing VMs/Templates from I440fx to Q35 Chipset with BIOS) при необходимости.
В выпадающем списке выберите Режим FIPS (FIPS Mode) кластера.
В выпадающем списке выберите Версию совместимости (Compatibility Version) кластера.
В выпадающем списке выберите Тип коммутатора (Switch Type).
Выберите Тип межсетевого экрана (Firewall Type) для хостов в кластере: Firewalld (по умолчанию) или iptables.
В выпадающем списке выберите Провайдер сети по умолчанию (Default Network Provider)
Установите Максимальный порог памяти логирования (Maximum Log Memory Threshold)
Установите флажок Включить службу Virt (Enable Virt Service) или Включить службу Gluster (Enable Gluster Service), чтобы указать, будет ли кластер заполняться хостами с виртуальными машинами или узлами с включенной службой Gluster.
При желании можно установить флажок Дополнительный источник генератора случайных чисел /dev/hwrng (Additional Random Number Generator source: /dev/hwrng source), чтобы указать аппаратный генератор случайных чисел, который будут использовать все хосты кластера. Устройство /dev/urandom source (предоставлено операционной системой Linux) включено по умолчанию.
Откройте вкладку Оптимизация (Optimization), чтобы выбрать пороговое значение для совместного использования страницы памяти в кластере, а также при желании включите управление потоками ЦП, динамическое распределение памяти (memory ballooning), совместное использование памяти и выберите механизм её распределения на хостах кластера.
Откройте вкладку Политика миграции (Migration Policy), чтобы определить политику миграции виртуальных машин в кластере.
Откройте вкладку Политика планирования (Scheduling Policy), чтобы при желании настроить политику планирования и оптимизировать планировщик, включить доверенную службу для хостов кластера и резервирование высокой доступности (HA Reservation), а также выбрать политику серийных номеров.
Откройте вкладку Консоль (Console), чтобы при желании переопределить глобальный SPICE-прокси (если он есть) и задать адрес SPICE-прокси для хостов кластера.
Откройте вкладку Политика ограничения (Fencing policy), чтобы включить или выключить ограничение (изоляцию) в кластере, а также выберите опции, отвечающие за ограничение (изоляцию).
Откройте вкладку Пул MAC-адресов (MAC Address Pool), чтобы указать пул MAC-адресов, отличный от заданного по умолчанию для кластера. Дополнительные сведения о способах создания, изменения или удаления пулов MAC-адресов см. в разделе Пулы MAC-адресов.
Нажмите OK, чтобы создать кластер и открыть окно Помощник по созданию кластера (Cluster - Guide Me).
Окно Помощник (Guide Me) содержит список сущностей, которые нужно сконфигурировать для кластера. Сконфигурируйте эти сущности или отложите конфигурирование, нажав Настроить позже (Configure Later). Чтобы возобновить конфигурирование, выберите кластер и нажмите Дополнительные действия (More Actions) , а затем нажмите Помощник (Guide Me).

Хосты, у которых семейство ЦП старше указанного в поле Тип ЦП (CPU Type), не могут стать частью этого кластера.

Open vSwitch (OVS) - представлен для ознакомления. Функционал экспериментальный, в продуктивной среде использовать не рекомендуется, техническая поддержка не оказывается

Добавлять хосты можно только к кластерам с типом межсетевого экрана firewalld.

2.3.2.2. Описание общих настроек кластера

В приведенной ниже таблице описаны настройки вкладки Общее (General) в окнах Новый кластер (New Cluster) и Изменить кластер (Edit Cluster). При нажатии кнопки OK система подсвечивает некорректно введенные значения оранжевым цветом, не давая принять изменения. Кроме того, поля снабжены подсказками, которые указывают ожидаемые значения или диапазон значений.

Таблица 33. Общие настройки кластера
Поле	Описание/действие
Центр данных (Data Center)	Центр данных, в котором будет содержаться кластер. Центр данных должен быть создан до добавления кластера.
Имя (Name)	Имя кластера. В этом текстовом поле должно быть не больше 40 знаков. Имя должно быть уникальным и представлять собой любую комбинацию латинских букв в верхнем и нижнем регистре, цифр, дефисов и знаков подчеркивания.
Описание/комментарий (Description/Comment)	Описание кластера или дополнительные примечания. Эти поля являются рекомендованными, но не обязательными.
Сеть управления (Management Network)	Логическая сеть, которой будет назначена роль сети управления. По умолчанию – ovirtmgmt. Эта сеть также будет использоваться для миграции виртуальных машин, если сеть миграции не подключена к хосту-источнику или хосту-приемнику. В существующих кластерах сеть управления можно изменить, только нажав кнопку Управление сетями (Manage Networks) на вкладке Логические сети (Logical Networks) в подробном представлении.
Архитектура ЦП (CPU Architecture)	Архитектура ЦП кластера. Все хосты в кластере должны иметь указанную архитектуру. В зависимости от выбранной архитектуры ЦП доступны различные типы ЦП. не определено (undefined): все остальные типы ЦП. x86_64: ЦП типа Intel и AMD. ppc64: ЦП типа IBM POWER. s390x* ЦП типа IBM s390/z
Тип ЦП (CPU Type)	Самое старое семейство ЦП в кластере. Список типов ЦП приведен в разделе Требования к ЦП в Руководстве по планированию и требованиям (Planning and Prerequisites Guide). Его изменение после создания кластера приведет к серьезному нарушению работы. Установите тип ЦП, ориентируясь на самую старую модель ЦП хоста в кластере. Использоваться могут только те функции, которые есть во всех моделях. Для ЦП типа Intel и AMD модели ЦП перечисляются в логическом порядке от самой старой к самой новой.
Версия совместимости (Compatibility Version)	Для zVirt 3.2 - 4.6. Нельзя выбрать более раннюю версию, чем та, что указана для центра данных.
Тип коммутатора (Switch Type)	Тип коммутатора, используемого кластером. Мост (Linux Bridge) – стандартный коммутатор zVirt. Open vSwitch (OVS)– обеспечивает экспериментальную поддержку сетевых функций Open vSwitch.
Тип межсетевого экрана (Firewall Type)	Указывает тип межсетевого экрана для хостов в кластере: Firewalld (по умолчанию) или iptables. Добавлять хосты можно только к кластерам с типом межсетевого экрана firewalld.
Провайдер сети по умолчанию (Default Network Provider)	Указывает внешнего поставщика сети по умолчанию, которого будет использовать кластер. Если выбрать ovirt-provider-ovn, то хосты, добавляемые в кластер, автоматически будут настраиваться на взаимодействие через поставщика OVN. Изменение поставщика сети по умолчанию потребует переустановки всех хостов в кластере для того, чтобы изменения вступили в силу.
Максимальный порог памяти логирования (Maximum Log Memory Threshold)	Задает пороговое значение максимального потребления памяти (в процентах или в виде абсолютной величины в МБ), факт достижения которого вносится в журнал. Сообщение вносится в журнал, если использование памяти хоста превышает это процентное значение или если объем доступной памяти хоста падает ниже абсолютного значения в МБ. Значение по умолчанию – 95%.
Включить службу Virt (Enable Virt Service)	При нажатии кнопки-переключателя хосты в этом кластере будут использоваться для запуска виртуальных машин.
Включить службу Gluster (Enable Gluster Service)	При нажатии кнопки-переключателя хосты в этом кластере будут использоваться в качестве узлов серверов хранения zVirt, а не для запуска виртуальных машин.
Импорт существующей конфигурации Gluster (Import existing gluster configuration)	Этот флажок можно установить, только если отмечена кнопка-переключатель Включить службу Gluster (Enable Gluster Service). Эта опция позволяет импортировать существующий кластер с поддержкой Gluster и все подключенные к нему хосты в менеджер управления. Следующие параметры необходимы для каждого хоста в импортируемом кластере: Адрес (Address): Введите IP-адрес или FQDN хост-сервера Gluster. Публичный ключ SSH хоста (Host ssh public key (PEM)): позволяет обратиться к хосту без пароля и убедиться, что вы подключаетесь к правильному хосту. Пароль (Password): Введите root-пароль, необходимый для взаимодействия с хостом.
Дополнительный источник - генератор случайных чисел (Additional Random Number Generator source)	Если этот флажок установлен, то для всех хостов в кластере доступно дополнительное устройство - генератор случайных чисел. Это способствует распространению энтропии от генератора случайных чисел к виртуальным машинам.

2.3.2.3. Описание настроек оптимизации

Пояснения относительно памяти

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

Пояснения относительно ЦП

Для процессов, не очень сильно загружающих ЦП, можно запускать виртуальные машины с общим количеством процессорных ядер, превышающим количество ядер хоста. Плюсы такого подхода следующие:
- Можно запускать большее количество виртуальных машин, что снижает требования к оборудованию.
- Это также позволяет конфигурировать виртуальные машины с топологиями ЦП, которые иначе были бы невозможны – например, когда количество виртуальных ядер находится в диапазоне между количеством ядер хоста и количеством потоков хоста.
Для достижения наилучшей производительности и особенно для процессов, сильно загружающих ЦП, на виртуальной машине следует использовать ту же топологию, что и на хосте, чтобы и для хоста, и для виртуальной машины ожидаемая работа кэша была одинаковой. Когда на хосте включена гиперпоточность, QEMU-процесс трактует гиперпотоки (hyperthreads) хоста как ядра, поэтому виртуальная машина не знает, что она работает на одном ядре с несколькими потоками. Такое поведение может повлиять на производительность виртуальной машины, поскольку виртуальное ядро, которое фактически соответствует гиперпотоку (hyperthread) в ядре хоста, может использовать один и тот же кэш вместе с другим гиперпотоком в том же ядре хоста, в то время как виртуальная машина трактует его как отдельное ядро.

В приведенной ниже таблице описаны настройки вкладки Оптимизация (Optimization) окон Новый кластер (New Cluster) и Изменить кластер (Edit Cluster).

Таблица 34. Настройки оптимизации
Поле	Описание/действие
Оптимизация памяти (Memory Optimization)	Выключить перераспределение памяти (None - Disable memory overcommit): Отключает совместное использование страниц памяти. Для серверной нагрузки - разрешить перераспределение физической памяти на 150% от системной памяти на каждом хосте (For Server Load - Allow scheduling of 150% of physical memory): Устанавливает порог совместного использования страницы памяти в значение, равное 150% от объема системной памяти на каждом хосте. Для нагрузки рабочей станции - разрешить перераспределение физической памяти на 200% от системной памяти на каждом хосте (For Desktop Load - Allow scheduling of 200% of physical memory): Устанавливает порог совместного использования страницы памяти в значение, равное 200% от объема системной памяти на каждом хосте.
Симметричная многопоточность (Symmetric Multithreading)	Позволяет отключить использование гиперпоточности в ЦП (hyperhreading). При этом следующая опция Потоки ЦП (CPU Threads) становится недоступной
Потоки ЦП (CPU Threads)	Установка флажка Считать потоки как ядра (Count Threads As Cores) позволяет хостам обеспечить работу виртуальных машин с общим количеством процессорных ядер, превышающим количество ядер хоста. Если этот флажок установлен, открытые потоки хостов трактуются как ядра, которые виртуальные машины могут использовать. Например, 24-ядерная система с 2 потоками на ядро (всего 48 потоков) может запускать виртуальные машины, каждая из которых содержит до 48 ядер, а алгоритмы расчета загрузки ЦП хоста будут сравнивать нагрузку с удвоенным количеством потенциально используемых ядер.
Динамическое выделение памяти (Memory Balloon)	Если установлен флажок Включить оптимизацию динамического выделения памяти (Enable Memory Balloon Optimization), то на виртуальных машинах, работающих на хостах в этом кластере, становится возможным выделение памяти в объеме, превышающем физически доступный (memory overcommitment). Когда этот флажок установлен, менеджер избыточного выделения памяти (Memory Overcommit Manager, MoM) начинает применять динамическое выделение памяти во всех возможных ситуациях, при этом каждой виртуальной машине будет предоставлен как минимум тот гарантированный объем памяти, который был указан при её создании. Для динамического выделения памяти виртуальная машина должна иметь устройство balloon с соответствующими драйверами. Каждая виртуальная машина включает в себя такое устройство по умолчанию, если только оно не было удалено специально. Каждый хост в этом кластере получает обновление политики динамического выделения памяти, когда его статус меняется на Включен (Up). При необходимости вы можете вручную обновить политику динамического выделения памяти на хосте, не меняя статус. Смотрите Обновление политики Менеджера избыточного выделения памяти (MoM) на хостах в кластере. Важно понимать, что в некоторых сценариях динамическое выделение памяти (ballooning) может вступать в конфликт с объединением одинаковых страниц памяти (KSM). В таких случаях Менеджер избыточного выделения памяти (MoM) будет пытаться скорректировать объем выделения памяти (ballooning), чтобы минимизировать конфликты. Кроме того, в ряде сценариев динамическое выделение памяти может привести к тому, что производительность для виртуальной машины будет неоптимальной. Администраторам рекомендуется с осторожностью использовать данную опцию в целях оптимизации.
Управление KSM	Если выбрана опция Включить KSM (Enable KSM), то MoM может запустить KSM, когда это необходимо и может дать экономию памяти, выгода от которой перевешивает затраты на ЦП.

2.3.2.4. Описание настроек политик миграции

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

Таблица 35. Описание настроек политик миграции

Политика

Описание

Значение по умолчанию для кластера - «Минимальный простой» (Minimal downtime)

Переопределение в vdsm.conf по-прежнему применимо. Гостевой хук-механизм выключен.

Минимальный простой (Minimal downtime)

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

Миграция после копирования (Post-copy migration)

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

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

Приостановка при необходимости (Suspend workload if needed)

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

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

Таблица 36. Описание полосы пропускания
Политика	Описание
Авто (Auto)	Полоса пропускания копируется из настройки Ограничение скорости (Мбит/с) (Rate Limit (Mbps)) в политике QoS сети хоста (Host Network QoS) в центре данных. Если ограничение скорости не установлено, то оно рассчитывается как минимальное значение скорости соединения отправляющего и принимающего сетевых интерфейсов. Если ограничение скорости не установлено, а скорости каналов недоступны, то оно определяется локальной настройкой Менеджера виртуальных рабочих мест и серверов (VDSM) на отправляющем хосте.
Гипервизор (по умолчанию) (Hypervisor default)	Полоса пропускания контролируется локальной настройкой VDSM на хосте-источнике.
Пользовательский (Custom)	Задается пользователем (в Мбит/с). Это значение делится на количество одновременных миграций (по умолчанию 2, чтобы учесть входящие и исходящие миграции). Поэтому заданная пользователем полоса пропускания должна быть достаточно большой, чтобы вместить все одновременные миграции. Например, если Пользовательская (Custom) полоса пропускания задана в размере 600 Мбит/с, то максимальная полоса пропускания при миграции виртуальной машины на самом деле составляет 300 Мбит/с.

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

Таблица 37. Настройки политики отказоустойчивости
Поле	Описание/действие
Мигрировать ВМ (Migrate Virtual Machines)	Переносятся все виртуальные машины в заданном порядке приоритетности.
Мигрировать только ВМ в режиме высокой доступности (Migrate only Highly Available Virtual Machines)	Переносятся только виртуальные машины с признаком высокой доступности, чтобы предотвратить перегрузку других хостов.
Не мигрировать виртуальные машины (Do Not Migrate Virtual Machines)	Не дает переносить виртуальные машины.

2.3.2.5. Описание настроек политик планирования

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

Поле Описание/действие

Выбор политики

Выберите политику из выпадающего списка.

Не назначена (none): Балансировка нагрузки или распределение питания между хостами для уже работающих виртуальных машин выключены. Этот режим выбран по умолчанию. Когда виртуальная машина запущена, ресурсы памяти и загрузка ЦП равномерно распределяются между всеми хостами в кластере. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если параметры CpuOverCommitDurationMinutes, HighUtilization или MaxFreeMemoryForOverUtilized этого хоста достигли заданных значений.
Равномерное распределение (evenly_distributed): Распределяет нагрузку на оперативную память и ЦП равномерно между всеми хостами в кластере. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если параметры CpuOverCommitDurationMinutes, HighUtilization или MaxFreeMemoryForOverUtilized этого хоста достигли заданных значений.
Обслуживание кластера (cluster_maintenance): Ограничивает активность в кластере во время выполнения задач технического обслуживания. Нельзя запускать новые виртуальные машины, кроме виртуальных машин с признаком высокой доступности. В случае отказа хоста виртуальные машины с признаком высокой доступности перезапустятся в установленном порядке, и любая виртуальная машина сможет смигрировать.
Энергосбережение (power_saving): Распределяет загрузку ОЗУ и ЦП по подмножеству доступных хостов, чтобы снизить энергопотребление на недогруженных хостах. Если на некоторых хостах загрузка ЦП находится ниже нижнего значения загрузки дольше заданного интервала времени, то, чтобы их питание можно было отключить, все виртуальные машины переносятся с них на другие хосты. Дополнительные виртуальные машины, подключенные к хосту, не запустятся, если загрузка этого хоста достигла заданного верхнего значения загрузки.
Равномерное распределение ВМ (vm_evenly_distributed): Распределяет виртуальные машины равномерно между хостами, исходя из количества виртуальных машин. Кластер считается несбалансированным, если на любом из хостов запущено больше виртуальных машин, чем указано в параметре HighVmCount, и есть хотя бы один хост, количество виртуальных машин на котором выходит за предельное значение параметра MigrationThreshold.

Свойства

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

HighVmCount: Устанавливает минимальное количество виртуальных машин, которые должны работать на одном хосте для активизации балансировки нагрузки. По умолчанию это 10 работающих виртуальных машин на хост. Балансировка нагрузки будет включена, если хотя бы на одном хосте в кластере будет достигнуто значение параметра HighVmCount по количеству работающих виртуальных машин.
MigrationThreshold: Определяет "буфер" перед переносом виртуальных машин с хоста. Это максимальная разница (включительно) между количеством виртуальных машин на наиболее загруженном и наименее загруженном хостах. Кластер сбалансирован, если для каждого хоста в кластере количество виртуальных машин не выходит за пределы диапазона миграции. Значение по умолчанию – 5.
SpmVmGrace: Определяет количество слотов для виртуальных машин, которые должны быть зарезервированы на хостах SPM. Загрузка на хосте SPM будет ниже, чем на других хостах, т.е. эта переменная определяет, насколько меньше виртуальных машин может работать на хосте SPM по сравнению с другими хостами. Значение по умолчанию – 5.
CpuOverCommitDurationMinutes: Задает время (в минутах), в течение которого хост может работать при загрузке ЦП, выходящей за заданные значения, прежде чем вступит в действие политика планирования. Этот интервал времени позволяет избежать активации политики планирования и ненужной миграции виртуальных машин при временных скачках загрузки ЦП. Максимум два знака. Значение по умолчанию – 2.
HighUtilization: Выражается в процентах. Если в течение заданного интервала времени хост загружает ЦП на уровне верхнего предела загрузки или выше, то Менеджер управления будет переносить виртуальные машины на другие хосты кластера до тех пор, пока загрузка ЦП этого хоста не опустится ниже максимального порога. Значение по умолчанию – 80. Значение не может быть меньше 50 или больше 99.
LowUtilization: Выражается в процентах. Если в течение заданного интервала времени хост загружает ЦП на уровне ниже нижнего предела загрузки, то Менеджер управления будет переносить виртуальные машины на другие хосты кластера. Менеджер управления отключит питание на исходном хосте и перезапустит его снова, когда того потребует балансировка нагрузки или когда в кластере не будет достаточно свободных хостов. Значение по умолчанию – 20. Значение не может быть больше 49.
ScaleDown: Уменьшает влияние весовой функции Резервирование высокой доступности (HA Reservation) методом деления оценки хоста на указанную величину. Это необязательное свойство, которое может быть добавлено в любую политику, включая политику Не назначена (none).
HostsInReserve: Указывает количество хостов, которые должны продолжать работать, даже если на них нет запущенных виртуальных машин. Это необязательное свойство, которое может быть добавлено к политике Энергосбережение (power_saving).
EnableAutomaticHostPowerManagement: Включает автоматическое управление питанием на всех хостах в кластере. Это необязательное свойство, которое может быть добавлено к политике Энергосбережение (power_saving). Значение по умолчанию – верно (true).
MaxFreeMemoryForOverUtilized: Указывает минимальный объем свободной оперативной памяти, обязательный для хоста, в МБ. Если объем свободной оперативной памяти на хосте меньше указанного, то Менеджер управления считает хост перегруженным. Например, если установить для этого свойства значение 1 000, то хост, у которого меньше 1 ГБ свободной оперативной памяти, будет перегружен.

Подробнее о том, как это свойство работает с политиками Энергосбережение (power_saving) и Равномерное распределение (evenly_distributed), см. в Разделе Свойства политики планирования в кластере MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized.

Это свойство можно добавить к политикам Энергосбережение (power_saving) и Равномерное распределение (evenly_distributed). Хотя оно появляется в списке свойств для политики Равномерное распределение ВМ (vm_evenly_distributed), оно не применяется к ней.
MinFreeMemoryForUnderUtilized: Указывает максимальный объем свободной оперативной памяти в МБ, который будет у хоста. Если объем свободной оперативной памяти на хосте больше указанного, то Менеджер управления считает, что хост недогружен. Например, если для этого параметра установить значение 10 000, то хост, у которого больше 10 ГБ свободной оперативной памяти, будет недогружен.

Подробнее о том, как это свойство работает с политиками Энергосбережение (power_saving) и Равномерное распределение (evenly_distributed) см. в Разделе Свойства политики планирования в кластере MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized.

Это свойство можно добавить к политикам Энергосбережение (power_saving) и Равномерное распределение (evenly_distributed). Хотя оно появляется в списке свойств для политики Равномерное распределение ВМ (vm_evenly_distributed), оно не применяется к ней.
HeSparesCount: Устанавливает количество дополнительных узлов с ролью hosted engine, которые должны зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Другим виртуальным машинам запрещено запускаться на узле с ролью hosted engine, если из-за этого не останется достаточно свободной оперативной памяти для виртуальной машины c Менеджером управления. Это необязательное свойство, которое может быть добавлено к политикам Энергосбережение (power_saving), Равномерное распределение ВМ (vm_evenly_distributed) и Равномерное распределение (evenly_distributed) Значение по умолчанию – 0.

Оптимизация планировщика (Scheduler Optimization)

Оптимизируйте планирование для взвешивания/упорядочивания хостов.

Оптимизировать для загрузки (Optimize for Utilization): Включает модули взвешивания в процесс планирования для обеспечения наилучшего выбора.
Оптимизировать для скорости (Optimize for Speed): Пропускает взвешивание хостов в случаях, когда имеется более десяти ожидающих запросов.

Включить доверенную службу (Enable Trusted Service)

Активирует интеграцию с сервером OpenAttestation. Прежде чем ее можно будет включить, введите сведения о сервере OpenAttestation с помощью инструмента engine-config.

Сервер OpenAttestation и технология Intel Trusted Execution Technology (Intel TXT) больше недоступны.

Включить контроль емкости для высокодоступных ВМ (Enable HA Reservation)

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

Политика серийных номеров (Serial Number Policy)

Конфигурация политики присвоения серийных номеров каждой новой виртуальной машине в кластере:

Значение по умолчанию для системы (System Default): Использует общесистемные значения по умолчанию в базе данных Менеджера управления. Для конфигурирования этих значений по умолчанию, используйте инструмент конфигурации механизма, чтобы установить значения DefaultSerialNumberPolicy и DefaultCustomSerialNumber. Эти пары ключ-значение сохраняются в таблице vdc_options в базе данных Менеджера управления.
Для политики DefaultSerialNumberPolicy
Значение по умолчанию: HOST_ID

Возможные значения: HOST_ID, VM_ID, CUSTOM

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

engine-config --set DefaultSerialNumberPolicy=VM_ID

Перезапустите Менеджер управления для применения настроек.
Для DefaultCustomSerialNumber
Значение по умолчанию: Фиктивный серийный номер. Возможные значения: Любая строка (ограничение: максимум 255 знаков)

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

engine-config --set DefaultCustomSerialNumber="My very special string value"

Перезапустите Менеджер управления для применения настроек.
Идентификатор хоста (Host ID): Устанавливает серийный номер каждой новой виртуальной машины в значение, соответствующее UUID хоста.
Идентификатор ВМ (Vm ID): Устанавливает серийный номер каждой новой виртуальной машины в значение, соответствующее UUID виртуальной машины.
Пользовательский серийный номер (Custom serial number): Устанавливает серийный номер каждой новой виртуальной машины в значение, которое вы задаете в параметре Пользовательский серийный номер (Custom Serial Number).

Пользовательский серийный номер (Custom serial number)

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

Когда свободная память хоста падает ниже 20%, такие команды балунинга памяти как

mom.Controllers.Balloon - INFO Ballooning guest:half1 from 1096400 to 1991580

записываются в журнал /var/log/vdsm/mom.log.

/Var/log/vdsm/mom.log – это файл журнала Менеджера избыточного выделения памяти.

2.3.2.6. Свойства политики планирования в кластере MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized

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

Ниже описано, как политики планирования в кластере Равномерное распределение (evenly_distributed) и Энергосбережение (power_saving) взаимодействуют со свойствами MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized. Хотя обе политики учитывают загрузку ЦП и памяти, загрузка ЦП не имеет отношения к свойствам MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized.

Если вы зададите свойства MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized как часть политики равномерного распределения (evenly_distributed):

Хосты, которые имеют меньше свободной памяти, чем MaxFreeMemoryForOverUtilized, являются перегруженными и становятся хостами-источниками.
Хосты, которые имеют больше свободной памяти, чем MinFreeMemoryForUnderUtilized, являются недогруженными и становятся хостами-приемниками.
Если значение MaxFreeMemoryForOverUtilized не указано, то планировщик не переносит виртуальные машины, исходя из загрузки памяти. (Он продолжает переносить виртуальные машины, исходя из других критериев политики, таких как загрузка ЦП.)
Если значение MinFreeMemoryForUnderUtilized не указано, то планировщик считает, что все хосты могут становиться хостами-приемниками.

Если вы зададите свойства MaxFreeMemoryForOverUtilized и MinFreeMemoryForUnderUtilized как часть политики Энергосбережение (power_saving):

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

Дополнительные ресурсы
Описание настроек политик планирования

2.3.2.7. Описание настроек консоли кластера

В приведенной ниже таблице описаны настройки вкладки Консоль (Console) в окнах Новый кластер (New Cluster) и Изменить кластер (Edit Cluster).

Таблица 39. Настройки консоли
Поле	Описание/действие
Перезаписать адрес SPICE-прокси (Overridden SPICE proxy address)	Поставьте флажок в это поле, чтобы переопределить SPICE-прокси, заданный в глобальной конфигурации. Эта функция полезна, когда пользователь (например, подключающийся через Пользовательский портал) располагается вне сети, в которой находятся гипервизоры.
Задать адрес SPICE-прокси для кластера (Define SPICE Proxy for Cluster)	Прокси-сервер, посредством которого клиент SPICE соединяется с виртуальными машинами. Адрес должен быть задан в следующем формате: `protocol://[host]:[port]`

2.3.2.8. Описание настроек политик ограничения

В приведенной ниже таблице описаны настройки вкладки Политика ограничения (Fencing Policy) в окнах Новый кластер (New Cluster) и Изменить кластер (Edit Cluster).

Таблица 40. Настройки политик ограничения
Поле	Описание/действие
Включить ограничения (Enable fencing)	Включает изоляцию в кластере. Изоляция включена по умолчанию, но при необходимости ее можно выключить: например, если возникают или ожидаются временные проблемы в работе сети, администраторы могут отключить изоляцию до завершения диагностики или обслуживания. Внимание! Если изоляция выключена, виртуальные машины с признаком высокой доступности, работающие на хостах, находящихся в состоянии "не отвечает", не будут перезапущены где-либо еще.
Пропустить ограничение, если хост имеет аренду на хранилище (Skip fencing if host has live lease on storage)	Если этот флажок установлен, то никакие хосты в кластере, которые находятся в состоянии "не отвечает" и все еще подключены к хранилищу, не будут изолироваться.
Пропустить ограничение при проблемах подключения кластера (Skip fencing on cluster connectivity issues)	Когда этот флажок установлен, изоляция будет временно выключена, если процент хостов в кластере, испытывающих проблемы со связью, больше или равен заданному значению Threshold. Значение Threshold выбирается из следующего выпадающего списка: 25, 50, 75 и 100.
Пропустить ограничение, если блоки Gluster активны (Skip fencing if gluster bricks are up)	Эта опция доступна только при включенной функции Gluster Storage. Когда этот флажок установлен, изоляция пропускается, если брики работают и доступны с других узлов того же ранга.
Пропустить ограничение, если кворум Gluster не соблюден (Skip fencing if gluster quorum not met)	Эта опция доступна только при включенной функции Gluster Storage. Когда этот флажок установлен, изоляция пропускается, если брики работают и выключение хоста вызовет потерю кворума.

2.3.2.9. Задание политик управления загрузкой и питанием для хостов в кластере

Политики планирования Равномерное распределение (evenly_distributed) и Энергосбережение (power_saving) позволяют задавать приемлемые значения загрузки ОЗУ и ЦП, а также момент, в который виртуальные машины нужно переносить на хост или с хоста. Политика планирования Равномерное распределение ВМ (vm_evenly_distributed) распределяет виртуальные машины равномерно между хостами, исходя из количества виртуальных машин. Задайте политику планирования, чтобы включить автоматическую балансировку нагрузки между хостами в кластере. Подробное описание каждой из политик планирования см. в разделе Описание настроек политик планирования.

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

Нажмите Ресурсы (Compute) Кластеры (Clusters) и выберите кластер.
Нажмите Изменить (Edit).
Откройте вкладку Политика планирования (Scheduling Policy).
Выберите одну из следующих политик:
- none
- vm_evenly_distributed
  1. Чтобы включить балансировку нагрузки, в поле HighVmCount укажите минимальное количество виртуальных машин, которое должно быть запущено хотя бы на одном хосте.
  2. В поле MigrationThreshold задайте максимальную допустимую разницу между количеством виртуальных машин на наиболее загруженном и наименее загруженном хостах.
  3. В поле SpmVmGrace укажите количество слотов для виртуальных машин, которое должно быть зарезервировано на хостах SPM.
  4. При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в разделе Настройка слотов памяти, резервируемых для узлов hosted engine на дополнительных хостах.
- evenly_distributed
  1. В поле CpuOverCommitDurationMinutes укажите время (в минутах), в течение которого хост может работать при загрузке ЦП, выходящей за заданные значения, прежде чем вступит в действие политика планирования.
  2. В поле HighUtilization укажите процент загрузки ЦП, при котором начинается миграция виртуальных машин на другие хосты.
  3. При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в разделе Настройка слотов памяти, резервируемых для узлов hosted engine на дополнительных хостах.
- power_saving
  1. В поле CpuOverCommitDurationMinutes укажите время (в минутах), в течение которого хост может работать при загрузке ЦП, выходящей за заданные значения, прежде чем вступит в действие политика планирования.
  2. В поле LowUtilization укажите процент загрузки ЦП, ниже которого хост будет считаться недогруженным.
  3. В поле HighUtilization укажите процент загрузки ЦП, при котором начинается миграция виртуальных машин на другие хосты.
  4. При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в разделе Настройка слотов памяти, резервируемых для узлов hosted engine на дополнительных хостах.
В качестве Оптимизации расписания (Scheduler Optimization) выберите для кластера одно из следующих значений:
- Оптимизировать для утилизации (Optimize for Utilization), чтобы включить модули взвешивания в процесс планирования для обеспечения наилучшего выбора.
- Оптимизировать для скорости (Optimize for Speed), чтобы пропустить взвешивание хостов в случаях, когда имеется более десяти ожидающих запросов.
Если для верификации хостов используется сервер OpenAttestation и сведения о сервере заданы с помощью инструмента engine-config, то установите флажок Включить Trusted Service (Enable Trusted Service).

Сервер OpenAttestation и технология Intel Trusted Execution Technology (Intel TXT) больше недоступны.
При желании установите флажок в поле Включить резервирование ресурсов для высокодоступных ВМ (Enable HA Reservation), чтобы Менеджер управления отслеживал ресурсы кластера для виртуальных машин с признаком высокой доступности.
При желании выберите Политику серийных номеров (Serial Number Policy) для виртуальных машин в кластере:
- Значение по умолчанию (System Default): Используйте системные значения по умолчанию, которые настраиваются в базе данных Менеджера управления с помощью инструмента настройки узла engine, и имена ключей DefaultSerialNumberPolicy и DefaultCustomSerialNumber. Значение по умолчанию для DefaultSerialNumberPolicy – это использовать ID хоста (Host ID). Дополнительную информацию см. в разделе Политики планирования в Руководстве по администрированию.
- Хост ID (Host ID): Установите серийный номер каждой виртуальной машины в значение, соответствующее UUID хоста.
- Код ВМ (Vm ID): Установите серийный номер каждой виртуальной машины в значение, соответствующее UUID виртуальной машины.
- Настраиваемый серийный номер (Custom serial number): Установите серийный номер каждой виртуальной машины в значение, которое вы задаете в следующем параметре Пользовательский серийный номер (Custom Serial Number).
Нажмите OK.

2.3.2.10. Обновление политики Менеджера избыточного выделения памяти (MoM) на хостах в кластере

Менеджер избыточного выделения памяти управляет функциями балунинга памяти и KSM на хосте. Относящиеся к кластеру изменения в этих функциях передаются хостам при следующем переходе хоста в состояние Включен (Up) running после перезагрузки или после режима обслуживания. Однако при необходимости важные изменения можно применить к хосту немедленно, синхронизировав политику MoM, когда хост находится в состоянии Включен (Up) running . Следующую процедуру нужно выполнить на каждом хосте по отдельности.

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя кластера. Откроется подробное представление.
Откройте вкладку Хосты (Hosts) и выберите хост, который требует обновленной политики MoM.
Нажмите Политика синхронизации MoM (Sync MoM Policy).

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

2.3.2.11. Создание профиля ЦП

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

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

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя кластера. Откроется подробное представление.
Откройте вкладку Профили ЦП (CPU Profiles).
Нажмите Новый (New).
В поля Имя (Name) и Описание (Description) введите имя и описание профиля ЦП.
Выберите политику QoS, которую следует применить к профилю ЦП, из списка QoS.
Нажмите OK.

2.3.2.12. Удаление профиля ЦП

Удалите существующий профиль ЦП из среды zVirt.

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя кластера. Откроется подробное представление.
Откройте вкладку Профили ЦП (CPU Profiles) и выберите профиль ЦП, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

Если этот профиль ЦП был назначен каким-либо виртуальным машинам, то этим виртуальным машинам будет автоматически назначен профиль ЦП default.

2.3.2.13. Импортирование существующего кластера хранения Gluster

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

После указания таких сведений, как IP-адрес или имя хоста и пароль какого-либо хоста в кластере, на этом хосте через SSH будет выполнена команда gluster peer status, которая выведет список входящих в кластер хостов. Необходимо вручную проверить отпечатки каждого хоста и указать для них пароли. Невозможно импортировать кластер, если один из хостов в нем не работает или недоступен. Поскольку на только что импортированных хостах не установлен VDSM, скрипт начальной загрузки устанавливает все необходимые пакеты VDSM на хосты после их импорта и перезагружает их.

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите Новый (New).
Выберите Центр данных (Data Center), которому будет принадлежать кластер.
В поля Имя (Name) и Описание (Description) введите имя и описание кластера.
Установите флажки в полях Включить службу Gluster (Enable Gluster Service) и Импорт существующей конфигурации gluster (Import existing gluster configuration).

Поле Импорт существующей конфигурации gluster (Import existing gluster configuration) отображается только при установленном флажке Импорт существующей конфигурации gluster (Import existing gluster configuration).
В поле Имя хоста (Hostname) введите имя хоста или IP-адрес любого сервера в кластере.

Отображается публичный ключ SSH хоста (Host ssh public key (PEM)), чтобы можно было убедиться, что соединение устанавливается с правильным хостом. Если хост недоступен или возникла сетевая ошибка, то в поле публичный ключ SSH хоста (Host ssh public key (PEM)) будет отображаться ошибка Ошибка при получении открытого ключа SSH (Error in fetching ssh public key).
Введите Пароль (Password) для сервера и нажмите OK.
Откроется окно Добавить хосты (Add Hosts), и будет выведен список хостов, которые являются частью кластера.
Для каждого хоста введите Имя (Name) и Root-пароль (Root Password).
Если вы хотите использовать один и тот же пароль для всех хостов, то установите флажок Использовать общий пароль (Use a Common Password), чтобы ввести пароль в соответствующее текстовое поле.

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

Убедитесь, что SSH ключи действительны, и примените изменения, нажав OK.

Скрипт начальной загрузки установит все необходимые пакеты VDSM на хосты после их импорта и перезагрузит их. Вы успешно импортировали существующий кластер хранения Red Hat Gluster в Менеджер управления.

2.3.2.14. Описание настроек в окне "Добавить хосты (Add Hosts)"

В окне Добавить хосты (Add Hosts) можно указать подробные сведения о хостах, импортированных как часть кластера Gluster. Это окно появится после установки флажка в поле Включить службу Gluster (Enable Gluster Service) в окне Создать кластер (New Cluster) и указания необходимых сведений о хосте.

Таблица 41. Настройки в окне "Добавить хосты Gluster (Add Gluster Hosts)"
Поле	Описание
Использовать общий пароль (Use a common password)	Установите этот флажок, чтобы использовать один и тот же пароль для всех хостов, принадлежащих кластеру. Введите пароль в поле Пароль (Password), затем нажмите Применить (Apply), чтобы установить этот пароль для всех хостов.
Имя (Name)	Введите имя хоста.
Имя/IP-адрес хоста (Hostname/IP)	В это поле автоматически подставляется FQDN или IP-адрес хоста, который вы задали в окне Создать кластер (New Cluster).
Root Password (Root-пароль)	Введите пароль в это поле, чтобы использовать разные root-пароли для каждого хоста. Это поле переопределяет общий пароль, указанный для всех хостов в кластере.
Отпечаток (Fingerprint)	Отображается отпечаток хоста, чтобы можно было убедиться, что соединение устанавливается с правильным хостом. В это поле автоматически подставляется отпечаток хоста, который вы задали в окне Создать кластер (New Cluster).

2.3.2.15. Удаление кластера

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

Кластер Default удалить невозможно, так как он содержит пустой (Blank) шаблон. Однако кластер Default можно переименовать и добавить в новый Центр данных.

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

Нажмите Ресурсы (Compute) Кластеры (Clusters) и выберите кластер.
Убедитесь в том, что в кластере нет хостов.
Нажмите Дополнительные действия (More Actions) , а затем Удалить (Remove).
Нажмите ОК

2.3.2.16. Оптимизация памяти

Чтобы увеличить количество виртуальных машин на хосте, можно использовать избыточное выделение памяти (memory overcommitment), при котором объем памяти, назначаемый виртуальным машинам, превышает объем ОЗУ и определяется областью подкачки.

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

Производительность подкачки – область подкачки работает медленнее и потребляет больше ресурсов ЦП, чем ОЗУ, что влияет на производительность виртуальных машин. Чрезмерно интенсивная подкачка может привести к перегрузке ЦП.
Демон остановки процессов при нехватке памяти (Out-of-memory, или OOM killer) – если на хосте заканчивается пространство подкачки, то новые процессы не могут запуститься и демон ядра OOM killer начинает завершать активные процессы (такие как гостевые процессы виртуальных машин).

Для решения этих проблем можно:

Ограничить избыточное выделение памяти, используя настройку Оптимизация памяти (Memory Optimization) и Менеджер избыточного выделения памяти (Memory Overcommit Manager, MoM).
Сделать область подкачки достаточно большой, чтобы удовлетворить максимально возможные потребности в виртуальной памяти с запасом.
Уменьшить объем виртуальной памяти, включив балунинг памяти (memory ballooning) и Объединение одинаковых страниц памяти (Kernel Same-page Merging, KSM).

2.3.2.17. Оптимизация памяти и избыточное выделение памяти

Можно ограничить величину избыточного выделения памяти, установив настройку Оптимизация памяти (Memory Optimization) в одно из следующих значений:

Выключить перераспределение памяти (None) - 0%
Для серверной нагрузки (For Server Load) - 150%
Для нагрузки рабочей станции (For Desktop Load) - 200%.

Каждое значение соответствует процентной доле от объема ОЗУ. Например, если хост имеет 64 ГБ ОЗУ, выбор значения Для серверной нагрузки (For Server Load) (150%) означает, что может быть выделено дополнительно 32 ГБ и, таким образом, общий объем виртуальной памяти станет равен 96 ГБ. Если хост использует 4 ГБ из этого общего объема, то оставшиеся 92 ГБ будут доступны. Их можно назначить виртуальным машинам (Оперативная память (разделяемая) (Memory Size) на вкладке Система (System)), но оставьте какую-то часть неназначенной – в качестве запаса.

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

В отношении процессов, для которых характерен скорее плавный рост потребности в памяти, выберите более высокий процент, например Для нагрузки рабочей станции (For Desktop Load) (200%) или Для серверной нагрузки (For Server Load) (150%).
В отношении более критичных приложений или процессов, для которых характерны скорее внезапные скачки потребности в памяти, выберите более низкий процент, например Для серверной нагрузки (For Server Load) (150%) или Выключить перераспределение памяти (None) (0%). Выбор значения Выключить перераспределение памяти (None) предотвращает избыточное выделение памяти, но позволяет MoM и механизмам балунинга памяти и KSM продолжать оптимизировать виртуальную память.

Всегда подвергайте настройки Оптимизации памяти (Memory Optimization) стресс-тестированию в широком диапазоне условий, прежде чем развернуть конфигурацию в производственной среде.

Чтобы настроить Оптимизацию памяти (Memory Optimization), откройте вкладку Оптимизация (Optimization) в окне Новый кластер (New Cluster) или Изменить кластер (Edit Cluster). См. раздел Описание настроек оптимизации.

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

Фактическую доступную память нельзя определить в реальном времени, поскольку степень оптимизации памяти, обеспечиваемой механизмами KSM и балунинга памяти, все время меняется.
Когда виртуальные машины достигают предела виртуальной памяти, новые приложения не могут запуститься.
При планировании количества виртуальных машин, которые будут работать на хосте, используйте в качестве отправной точки максимальный объем виртуальной памяти (объем физической памяти и настройку Оптимизация памяти (Memory Optimization)). Не учитывайте небольшие объемы виртуальной памяти, достигаемые благодаря оптимизации памяти, такой как балунинг памяти и KSM.

2.3.2.18. Область подкачки и избыточное выделение памяти

Оценивая общий размер виртуальной памяти, отталкивайтесь от объема физической памяти и настройки Оптимизация памяти (Memory Optimization). Исключите любое уменьшение объема виртуальной памяти в результате оптимизации с помощью MoM, балунинга памяти и KSM.

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

2.3.2.19. Менеджер избыточного выделения памяти (Memory Overcommit Manager, MoM)

Менеджер избыточного выделения памяти (Memory Overcommit Manager, MoM) решает две задачи:

Ограничивает избыточное выделение, применяя настройку Оптимизация памяти (Memory Optimization) к хостам в кластере, как описано в предыдущем разделе.
Оптимизирует память, управляя балунингом памяти (memory ballooning) и KSM, как описано в следующих разделах.

Включать или выключать MoM не нужно.

Когда объем свободной памяти хоста падает ниже 20%, команды балунинга (такие как mom.Controllers.Balloon - INFO Ballooning guest:half1 from 1096400 to 1991580) вносятся в файл журнала MoM /var/log/vdsm/mom.log.

2.3.2.20. Балунинг памяти (Memory Ballooning)

Виртуальные машины запускаются с полным объемом виртуальной памяти, который им выделен. Как только использование виртуальной памяти превысит объем ОЗУ, хост начинает больше полагаться на область подкачки. Если балунинг памяти (memory ballooning) включен, он позволяет виртуальным машинам отдавать неиспользуемые части памяти. Освобожденная память может быть повторно использована другими процессами и виртуальными машинами на хосте. Уменьшение объема занимаемой памяти снижает вероятность подкачки и повышает производительность.

Пакет virtio-balloon, который устанавливает устройство балунинга памяти и драйверы, поставляется как загружаемый модуль ядра (loadable kernel module, LKM). По умолчанию он сконфигурирован так, чтобы загружаться автоматически. Помещение модуля в черный список или его выгрузка выключает балунинг памяти.

Устройства балунинга памяти не координируются напрямую друг с другом; они полагаются на процесс Memory Overcommit Manager (MoM) хоста, постоянно отслеживающий потребности каждой виртуальной машины и указывающий устройству балунинга памяти увеличить или уменьшить виртуальную память.

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

Не рекомендуется использовать балунинг памяти и избыточное выделение памяти для процессов, требующих стабильно высокой производительности и низкой задержки. См. Настройка высокопроизводительных виртуальных машин.
Используйте балунинг памяти, когда увеличение плотности виртуальных машин (экономичность) важнее производительности.
Балунинг памяти не сильно влияет на загрузку ЦП. (KSM потребляет часть ресурсов ЦП, но это потребление остается постоянным под нагрузкой).

Чтобы включить балунинг памяти, откройте вкладку Оптимизация (Optimization) в окне Новый кластер (New Cluster) или Изменить кластер (Edit Cluster). Затем установите флажок в поле Включить оптимизацию динамического выделения памяти (Enable Memory Balloon Optimization). Эта настройка включает избыточное выделение памяти на виртуальных машинах, работающих на узлах в этом кластере. Когда этот флажок поставлен, MoM начинает применять балунинг памяти во всех возможных ситуациях с ограничением гарантированного объема памяти для каждой виртуальной машины. См. раздел Описание настроек оптимизации.

Каждый хост в этом кластере получает обновление политики балунинга памяти, когда его статус меняется на Включен (Up) running . При необходимости вы можете вручную обновить политику балунинга памяти на хосте, не меняя статус. См. раздел Обновление политики Менеджера избыточного выделения памяти на хостах в кластере.

2.3.2.21. Объединение одинаковых страниц памяти (Kernel Same-page Merging, KSM)

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

Включенная функция Объединения одинаковых страниц памяти (Kernel Same-page Merging, KSM) проверяет виртуальную память на хосте, устраняет дублирующиеся страницы памяти и распределяет оставшиеся страницы памяти между несколькими приложениями и виртуальными машинами. Эти общие страницы памяти помечаются как копируемые при записи, и если виртуальной машине необходимо записать изменения на страницу, она сначала создает копию и только потом записывает свои изменения в копию.

Когда функция KSM включена, ей управляет MoM. Настраивать или управлять функцией KSM вручную не нужно.

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

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

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

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

Чтобы включить KSM, откройте вкладку Оптимизация (Optimization) в окне Новый кластер (New Cluster) или Изменить кластер (Edit Cluster). Затем установите флажок в поле Включить KSM (Enable KSM). Этот флажок позволяет Менеджеру избыточного выделения памяти запускать KSM, когда это необходимо и может дать экономию памяти, выгода от которой перевешивает затраты на ЦП. См. раздел Описание настроек оптимизации.

2.3.2.22. UEFI и чипсет Q35

Чипсет Q35 с UEFI и SecureBoot – это предварительные версии технологий, представленные для оценки (Technology Preview). Такие технологии не поддерживаются соглашениями об уровне обслуживания (SLA) продуктивной среды и могут быть функционально неполными. Не рекомендуется использовать их в продуктивной среде. Тем не менее они дают возможность раннего доступа к будущим функциям продукта, позволяя заказчикам тестировать функциональность и оставлять отзывы в процессе разработки.

Чипсет Intel Q35, используемый по умолчанию для новых виртуальных машин, включает в себя поддержку Unified Extensible Firmware Interface (UEFI), который заменяет устаревший BIOS.

Либо можно настроить виртуальную машину или кластер для использования устаревшего чипсета Intel i440fx, который не поддерживает UEFI.

UEFI имеет ряд преимуществ по сравнению с устаревшей BIOS, а именно:

Современный загрузчик.
Функцию SecureBoot, которая проверяет подлинность цифровых подписей загрузчика.
Таблицу разделов GUID (GPT), позволяющую использовать диски размером более 2 ТБ.

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

Таблица 42. Доступные типы BIOS
Тип BIOS	Описание
Чипсет Q35 с BIOS (Q35 Chipset with BIOS)	BIOS
Чипсет Q35 с UEFI (Q35 Chipset with UEFI)	UEFI
Чипсет Q35 с UEFI SecureBoot (Q35 Chipset with UEFI SecureBoot)	UEFI с функцией SecureBoot, которая проверяет подлинность цифровых подписей загрузчика
I440FX Chipset with BIOS	Чипсет i440fx с устаревшей BIOS

Задание типа BIOS до установки ОС

Настроить виртуальную машину для использования чипсета Q35 и UEFI можно перед установкой ОС. Преобразование виртуальной машины из устаревшей BIOS в UEFI после установки ОС не поддерживается.

2.3.2.23. Настройка кластера для использования чипсета Q35 и UEFI

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

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

На Пользовательском портале или Портале администрирования нажмите Ресурсы (Compute) Кластеры (Clusters).
Выберите кластер и нажмите Изменить (Edit).
Нажмите Общие (General).
Определите тип чипсета/ПО по умолчанию для новых виртуальных машин в кластере, нажав на выпадающее меню Тип чипсета/ПО (Chipset/Firmware Type) и выбрав один из следующих вариантов:
- I440FX Chipset with BIOS
- Чипсет Q35 с BIOS (Q35 Chipset with BIOS)
- Чипсет Q35 с UEFI (Q35 Chipset with UEFI)
- Чипсет Q35 с UEFI SecureBoot (Q35 Chipset with UEFI SecureBoot)
Если какие-либо из существующих виртуальных машин в кластере должны использовать новый тип чипсета/ПО, настройте их соответствующим образом. Дополнительную информацию см. в разделе Настройка виртуальной машины для использования чипсета Q35 с UEFI.

Поскольку изменить тип чипсета/ПО можно только перед установкой ОС, для всех существующих виртуальных машин, настроенных на использование BIOS типа Заданный для кластера по умолчанию (Cluster default), измените тип чипсета/ПО в значение, соответствующее предыдущему типу, заданному для кластера по умолчанию. В противном случае виртуальная машина может не загрузиться. Либо, как вариант, можно переустановить ОС виртуальной машины.

2.3.2.24. Настройка виртуальной машины для использования чипсета Q35 с UEFI

Настроить виртуальную машину для использования чипсета Q35 и UEFI можно перед установкой ОС. Преобразование виртуальной машины из устаревшей BIOS в UEFI или из UEFI в устаревший BIOS может помешать загрузке виртуальной машины. Если вы меняете тип BIOS существующей виртуальной машины, переустановите ОС.

Если тип чипсета/ПО виртуальной машины установлен в значение Заданный для кластера по умолчанию (Cluster default), изменение тип чипсета/ПО кластера приводит к изменению тип чипсета/ПО виртуальной машины. Если на виртуальной машине установлена ОС, изменение тип чипсета/ПО кластера может привести к сбою загрузки виртуальной машины.

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

На Пользовательском портале или Портале администрирования нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Выберите виртуальную машину и нажмите Изменить (Edit).
На вкладке Общие (General) нажмите Показать расширенные настройки (Show Advanced Options).
Нажмите Система (System).
В выпадающем меню Тип BIOS (Chipset/Firmware Type) выберите одно из следующих значений:
- I440FX Chipset with BIOS
- Чипсет Q35 с BIOS (Q35 Chipset with BIOS)
- Чипсет Q35 с UEFI (Q35 Chipset with UEFI)
- Чипсет Q35 с UEFI SecureBoot (Q35 Chipset with UEFI SecureBoot)
Нажмите OK.
На Пользовательском портале или Портале администрирования выключите виртуальную машину. При следующем запуске виртуальной машины она будет работать с выбранным новым типом чипсета/ПО.

2.4. Логические сети

2.4.1. Задачи, касающиеся логических сетей

2.4.1.1. Выполнение задач, касающихся логических сетей

Нажав Сеть (Network) Сети (Networks), пользователь попадает в центр выполнения операций с логическими сетями и поиска логических сетей по свойствам каждой сети или ее ассоциации с другими ресурсами. Кнопки Новая (New), Изменить (Edit) и Удалить (Remove) позволяют создавать, менять свойства и удалять логические сети в центрах данных.

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

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

Эти функции также доступны через каждый отдельный ресурс.

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

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

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

Службы каталогов
DNS
Хранилище

2.4.1.2. Создание новой логической сети в центре данных или кластере

Создайте логическую сеть и определите ее использование в центре данных или в кластерах центра данных.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers) или Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя центра данных или кластера. Откроется подробное представление.
Откройте вкладку Логические сети (Logical Networks).
Откройте окно Новая логическая сеть (New Logical Network):
- В подробном представлении центра данных нажмите Новая (New).
- В подробном представлении кластера нажмите Добавить сеть (Add Network).
В полях Имя (Name), Описание (Description) и Комментарий (Comment) укажите значения для логической сети.
Дополнительно: Установите флажок Включить тегирование VLAN (Enable VLAN tagging).
Дополнительно: Снимите флажок Сеть ВМ (VM Network).
Дополнительно: Установите флажок в поле Создать на внешнем провайдере (Create on external provider). Это выключает параметры "Метка сети" и "Сеть ВМ". Подробности см. в разделе Внешние провайдеры.
- Выберите Внешний провайдер (External Provider). Список Внешних провайдеров (External Provider) не включает в себя внешних провайдеров, находящихся в режиме "только чтение".
- Чтобы создать внутреннюю изолированную сеть, выберите ovirt-provider-ovn в списке Внешних провайдеров (External Provider) и не ставьте флажок в поле Подключаться к физической сети (Connect to physical network).
В текстовом поле Метка сети (Network Label) введите новую или выберите существующую метку для логической сети.

В качестве Максимального размера передаваемого блока данных (MTU) либо выберите Значение по умолчанию (1500) (Default (1500)), либо выберите Пользовательский (Custom) и укажите само это значение.

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

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

В случае выбора ovirt-provider-ovn в выпадающем списке Внешний провайдер (External Provider) укажите, должна ли сеть использовать Группы безопасности (опция Безопасность сетевого порта (Network Port Security)). Подробности см. в Разделе Описание общих настроек логической сети.
На вкладке Кластер (Cluster) выберите кластеры, которым будет назначена эта сеть (опция Подключить (Attach)). Можно также указать, будет ли логическая сеть обязательной сетью (опция Обязательная (Require)).
Если поставлен флажок Создать на внешнем провайдере (Create on external provider), то будет видна вкладка Подсеть (Subnet). На вкладке Подсеть (Subnet) выберите Создать подсеть (Create subnet), введите Имя (Name), CIDR и адрес Шлюза (Gateway) и выберите Версию IP (IP Version) для подсети, которую будет предоставлять логическая сеть. Можно также добавить серверы DNS, если необходимо.
На вкладке Профили vNIC (vNIC Profiles) добавьте vNIC-профили к логической сети, если необходимо.
Нажмите OK.

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

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

2.4.1.3. Изменение логической сети

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

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Логические сети (Logical Networks) и выберите логическую сеть.
Нажмите Изменить (Edit).

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

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

Нажмите OK.

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

2.4.1.4. Удаление логической сети

Для удаления логической сети нажмите Сеть (Network) Сети (Networks) или Ресурсы (Compute) Центры данных (Data Centers). Далее показано, как удалить логические сети, ассоциированные с центром данных. Для работающей среды zVirt должна быть хотя бы одна логическая сеть, используемая в качестве сети управления ovirtmgmt.

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Откройте вкладку Логические сети (Logical Networks), чтобы вывести список логических сетей центра данных.
Выберите логическую сеть и нажмите Удалить (Remove).
Если сеть предоставлена внешним провайдером, то при желании для удаления логической сети сразу из Менеджера управления и внешнего провайдера поставьте флажок Удалить сеть(и) внешнего(их) провайдера(ов) (Remove external network(s) from the provider(s) as well). Поле для флажка неактивно, если внешний провайдер находится в режиме "только чтение".
Нажмите OK.

Логическая сеть удалена из Менеджера управления и более не доступна.

2.4.1.5. Настройка логической сети, не являющейся сетью управления, в качестве маршрута по умолчанию

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

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

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

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

Нажмите Сеть (Network) Сети (Networks).
Нажмите на имя логической сети, не являющейся сетью управления, чтобы открыть сведения о ней и настроить ее в качестве маршрута по умолчанию.
Откройте вкладку Кластеры (Clusters).
Нажмите Управление сетью (Manage Network). Откроется окно Управление сетью (Manage Network).
Установите флажок Маршрут по умолчанию (Default Route) для соответствующих кластеров.
Нажмите OK.

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

Важные ограничения при использовании IPv6

zVirt поддерживает только статическую адресацию для IPv6.
Если обе сети используют один шлюз (находятся в одной подсети), то можно передать роль маршрута по умолчанию от сети управления (ovirtmgmt) другой логической сети.
Если хост и Менеджер управления находятся в разных подсетях, то Менеджер управления теряет связь с хостом, поскольку шлюз IPv6 был удален.
При переносе маршрута по умолчанию в сеть, не являющуюся сетью управления, шлюз IPv6 удаляется из сетевого интерфейса и генерируется предупреждение: В кластере имя кластера (clustername) у сети ovirtmgmt больше нет роли "маршрут по умолчанию". Шлюз IPv6 удаляется из этой сети.

2.4.1.6. Добавление статического маршрута на хосте

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

Добавляемые статические маршруты сохраняются до тех пор, пока соответствующий мост маршрутизации, интерфейс или bond-интерфейс существует и имеет IP-адрес. В противном случае система удалит статический маршрут.

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

Пользовательский статический маршрут сохраняется до тех пор, пока его интерфейс или bond-интерфейс существует и имеет IP-адрес. В противном случае он удаляется.

В результате сети ВМ ведут себя не так, как сети без ВМ:

В основе сетей ВМ лежит мост (bridge). Перенос сети с одного интерфейса или bond-интерфейса на другой не влияет на маршрут в сети ВМ.
В основе сетей без ВМ лежит интерфейс. Перенос сети с одного интерфейса или bond-интерфейса на другой удаляет маршрут, связанный с сетью без ВМ.

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

Для этой процедуры требуется инструмент nmstate

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

Подключитесь к хосту, который вы хотите настроить.
На хосте создайте файл static_route.yml со следующим содержимым (пример):
```
routes:
config:
- destination: 192.168.123.0/24
    next-hop-address: 192.168.178.1
    next-hop-interface: eth1
```
Замените приведенные в качестве примера значения реальными значениями для вашей сети.
Чтобы маршрутизировать трафик в сеть, добавленную в качестве вторичной, используйте next-hop-interface для указания интерфейса или имени сети.
- Чтобы использовать сеть без ВМ, укажите интерфейс, например, eth1.
- Чтобы использовать сеть ВМ, укажите имя сети, которое является и именем моста, например, net1.
Выполните команду:
```
$ nmstatectl set static_route.yml
```

Действия по проверке:

Выполните команду ip route со значением параметра приемника, установленным в static_route.yml. Должен отобразиться желаемый маршрут. Например, выполните следующую команду:
```
$ ip route | grep 192.168.123.0
```
Дополнительные ресурсы
Удаление статического маршрута на хосте

2.4.1.7. Удаление статического маршрута на хосте

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

В результате сети ВМ ведут себя не так, как сети без ВМ:

В основе сетей ВМ лежит мост (bridge). Перенос сети с одного интерфейса или bond-интерфейса на другой не влияет на маршрут в сети ВМ.
В основе сетей без ВМ лежит интерфейс. Перенос сети с одного интерфейса или bond-интерфейса на другой удаляет маршрут, связанный с сетью без ВМ.

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

Для этой процедуры требуется инструмент nmstate

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

Подключитесь к хосту, который хотите перенастроить.
На хосте измените файл static_route.yml.
Вставьте строку state: absent, как показано в следующем примере.
Вставьте значение next-hop-interface между квадратными скобками конструкции interfaces: []. Результат должен быть похож на показанный в следующем примере.
```
routes:
config:
- destination: 192.168.123.0/24
    next-hop-address: 192.168.178.
    next-hop-interface: eth1
    state: absent
interfaces: [{“name”: eth1}]
```
Выполните команду:
```
$ nmstatectl set static_route.yml
```

Действия по проверке:

Выполните команду ip route со значением параметра приемника, установленным в static_route.yml. Желаемый маршрут больше не должен отображаться. Например, выполните следующую команду:
```
$ ip route | grep 192.168.123.0
```
Дополнительные ресурсы
Добавление статического маршрута на хосте

2.4.1.8. Просмотр или изменение шлюза для логической сети

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

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

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces), чтобы вывести список сетевых интерфейсов, подключенных к хосту, и их конфигурации.
Нажмите Настройка сетей хоста (Setup Host Networks).
Наведите указатель мыши на назначенную логическую сеть и нажмите на значок карандаша . Откроется окно Изменить сеть управления (Edit Management Network).

В окне Изменить сеть управления (Edit Management Network) отображается имя сети, способ конфигурации (boot protocol), IP-адрес, маска подсети и адреса шлюзов. Сведения об адресах можно изменить вручную, выбрав Статичную (Static) конфигурацию.

2.4.1.9. Описание общих настроек логической сети

В приведенной ниже таблице описаны настройки вкладки Общие (General) окон Новая логическая сеть (New Logical Network) и Изменить логическую сеть (Edit Logical Network).

Таблица 43. Настройки окон "Новая логическая сеть (New Logical Network)" и "Изменить логическую сеть (Edit Logical Network)"

Имя поля

Описание

Имя (Name)

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

Имейте в виду, что хотя имя логической сети может быть длиннее 15 знаков и может содержать знаки, отличные от ASCII, идентификатор на хосте (vdsm_name) будет отличаться от заданного имени. Указания по отображению сопоставления этих имен см. в разделе Инструмент сопоставления VDSM с именем сети.

Описание (Description)

Описание логической сети. Это текстовое поле имеет ограничение по длине (40 знаков).

Комментарий (Comment)

Поле для добавления обычного текста в читаемой человеком форме – комментариев, относящихся к логической сети.

Создать на внешнем провайдере (Create on external provider)

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

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

Включить тегирование VLAN (Enable VLAN tagging)

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

Сеть ВМ (VM Network)

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

Изоляция портов (Port Isolation)

Если этот флажок установлен, виртуальные машины на одном хосте не могут обмениваться данными и видеть друг друга в этой логической сети. Чтобы эта опция работала на разных гипервизорах, на коммутаторах должна быть настроена PVLAN/изоляция портов на соответствующих портах/VLAN, подключенных к гипервизорам, и не должны использоваться какие-либо настройки возврата кадров (например, Hairpin NAT).

Максимальный размер передаваемого блока данных (MTU)

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

Метка сети (Network Label)

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

Безопасность сетевого порта (Network Port Security)

Позволяет назначать группы безопасности портам в этой логической сети. Выключен (Disabled) отключает функцию групп безопасности. Включен (Enabled) включает эту функцию. Когда порт создается и подключается к этой сети, функция безопасности будет включена. Это означает, что доступ к виртуальным машинам и от них будет зависеть от групп безопасности, которые в настоящее время предоставляются. Неопределён (Undefined) разрешает портам наследовать поведение из файла конфигурации, заданного для всех сетей. По умолчанию этот файл выключает группы безопасности. Подробности см. в разделе Назначение групп безопасности логическим сетям и портам.

2.4.1.10. Описание настроек кластера логической сети

В приведенной ниже таблице описаны настройки вкладки Кластер (Cluster) окна Новая логическая сеть (New Logical Network).

Таблица 44. Настройки в окне "Новая логическая сеть (New Logical Network)"
Имя поля	Описание
Управление сетями кластера (Attach/Detach Network to/from Cluster(s))	Позволяет подключать логическую сеть к кластерам или отключать ее от кластеров в центре данных и указывать, будет ли логическая сеть обязательной сетью для отдельных кластеров. Имя (Name) – имя кластера, к которому будут применяться настройки. Это неизменяемое значение. Выбрать все (Attach All) – позволяет подключить логическую сеть ко всем кластерам в центре данных или отключить ее от них. Либо поставьте или снимите флажок Подключить (Attach) рядом с именем каждого кластера, чтобы подключить логическую сеть к данному кластеру или отключить ее от него. Выбрать все (Required All) – позволяет указать, является ли логическая сеть обязательной сетью на всех кластерах. Либо поставьте или снимите флажок Обязательная (Required) рядом с именем каждого кластера, чтобы указать, является ли логическая сеть обязательной сетью для конкретного кластера.

2.4.1.11. Описание настроек vNIC-профилей логической сети

В приведенной ниже таблице описаны настройки вкладки профили vNIC (vNIC Profiles) окна Новая логическая сеть (New Logical Network).

Таблица 45. Настройки окна Новая логическая сеть (New Logical Network)
Имя поля	Описание
Профили vNIC (vNIC Profiles)	Эта опция позволяет задать один или несколько профилей vNIC для логической сети. Можно добавить/удалить профиль vNIC для/из логической сети, нажав кнопку или рядом с профилем. Первое поле предназначено для указания имени профиля vNIC. Публичный (Public) – позволяет указать, будет ли профиль доступен для всех пользователей. QoS – позволяет указать профиль QoS сети для профиля vNIC.

2.4.1.12. Назначение определённого типа трафика для логической сети

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

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите имя кластера. Откроется подробное представление.
Выберите вкладку Логические сети (Logical Networks).
Нажмите Управление сетями (Manage Networks).
Установите необходимые флажки и кнопки-переключатели.
Нажмите OK.

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

2.4.1.13. Описание настроек в окне "Управление сетями (Manage Networks)"

В приведенной ниже таблице описаны настройки окна Управление сетями (Manage Networks).

Таблица 46. Настройки окна "Управление сетями (Manage Networks)"
Поле	Описание/действие
Подключить (Assign)	Назначает логическую сеть всем хостам в кластере.
Обязательная (Require)	Сеть, отмеченная как "Обязательная (Require)", должна сохранять работоспособность для надлежащего функционирования ассоциированных с нею хостов. Если обязательная сеть перестаёт функционировать, все ассоциированные с нею хосты становятся неработоспособными.
Сеть ВМ (VM Network)	Логическая сеть, отмеченная как "Сеть ВМ (VM Network)", обслуживает сетевой трафик, относящийся к сети виртуальных машин.
Сеть отображения (Display Network)	Логическая сеть, обозначенная как "Сеть отображения (Display Network)", обслуживает сетевой трафик, относящийся к SPICE и VNC.
Сеть миграции (Migration Network)	Логическая сеть, обозначенная как "Сеть миграции (Migration Network)", обслуживает трафик миграции виртуальных машин и хранилищ. Если в этой сети произойдет отключение питания, то вместо нее будет использоваться сеть управления (ovirtmgmt).

2.4.1.14. Настройка виртуальных функций на сетевой карте

Это один из вопросов на тему, как настроить и сконфигурировать SR-IOV в zVirt. Дополнительные сведения см. в разделе Установка и настройка SR-IOV.

Виртуализация ввода-вывода (технология SR-IOV) позволяет с помощью физических и виртуальных функций использовать каждое оконечное устройство PCIe как несколько отдельных устройств. PCIe-карта может иметь от одной до восьми физических функций. Каждая физическая функция может иметь множество виртуальных функций. Количество возможных виртуальных функций зависит от конкретного типа PCIe-устройства.

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

Виртуальные функции можно настроить так же, как и отдельную сетевую карту, в том числе:

Назначить одну или несколько логических сетей для виртуальной функции;
Создать бондинг интерфейсов с виртуальными функциями;
Назначить виртуальные сетевые карты (vNIC) виртуальным функциям для сквозного доступа к устройствам.

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

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

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста с поддержкой технологии SR-IOV. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Выберите Настройка сетей хоста (Setup Host Networks).
Выберите сетевую карту с поддержкой SR-IOV, отмеченную знаком , и нажмите на значок карандаша .

Дополнительно: Чтобы изменить количество виртуальных функций, нажмите кнопку с выпадающим списком Настройка количества виртуальных функций (Number of VFs setting) и измените значение в текстовом поле Количество виртуальных функций (Number of VFs).

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

Дополнительно: Чтобы установить ограничение для виртуальных сетей на доступ к виртуальным функциям, выберите Особые сети (Specific networks).
- Выберите те сети, которым будет разрешен доступ к виртуальным функциям, или с помощью Меток (Labels) выберите сети с соответствующими сетевыми метками.
Нажмите OK.
В окне Настройка сетей хоста (Setup Host Networks) нажмите OK.

2.4.2. Виртуальные сетевые карты (vNICs)

2.4.2.1. Обзор профилей vNIC

Профиль виртуальной сетевой карты (профиль vNIC) – это набор параметров, которые можно применить к отдельным виртуальным сетевым картам в Менеджере управления. Профиль vNIC позволяет применять профили QoS сети к vNIC, включать или выключать зеркалирование портов, добавлять или удалять пользовательские свойства. Профиль vNIC также дает дополнительную гибкость управления, поскольку разрешение на использование (потребление) этих профилей может быть предоставлено определенным пользователям. Таким образом, можно регулировать качество обслуживания (QoS) различных пользователей в определенной сети.

2.4.2.2. Создание или изменение профилей vNIC

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

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

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

Нажмите Сеть (Network) Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Выберите вкладку Профили vNIC (vNIC Profiles).
Нажмите Новый (New) или Изменить (Edit).
Введите имя и описание профиля в поля Имя (Name) и Описание (Description).
Выберите подходящую политику QoS из списка QoS.
Выберите Сетевой фильтр (Network Filter) из выпадающего списка, чтобы настроить трафик сетевых пакетов к виртуальным машинам и от них.
Установите флажок в поле Passthrough, чтобы включить сквозной доступ на vNIC и разрешить прямое назначение устройства виртуальной функции. Если включить свойство сквозного доступа, то по причине несовместимости будут выключены политика QoS, сетевая фильтрация и зеркалирование портов. Дополнительные сведения о сквозном доступе см. в разделе Включение сквозного доступа на профиле vNIC.
Если выбран Сквозной доступ (Passthrough), то при желании можно снять флажок Мигрируемый (Migratable), чтобы выключить возможность миграции для vNIC, которые используют этот профиль. Если оставляете флажок в этом поле, то см. Настройка виртуальных машин с виртуальными сетевыми картами с включенным SR-IOV в Руководстве по управлению виртуальными машинами.
Используйте флажки в полях Зеркалирование портов (Port Mirroring) и Разрешить всем пользователям доступ к этому профилю (Allow all users to use this Profile), чтобы включать и выключать эти опции.
Выберите пользовательское свойство из списка пользовательских свойств, где по умолчанию отображается Выберите ключ… (Please select a key…). Нажимая кнопки и , добавляйте или удаляйте пользовательские свойства.
Нажмите OK.

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

2.4.2.3. Описание настроек в окне "Профиль интерфейса (Interface Profile)"

Таблица 47. Окно "Профиль интерфейса (Interface Profile)"
Имя поля	Описание
Сеть (Network)	Выпадающий список доступных сетей, к которым можно применить профиль vNIC.
Имя (Name)	Имя профиля vNIC. Это должно быть уникальное имя длинной от 1 до 50 знаков, представляющее собой любую комбинацию латинских букв в верхнем и нижнем регистре, цифр, дефисов и знаков подчеркивания.
Описание (Description)	Описание профиля vNIC. Это поле является рекомендованным, но необязательным.
QoS	Выпадающий список доступных политик QoS сети для применения к профилю vNIC. Политики QoS регулируют входящий и исходящий сетевой трафик vNIC.
Сетевой фильтр (Network Filter)	Выпадающий список доступных сетевых фильтров, который можно применить к профилю vNIC. Сетевые фильтры повышают безопасность сети за счет фильтрации типов пакетов, которые могут быть отправлены на виртуальные машины и от них. По умолчанию установлен фильтр vdsm-no-mac-spoofing, который представляет собой комбинацию no-mac-spoofing и no-arp-mac-spoofing. Используйте параметр `Нет сетевого фильтра` (`No Network Filter`) для сетей VLAN и bond-интерфейсов виртуальных машин. Отключение сетевого фильтра на доверенных виртуальных машинах может повысить производительность.
Passthrough	Отметить флажком, чтобы включить свойство сквозного доступа. Сквозной доступ позволяет карте vNIC напрямую подключаться к виртуальной функции сетевой карты хоста. Свойство сквозного доступа нельзя изменять, если профиль vNIC подключен к виртуальной машине. При включенном сквозном доступе политика QoS, сетевые фильтры и зеркалирование портов в профиле vNIC выключены.
Мигрируемый (Migratable)	Флажок в этом поле определяет, можно ли переносить карты vNIC, использующие этот профиль, или нет. Миграция включена по умолчанию для обычных профилей vNIC: флажок в поле стоит, и снять его нельзя. Когда стоит флажок в поле Passthrough, свойство Мигрируемый (Migratable) становится доступным, и при необходимости флажок можно снять, чтобы выключить возможность миграции карт vNIC сквозного доступа.
Профиль отказоустойчивости vNIC (Failover)	Выпадающий список для выбора доступных профилей vNIC, действующих в качестве устройств аварийного переключения. Доступно только, когда стоят флажки в полях Passthrough и Мигрируемый (Migratable).
Зеркалирование портов (Port Mirroring)	Поставить/снять флажок, чтобы включить/отключить зеркалирование портов. При зеркалировании портов сетевой трафик третьего уровня копируется с логической сети на виртуальный интерфейс виртуальной машины. По умолчанию флажок в этом поле снят. Дополнительные сведения см. в разделе Зеркалирование портов (Port Mirroring) в Техническом справочнике.
Пользовательские свойства (Custom Properties)	Выпадающий список, в котором можно выбрать доступные пользовательские свойства, которые можно применить к профилю vNIC. Нажимая кнопки и , добавляйте или удаляйте соответствующие свойства.
Разрешить всем пользователям доступ к этому профилю (Allow all users to use this Profile)	Отметить флажком, чтобы сделать профиль доступным для всех пользователей. По умолчанию флажок стоит.

Описание сетевых фильтров

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

Ниже приведен список некоторых базовых сетевых фильтров, которые доступны при настройке профилей vNic.

Таблица 48. Базовые сетевые фильтры
Имя	Описание
vdsm-no-mac-spoofing	Представляет собой комбинацию no-mac-spoofing и no-arp-mac-spoofing
allow-arp	Разрешает ARP-трафик в обоих направлениях
allow-dhcp	Разрешает виртуальной машине запрашивать IP-адрес через DHCP (с любого DHCP-сервера).
allow-incoming-ipv4	Разрешает входящий трафик IPv4
allow-ipv4	Разрешает трафик IPv4 в обоих направлениях
clean-traffic	Предотвращает подмену MAC, IP и ARP. Этот фильтр ссылается на несколько других фильтров.
no-arp-spoofing	Предотвращает подмену ARP-трафика виртуальной машиной; этот фильтр разрешает только сообщения ARP-запроса и ARP-ответа и обеспечивает, чтобы эти пакеты содержали MAC- и IP-адреса виртуальной машины.
no-ip-multicast	Запрещает виртуальной машине отправлять многоадресные IP-пакеты.
no-ip-spoofing	Запрещает виртуальной машине отправлять пакеты IPv4 с исходящим IP-адресом, отличным от адреса в пакете.
no-mac-broadcast	Запрещает виртуальной машине отправлять широковещательные кадры (mac-адрес назначения `ff:ff:ff:ff:ff:ff`)
no-mac-spoofing	Предотвращает подмену mac-адреса виртуальной машиной

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

Например, фильтр clean-traffic может быть объединен с фильтром no-ip-multicast для предотвращения отправки виртуальными машинами многоадресного IP-трафика в дополнение к предотвращению подмены пакетов.

Для получения подробной информации о соответствующем фильтре изучите XML-файл этого фильтра. Это можно сделать на любом гипервизоре в среде zVirt.

Пример 22. Получение информации о фильтре

# cat /etc/libvirt/nwfilter/no-arp-ip-spoofing.xml

...

<filter name='no-arp-ip-spoofing' chain='arp-ip' priority='-510'>
  <uuid>ced3eb5b-6e82-4120-a6d3-4fcff18577cd</uuid>
  <rule action='return' direction='out' priority='400'>
    <arp arpsrcipaddr='$IP'/>
  </rule>
  <rule action='drop' direction='out' priority='1000'/>
</filter>

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

Сетевые фильтры

2.4.2.4. Включение сквозного доступа на профиле vNIC

Свойство сквозного доступа на профиле vNIC позволяет карте vNIC напрямую подключаться к виртуальной функции сетевой карты с включенной технологией SR-IOV. В этом случае карта vNIC будет обходить программную виртуализацию сети и подключаться непосредственно к виртуальной функции для прямого назначения устройства.

Если профиль vNIC уже подключен к vNIC-карте, то включить свойство сквозного доступа нельзя; чтобы обойти это ограничение, создается новый профиль. Если в профиле vNIC включено свойство сквозного доступа, то политику QoS, сетевые фильтры и зеркалирование портов нельзя включить в том же профиле.

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

Нажмите Сеть (Network) Сети (Networks).
Выберите имя логической сети. Откроется подробное представление.
Выберите вкладку Профили vNIC (vNIC Profiles), на которой отобразится список всех профилей vNIC для этой логической сети.
Нажмите Новый (New).
Введите имя и описание профиля в поля Имя (Name) и Описание (Description).
Поставьте флажок в поле Passthrough.
При желании можно снять флажок Мигрируемый (Migratable), чтобы выключить возможность миграции для vNIC, которые используют этот профиль. Если флажок в этом поле остается, то см. Настройка виртуальных машин с виртуальными сетевыми картами с включенным SR-IOV в Руководстве по управлению виртуальными машинами.
При необходимости выберите пользовательское свойство из списка пользовательских свойств, где по умолчанию отображается Выберите ключ… (Please select a key…). Нажимая кнопки и , добавляйте или удаляйте пользовательские свойства.
Нажмите OK.

Теперь возможность сквозного доступа активирована в профиле vNIC. Чтобы использовать этот профиль для прямого подключения виртуальной машины к сетевой карте или виртуальной функции PCI, подключите логическую сеть к сетевой карте и создайте новую виртуальную сетевую карту Сквозного доступа PCI (PCI Passthrough) на нужной виртуальной машине, которая использует профиль vNIC со сквозным доступом. Более подробную информацию об этих процедурах см. в разделе Изменение сетевых интерфейсов хоста и назначение логических сетей хостам руководства администратора и Добавление нового сетевого интерфейса в Руководстве по управлению виртуальными машинами.

2.4.2.5. Включение профиля vNIC для миграции SR-IOV с аварийным переключением

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

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

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

Свойства Passthrough и Мигрируемый (Migratable) отмечены флажками в профиле.
Сеть аварийного переключения подключена к хосту.
Чтобы можно было изменять профиль vNIC, действующий в качестве устройства аварийного переключения, необходимо сначала удалить все ссылки на аварийное переключение.
Действовать как устройства аварийного переключения могут профили vNIC, в которых снят флажок в поле Passthrough или которые не подключены к Внешней сети.

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

На Портале администрирования перейдите в раздел Сеть (Network) → Профили vNIC (vNIC profiles), выберите профиль vNIC, нажмите Изменить (Edit) и выберите Профиль отказоустойчивости vNIC (Failover vNIC profile) из выпадающего списка.
Нажмите OK, чтобы сохранить настройки профиля.

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

2.4.2.6. Удаление профиля vNIC

Удаление профиля vNIC из среды виртуализации.

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

Нажмите Сеть (Network) Сети (Networks).
Выберите имя логической сети. Откроется подробное представление.
Откройте вкладку Профили vNIC (vNIC Profiles), чтобы увидеть доступные профили vNIC.
Выберите один или сразу несколько профилей и нажмите Удалить (Remove).
Нажмите OK.

2.4.2.7. Назначение профилям vNIC групп безопасности

Эта функция доступна только при добавлении ovirt-provider-ovn в качестве внешнего провайдера сети. Невозможно создать группы безопасности через Менеджер управления. Их необходимо создать через OpenStack Networking на ovirt-provider-ovn.

Группы безопасности можно назначить профилю vNIC тех сетей, которые были импортированы из экземпляра OpenStack Networking и используют плагин Open vSwitch. Группа безопасности – это свод строгих правил, которые позволяют фильтровать входящий и исходящий трафик, проходящий через сетевой интерфейс. В процедуре ниже описано, как подключить группу безопасности к профилю vNIC.

Группам безопасности присваивается идентификатор, зарегистрированный в системе Open Virtual Network (OVN) Внешнего провайдера сети. Идентификаторы групп безопасности для данного арендатора можно найти с помощью OpenStack Networking API, см. раздел Списки групп безопасности в справочнике OpenStack API Reference.

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

Нажмите Сеть (Network) Сети (Networks).
Выберите имя логической сети. Откроется подробное представление.
Выберите вкладку Профили vNIC (vNIC Profiles).
Нажмите Новый (New) или выберите существующий профиль vNIC и нажмите Изменить (Edit).
В выпадающем списке пользовательских свойств выберите SecurityGroups. Если оставить выпадающий список пользовательских свойств незаполненным, то будут применены настройки безопасности по умолчанию, которые разрешают весь исходящий и внутренний трафики, но запрещают весь входящий трафик, поступающий извне группы безопасности по умолчанию. Обратите внимание, что последующее удаление свойства SecurityGroups не повлияет на применяемую группу безопасности.
В текстовом поле введите идентификатор группы безопасности, которую нужно подключить к профилю vNIC.
Нажмите OK.

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

2.4.2.8. Разрешения пользователей для профилей vNIC

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

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

Нажмите Сеть (Network) Профили vNIC (vNIC Profiles).
Выберите имя профиля vNIC. Откроется подробное представление.
Откройте вкладку Разрешения (Permissions), чтобы увидеть текущие разрешения пользователей для профиля.
Нажмите Добавить (Add) или Удалить (Remove), чтобы изменить разрешения пользователя для профиля vNIC.
В окне Добавить разрешение для пользователя (Add Permissions to User) нажмите Мои группы (My Groups), чтобы увидеть группы пользователей. Эту опцию можно использовать для предоставления разрешений другим пользователям в ваших группах.

Разрешения пользователей для профиля vNIC успешно настроены.

2.4.3. Сети внешнего провайдера

2.4.3.1. Импортирование сетей из внешних провайдеров

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

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

Нажмите Сеть (Network) Сети (Networks).
Нажмите Импортировать (Import).
Из выпадающего списка Провайдер сети (Network Provider) выберите внешнего провайдера. Система автоматически обнаруживает сети, предложенные этим провайдером, и отображает их в виде списка Провайдер сетей (Provider Networks).
Устанавливая флажки в соответствующие поля, выберите сети для импорта из списка Провайдер сетей (Provider Networks) и нажмите стрелку вниз , чтобы переместить эти сети в список Сети для импорта (Networks to Import).
Имя импортируемой сети можно изменить. Чтобы изменить имя, нажмите на имя сети в столбце Имя (Name) и измените текст.
Из выпадающего списка Центр данных (Data Center) выберите центр данных, в который будут импортированы сети.
Дополнительно: Уберите флажок из поля Разрешить всем (Allow All), чтобы эта сеть не была доступна всем пользователям.
Нажмите Импортировать (Import).

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

2.4.3.2. Ограничения относительно использования сетей внешнего провайдера

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

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

2.4.3.3. Настройка подсетей в логических сетях внешнего провайдера

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

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

При добавлении Открытой виртуальной сети (OVN) (ovirt-provider-ovn) в качестве внешнего провайдера сети, несколько подсетей могут быть присоединены друг к другу через маршрутизаторы. Для управления этими маршрутизаторами можно использовать OpenStack Networking API v2.0. Обратите внимание, что у ovirt-provider-ovn есть ограничение: Source NAT не реализован.

2.4.3.4. Добавление подсетей в логические сети внешнего провайдера

Создайте подсеть в логической сети, предоставленной внешним провайдером.

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

Нажмите Сеть (Network) Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Откройте вкладку Подсети (Subnets).
Нажмите Новая (New).
Введите Имя (Name) и бесклассовую междоменную маршрутизацию (CIDR) для новой подсети.
Из выпадающего списка Версия IP (IP Version) выберите или IPv4, или IPv6.
Нажмите OK.

В версии IPv6 zVirt поддерживает только статическую адресацию.

2.4.3.5. Удаление подсетей из логических сетей внешнего провайдера

Удалите подсеть из логической сети, предоставленной внешним провайдером.

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

Нажмите Сеть (Network) Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Откройте вкладку Подсети (Subnets).
Выберите подсеть и нажмите Удалить (Remove).
Нажмите OK.

2.4.3.6. Назначение групп безопасности логическим сетям и портам

Функция доступна, когда Открытая виртуальная сеть (OVN) добавлена как внешний провайдер сети (ovirt-provider-ovn). Группы безопасности нельзя создать с помощью Менеджера управления. Они создаются через OpenStack Networking API v2.0 или Ansible.

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

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

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя кластера. Откроется подробное представление.
Выберите вкладку Логические сети (Logical Networks).
Нажмите Добавить сеть (Add Network) и задайте свойства, убедившись при этом, что выбираете ovirt-provider-ovn из выпадающего списка Внешний провайдер (External Provider). Дополнительные сведения см. в разделе Создание новой логической сети в центре данных или кластере.
Из выпадающего списка Безопасность сетевого порта (Network Port Security) выберите Включен (Enabled). Дополнительные сведения см. в разделе Описание общих настроек логической сети.
Нажмите OK.
Создайте группы безопасности с помощью OpenStack Networking API v2.0 или Ansible.
Создайте правила групп безопасности с помощью OpenStack Networking API v2.0 или Ansible.
Обновите порты с группами безопасности, заданные с помощью OpenStack Networking API v2.0 или Ansible.
Дополнительно. Задайте, будет ли включен функционал безопасности на уровне порта. Сейчас это возможно только с помощью OpenStack Networking API. Если не выставлен атрибут port_security_enabled, то по умолчанию будет задано значение, указанное в сети, которой он принадлежит.

2.4.4. Хосты и сетевое взаимодействие

2.4.4.1. Менеджер сетевой конфигурации с отслеживанием состояния (nmstate)

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

Администратору не нужно устанавливать или конфигурировать nmstate, который включен по умолчанию и работает в фоновом режиме.

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

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

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

Изменение в nmstate позволяют Менеджеру управления эффективнее применять изменения, сделанные в Cockpit и Anaconda до того, как хост был добавлен в Менеджер управления.

Если используется dnf или yum для обновления пакета nmstate вручную, перезапустите vdsmd и supervdsmd на хосте. Например:

# dnf update nmstate
# systemctl restart vdsmd supervdsmd

Если используется dnf или yum для обновления пакета NetworkManager вручную, перезапустите vdsmd и supervdsmd на хосте. Например:

# dnf update NetworkManager
# systemctl restart NetworkManager

2.4.4.2. Обновление конфигурации ресурсов хоста

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обновить возможности (Refresh Capabilities).

Список сетевых карт во вкладке Сетевые интерфейсы (Network Interfaces) для выбранного хоста обновлен. Теперь любая новая сетевая карта может использоваться Менеджером управления.

2.4.4.3. Изменение сетевых интерфейсов хоста и назначение логических сетей хостам

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

Изменить IP-адрес хоста в zVirt можно, только удалив хост и затем добавив его снова.

Чтобы изменить настройки VLAN хоста, см. раздел Изменение настроек VLAN хоста.

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

Если коммутатор был сконфигурирован для предоставления информации по протоколу Link Layer Discovery Protocol (LLDP), наведите указатель мыши на физический сетевой интерфейс для просмотра текущей конфигурации порта коммутатора. Так можно избежать использования неправильной конфигурации. Проверьте следующую информацию перед назначением логических сетей:

Port Description (TLV type 4) (описание порта) и System Name (TLV type 5) (системное имя) помогают определить, к каким портам и на каком коммутаторе коммутированы интерфейсы хоста.
Port VLAN ID отображает ID сети VLAN, сконфигурированной на порте коммутатора для нетегированных кадров ethernet (Native VLAN). Все сети VLAN, сконфигурированные на порте коммутатора отображаются в виде комбинаций VLAN Name и VLAN ID.

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Нажмите Настройка сетей хоста (Setup Host Networks).
Дополнительно наведите указатель мыши на сетевой интерфейс хоста для просмотра информации о конфигурации, предоставленной коммутатором.

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

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

Сконфигурируйте логическую сеть:

Наведите указатель мыши на назначенную логическую сеть и нажмите значок карандаша . Откроется окно Изменить сеть управления (Edit Management Network).

На вкладке IPv4 выберите Конфигурацию (Boot Protocol) из вариантов Отсутствует (None), DHCP или Статичная (Static). Если выбран вариант Статичная (Static), то введите IP-адрес (IP), Маска подсети/префикс (Netmask/Routing Prefix) и Шлюз (Gateway).

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

Установите вариант Статичная (Static) для Конфигурации (Boot Protocol).
В поле Префикс маршрутизатора (Routing Prefix) введите длину префикса, используя прямую косую черту и число в десятичной системе счисления. Например: /48
IP: Полный IPv6-адрес сетевого интерфейса хоста. Например: 2001:db8::1:0:0:6
Шлюз (Gateway): IPv6-адрес исходного маршрутизатора. Например: 2001:db8::1:0:0:1

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

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

Настройте все хосты в кластере, чтобы их сети управления использовали один и тот же IP-стек: или IPv4, или IPv6. Одновременное использование обоих стеков не поддерживается.

Чтобы переопределить политику QoS сети хоста по умолчанию, откройте вкладку QoS. Выберите Перезаписать QoS (Override QoS) и введите желаемые значения в следующие поля:
- Общие веса (Weighted Share): Означает, какая часть пропускной способности логического канала связи должна быть выделена для конкретной сети относительно других сетей, подключенных к тому же логическому каналу связи. Точная доля зависит от суммарного количества долей всех сетей на этом канале связи. По умолчанию это число в диапазоне 1-100.
- Ограничение скорости [Mbps] (Rate Limit [Mbps]): Максимальная полоса пропускания для использования сетью.
- Подтверждённая скорость [Мб/с] (Committed Rate [Mbps]): Минимальная полоса пропускания, требуемая для сети. Требуемая Подтверждённая скорость не гарантируется и будет варьироваться в зависимости от сетевой инфраструктуры и Подтверждённой скорости, требуемой для других сетей на том же логическом канале связи.
Для конфигурирования сетевого моста откройте вкладку Настраиваемые параметры (Custom Properties) и из выпадающего списка выберите параметр bridge_opts. Введите корректный ключ и значение в следующем формате: key=значение. Разделите несколько записей знаком пробела. Следующие ключи корректны, а значения приведены в качестве примера. Для получения дополнительной информации об этих параметрах см. раздел Описание параметров bridge_opts.
```
forward_delay=1500
group_addr=1:80:c2:0:0:0
group_fwd_mask=0x0
hash_max=512
hello_time=200
max_age=2000
multicast_last_member_count=2
multicast_last_member_interval=100
multicast_membership_interval=26000
multicast_querier=0
multicast_querier_interval=25500
multicast_query_interval=13000
multicast_query_response_interval=1000
multicast_query_use_ifaddr=0
multicast_router=1
multicast_snooping=1
multicast_startup_query_count=2
multicast_startup_query_interval=3125
```
Для конфигурирования ethernet-свойств откройте вкладку Настраиваемые параметры (Custom Properties) и из выпадающего списка выберите параметр ethtool_opts. Введите корректное значение, используя формат аргументов командной строки ethtool. Например:
--coalesce em1 rx-usecs 14 sample-interval 3 --offload em2 rx on lro on tso off --change em1 speed 1000 duplex half
В этом поле можно использовать шаблоны подстановки. Например, для применения одного и того же параметра ко всем интерфейсам этой сети, используйте:
--coalesce * rx-usecs 14 sample-interval 3
Параметр ethtool_opts не доступен по умолчанию; его нужно добавить, используя инструмент конфигурации engine. Для получения дополнительной информации см. раздел Как настроить Менеджер управления для использования ethtool. Для получения дополнительной информации о свойствах ethtool откройте соответствующую страницу руководства, введя man ethtool в командной строке.
Для конфигурирования Fibre Channel over Ethernet (FCoE) откройте вкладку Настраиваемые параметры (Custom Properties) и из выпадающего списка выберите параметр fcoe. Введите корректный ключ и значение в следующем формате: key=значение. Требуется указать хотя бы enable=yes. Можно также добавить dcb=[yes|no] и auto_vlan=[yes|no]. Разделите несколько записей знаком пробела. Параметр fcoe не доступен по умолчанию; его нужно добавить, используя инструмент конфигурации engine. Для получения дополнительной информации см. раздел Как настроить Менеджер управления для использования FCoE.

Использовать FCoE рекомендуется вместе с отдельной выделенной логической сетью.
Чтобы изменить сеть, используемую хостом по умолчанию, с сети управления (ovirtmgmt) на сеть, не отвечающую за управление, сконфигурируйте маршрут сети, не отвечающей за управление, как используемый по умолчанию. Для получения дополнительной информации см. раздел Настройка логической сети, не являющейся сетью управления, в качестве маршрута по умолчанию.
Если ваше определение настроек логической сети не синхронизировано с конфигурацией сети на хосте, то поставьте флажок Синхронизировать сеть (Sync network). Для получения дополнительной информации о несинхронизированных хостах и о том, как их синхронизировать см. раздел Синхронизация сетей хостов.

Установите флажок Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine) для проверки сетевого подключения. Это действие возможно, только если хост находится в режиме обслуживания.
Нажмите OK.

Если для хоста отображаются не все сетевые карты, то нажмите Управление (Management) → Обновить возможности (Refresh Capabilities), чтобы обновить список сетевых карт, доступных для этого хоста.

Поиск и устранение неполадок

Иногда внесение нескольких изменений одновременно в конфигурацию сети хостов с помощью окна Настройка сетей хоста (Setup Host Networks) или задачи setupNetwork завершается ошибкой Сбой операции (Operation failed): [Cannot setup Networks]. Another Setup Networks or Host Refresh process in progress on the host. Please try later.. Эта ошибка свидетельствует о том, что некоторые изменения не были сконфигурированы на хосте. Это происходит из-за того, что для сохранения целостности состояния конфигурации единовременно может обрабатываться только одна сетевая задача. Другие одновременные задачи конфигурирования ставятся в очередь с 20-секундным интервалом по умолчанию. Для предотвращения вышеуказанного сбоя используйте команду engine-config, чтобы задать интервал SetupNetworksWaitTimeoutSeconds больше 20 секунд. Например:

# engine-config --set SetupNetworksWaitTimeoutSeconds=40

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

Синтаксис команды engine-config
Метод setupnetworks

2.4.4.4. Синхронизация сетей хостов

Менеджер управления определяет сетевой интерфейс как несинхронизированный (out-of-sync), когда определение настроек интерфейса на хосте отличается от определения настроек, которое хранит Менеджер управления.

Несинхронизированные сети обозначаются значком out of sync на вкладке Сетевые интерфейсы (Network Interfaces) и значком out of sync net в окне Настройка сетей хоста (Setup Host Networks).

Когда сеть хоста не синхронизирована, единственное, что можно сделать с несинхронизированной сетью в окне Настройка сетей хоста (Setup Host Networks) – это отключить логическую сеть от сетевого интерфейса или выполнить синхронизацию сети.

Причины, по которым хост становится несинхронизированным

Хост может стать несинхронизированным, если:

Внести изменения в конфигурацию на хосте, а не в окне Изменить логическую сеть (Edit Logical Networks), например:
- изменить идентификатор VLAN на физическом хосте
- изменить Пользовательское значение MTU (Custom MTU) на физическом хосте
Переместить хост в другой центр данных с тем же именем сети, но с другими значениями/параметрами.
Изменить свойство сети Сеть ВМ (VM Network), вручную удалив мост (bridge) с хоста.

Предотвращение рассинхронизации хоста

Следование этим рекомендациям предотвратит рассинхронизацию хоста:

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

Синхронизация хостов

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

логической сети
хоста
кластера

Синхронизация сетей хостов на уровне логической сети

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Нажмите Настройка сетей хоста (Setup Host Networks).
Наведите указатель мыши на несинхронизированную сеть и нажмите на значок карандаша . Откроется окно Изменить сеть (Edit Network).
Поставьте флажок Синхронизировать сеть (Sync network).
Нажмите OK, чтобы сохранить изменение сети.
Нажмите OK, чтобы закрыть окно Настройка сетей хоста (Setup Host Networks).

Синхронизация сетей хоста на уровне хоста

Нажмите Синхронизировать все сети (Sync All Networks) на вкладке Сетевые интерфейсы (Network Interfaces) хоста, чтобы синхронизировать все несинхронизированные сетевые интерфейсы хоста.

Синхронизация сетей хоста на уровне кластера

Нажмите Синхронизация всех сетей (Sync All Networks) на вкладке Логические сети (Logical Networks) кластера, чтобы синхронизировать все несинхронизированные определения настроек логических сетей для всего кластера.

Сети хоста также можно синхронизировать через REST API. См. syncallnetworks в руководстве по REST API.

2.4.4.5. Изменение настроек VLAN хоста

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

Чтобы сохранить синхронизацию сетей, сделайте следующее:

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

При изменении VLAN ID сети управления появляется следующее предупреждение:

Изменение определенных свойств (например, VLAN или MTU) сети управления
может привести к потере связи с хостами в центре данных, если конфигурация
его базовой сетевой инфраструктуры не учитывает эти изменения. Вы уверены,
что хотите продолжить?

(Changing certain properties (e.g. VLAN, MTU) of the management network could
lead to loss of connectivity to hosts in the data center, if its underlying
network infrastructure isn't configured to accommodate the changes.
Are you sure you want to proceed?)

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

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

2.4.4.6. Добавление нескольких VLAN к одному сетевому интерфейсу с помощью логических сетей

К одному сетевому интерфейсу можно добавить несколько VLAN для разделения трафика на одном хосте.

Для этого необходимо заранее создать несколько логических сетей и для каждой из них установить флажок Включить тегирование VLAN (Enable VLAN tagging) в окнах Новая логическая сеть (New Logical Network) или Изменить логическую сеть (Edit Logical Network).

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Нажмите Настройка сетей хоста (Setup Host Networks).
Перетащите логические сети с тегами VLAN в область Назначенные логические сети (Assigned Logical Networks) рядом с физическим сетевым интерфейсом. Физическому сетевому интерфейсу может быть назначено несколько логических сетей благодаря назначению тегов VLAN.
Измените логические сети:
1. Наведите указатель мыши на назначенную логическую сеть и нажмите на значок карандаша .
2. Если определение настроек логической сети не синхронизировано с конфигурацией сети на хосте, то поставьте флажок Синхронизировать сеть (Sync network).
3. Выберите Конфигурацию (Boot Protocol):
  - Отсутствует (None)
  - DHCP
  - Статичная (Static)
4. Укажите IP-адрес (IP) и Маску подсети (Subnet Mask).
5. Нажмите OK.
Поставьте флажок Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine), чтобы запустить проверку сети. Это действие будет выполнено, только если хост находится в режиме обслуживания.
Нажмите OK.

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

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

Копирование сетей хостов

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

Копирование конфигурации сети включает в себя:

Логические сети, подключенные к хосту, кроме сети управления ovirtmgmt.
Bond-интерфейсы, подключенные к интерфейсам

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

Не копируйте конфигурации сетей, содержащие статические IP-адреса. В этом случае Конфигурация (Boot protocol) на целевом хосте будет установлен в значение Отсутствует (None).
Копирование конфигурации на целевой хост с теми же именами интерфейсов, что и у исходного хоста, но с другими физическими сетевыми подключениями, приводит к неправильной конфигурации.
Целевой хост должен иметь как минимум столько же интерфейсов, что и исходный хост. В противном случае операция будет неудачной.
Копирование QoS, DNS и Настраиваемых параметров (custom_properties) не поддерживается.
Метки сетевых интерфейсов не копируются.

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

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

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

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

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
Выберите исходный хост, чью конфигурацию хотите скопировать.
Нажмите Копирование сетей хоста (Copy Host Networks). Откроется окно Копирование сетей хоста (Copy Host Networks).
Используйте параметр Целевой хост (Target Host), чтобы выбрать хост, который должен принять эту конфигурацию. В списке перечислены только те хосты, которые находятся в том же кластере.
Нажмите Копирование сетей хоста (Copy Host Networks).
Проверьте сетевые настройки целевого хоста

Выбор нескольких хостов деактивирует кнопку Копирование сетей хоста (Copy Host Networks) и контекстное меню.
Вместо кнопки Копирование сетей хоста (Copy Host Networks) можно нажать правой кнопкой мыши на хост и выбрать Копирование сетей хоста (Copy Host Networks) в контекстном меню.
Кнопка Копирование сетей хоста (Copy Host Networks) доступна также в подробном представлении каждого хоста.

2.4.4.7. Назначение дополнительных IPv4-адресов сети хоста

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

Хук vdsm-hook-extra-ipv4-addrs позволяет настроить дополнительные IPv4-адреса для сетей хоста. Дополнительные сведения о хуках см. в VDSM и хуки.

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

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

На хосте, для которого вы хотите настроить дополнительные IPv4-адреса, установите пакет хука VDSM.
```
# dnf install vdsm-hook-extra-ipv4-addrs
```
В Менеджере управления запустите следующую команду, чтобы добавить ключ:
```
# engine-config -s 'UserDefinedNetworkCustomProperties=ipv4_addrs=.*'
```
Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```
На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces) и нажмите Настройка сетей хоста (Setup Host Networks).
Отредактируйте сетевой интерфейс хоста, наведя указатель мыши на назначенную логическую сеть и нажав на значок карандаша .
Выберите ipv4_addr из выпадающего меню Настраиваемые параметры (Custom Properties) и добавьте дополнительный IP-адрес и префикс (например, 5.5.5.5/24). Если IP-адресов несколько, их надо разделять запятой.
Нажмите OK, чтобы закрыть окно Изменить сеть (Edit Network).
Нажмите OK, чтобы закрыть окно Настройка сетей хоста (Setup Host Networks).

Дополнительные IP-адреса не будут отображаться в Менеджере управления, но можно выполнить команду ip addr show на хосте, чтобы убедиться, что они были добавлены.

2.4.4.8. Добавление меток сети к сетевым интерфейсам хостов

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

Существует два способа добавления меток к сетевому интерфейсу хоста:

Вручную на Портале администрирования
Автоматически с использованием службы LLDP Labeler

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Нажмите Настройка сетей хоста (Setup Host Networks).
Нажмите Метки (Labels), после чего нажмите правой кнопкой мыши [Новая метка] ([New Label]). Выберите физический сетевой интерфейс, которому нужно присвоить метку.
Введите имя метки сети в текстовое поле Метка (Label).
Нажмите OK.

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

2.4.4.9. Настройка службы LLDP Labeler

По умолчанию служба LLDP Labeler запускается раз в час. Этот вариант полезен, если вы меняете оборудование (например, сетевые карты, коммутаторы или кабели) или конфигурацию коммутаторов.

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

Интерфейсы должны быть подключены к коммутатору Juniper.
Коммутатор Juniper должен быть настроен на предоставление Port VLAN с помощью LLDP.

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

Задайте username и password в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf:
- username – имя администратора Менеджера управления. Значение по умолчанию – admin@internal.
- password – пароль администратора Менеджера управления. Значение по умолчанию = 123456.
Настройте службу LLDP Labeler, обновив следующие значения в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf:
- clusters – разделенный запятыми список кластеров, на которых должна работать служба. Поддерживаются шаблоны подстановки. Например, значение Cluster* предпишет службе LLDP Labeler запуститься на всех кластерах, имя которых начинается со слова Cluster. Для запуска службы на всех кластерах в центре данных введите . Значение по умолчанию – Def.
- api_url – полный URL-адрес API-интерфейса Менеджера управления. Значение по умолчанию – https://<Manager_FQDN>/ovirt-engine/api
- ca_file – путь к файлу сертификата, выданного альтернативным Центром сертификации. Если альтернативные сертификаты не используются, оставьте это значение empty. По умолчанию - empty.
- auto_bonding – включает функции бондинга, имеющиеся у службы LLDP Labeler. Значение по умолчанию – true.
- auto_labeling – включает функции присвоения меток, имеющиеся у службы LLDP Labeler. Значение по умолчанию – true.
При желании можно настроить службу на запуск с другой периодичностью, изменив значение OnUnitActiveSec в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-labeler.timer. Значение по умолчанию – 1h.
Настройте службу на запуск прямо сейчас и при загрузке, введя следующую команду:
# systemctl enable --now ovirt-lldp-labeler
Чтобы вызвать службу вручную, введите следующую команду:
# /usr/bin/python /usr/share/ovirt-lldp-labeler/ovirt_lldp_labeler_cli.py

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

2.4.4.10. Изменение полного доменного имени (FQDN) хоста

Используйте следующую процедуру, чтобы изменить полное доменное имя хостов.

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

Переведите хост в режим обслуживания, чтобы виртуальные машины "на лету" перенеслись на другой хост. Дополнительную информацию см. в разделе Перевод хоста в режим обслуживания. Либо вручную выключите все виртуальные машины или перенесите их на другой хост. Дополнительную информацию см. в разделе Ручная миграция виртуальных машин руководства по управлению виртуальными машинами.
Нажмите Удалить (Remove) и затем OK, чтобы удалить хост из Портала администрирования.
Для обновления имени хоста воспользуйтесь инструментом hostnamectl.
```
# hostnamectl set-hostname _NEW_FQDN_
```
Перезагрузите хост.
Заново зарегистрируйте хост в Менеджере управления. Дополнительную информацию см. в разделе Добавление стандартных хостов в Менеджер управления.

Поддержка работы в сетях IPv6

В большинстве ситуаций zVirt поддерживает статическую адресацию в IPv6-сетях.

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

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

Поддерживается только статическая IPv6-адресация. Динамическая IPv6-адресация с DHCP или Автоматическая конфигурация адресов без сохранения состояния (Stateless Address Autoconfiguration) не поддерживаются.
Одновременная адресация IPv4 и IPv6 не поддерживается.
При работе в OVN-сетях может использоваться только IPv4 или IPv6.
Переключение кластеров от использования IPv4 к IPv6 не поддерживается.
Для IPv6 можно задать только один шлюз на хост.
Если обе сети используют один шлюз (находятся в одной подсети), то можно передать роль маршрута по умолчанию от сети управления (ovirtmgmt) другой логической сети. Хост и Менеджер управления должны иметь один и тот же шлюз IPv6. Если хост и Менеджер управления находятся в разных подсетях, то Менеджер управления может потерять связь с хостом, поскольку шлюз IPv6 был удален.
Использование домена хранения glusterfs с сервером gluster, имеющим IPv6-адрес, не поддерживается.

Установка и настройка SR-IOV

В этом разделе описаны шаги по установке и настройке SR-IOV со ссылками на разделы, подробно описывающие каждый шаг.

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

Настройте сквозной доступ PCI на хосте.
Измените конфигурацию виртуальных функций на сетевой карте.
Включите сквозной доступ (passthrough) в Профиле vNIC.
Настройте виртуальные машины с виртуальными сетевыми картами (vNIC) с включенным SR-IOV, чтобы уменьшить время неработоспособности сети во время миграции.

Количество виртуальных сетевых карт со сквозным доступом зависит от количества доступных виртуальных функций (VF) на хосте. Например, чтобы запустить виртуальную машину (ВМ) с тремя картами SR-IOV (vNIC), на хосте должны быть включены как минимум три виртуальные функции.
Поддерживаются горячее подключение и отключение.
Поддерживается миграция во время работы.
Для переноса виртуальной машины на хосте-приемнике также должно быть достаточно доступных виртуальных функций, чтобы ее принять. Во время миграции виртуальная машина высвобождает ряд виртуальных функций на хосте-источнике и занимает такое же количество виртуальных функций на хосте-приемнике.
На хосте устройство, канал или ifcae будут отображаться как любой другой интерфейс. Это устройство исчезнет, когда будет подключено к виртуальной машине, и снова появится, когда будет освобождено.
Избегайте подключения устройства хоста непосредственно к виртуальной машине для реализации функции SR-IOV.

Вот пример того, как может выглядеть libvirt XML для интерфейса:

----
<interface type='hostdev'>
    <mac address='00:1a:yy:xx:vv:xx'/>
    <driver name='vfio'/>
    <source>
<address type='pci' domain='0x0000' bus='0x05' slot='0x10' function='0x0'/>
    </source>
    <alias name='ua-18400536-5688-4477-8471-be720e9efc68'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</interface>
----

Поиск и устранение неполадок

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

# ip -s link show dev enp5s0f0

1: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 86:e2:ba:c2:50:f0 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    30931671   218401   0       0       0       19165434
    TX: bytes  packets  errors  dropped carrier collsns
    997136     13661    0       0       0       0
    vf 0 MAC 02:00:00:00:00:01, spoof checking on, link-state auto, trust off, query_rss off
    vf 1 MAC 00:1a:4b:16:01:5e, spoof checking on, link-state auto, trust off, query_rss off
    vf 2 MAC 02:00:00:00:00:01, spoof checking on, link-state auto, trust off, query_rss off

2.4.5. Объединение сетевых интерфейсов (бондинг)

2.4.5.1. Методы бондинга

При бондинге несколько сетевых карт объединяются в одно бонд-устройство; это дает следующие преимущества:

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

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

Для используемого по умолчанию в zVirt режима бондинга (Mode 4) Dynamic Link Aggregation требуется коммутатор, поддерживающий 802.3ad.

Логические сети bond-интерфейса должны быть совместимы. Bond-интерфейс может поддерживать только одну логическую сеть, не являющуюся виртуальной локальной сетью (VLAN). Остальные логические сети должны иметь уникальные идентификаторы (ID) VLAN.

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

Создать bond-интерфейс можно одним из следующих способов:

Вручную на Портале администрирования для конкретного хоста
Автоматически с помощью службы LLDP Labeler для необъединенных сетевых карт всех хостов в кластере или центре данных

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

2.4.5.2. Создание Bond-интерфейса на Портале администрирования

Bond-интерфейс можно создать на определенном хосте на Портале администрирования. Bond-интерфейс может передавать как тегированный трафик VLAN, так и нетегированный трафик.

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите имя хоста. Откроется подробное представление.
Нажмите вкладку Сетевые интерфейсы (Network Interfaces), чтобы просмотреть список физических сетевых интерфейсов, подключенных к хосту.
Нажмите Настройка сетей хоста (Setup Host Networks).
Проверьте конфигурацию коммутатора. Если коммутатор настроен на предоставление информации Link Layer Discovery Protocol (LLDP), то наведите указатель мыши на физическую сетевую карту, чтобы просмотреть конфигурацию агрегирования порта коммутатора.

Перетащите сетевую карту на другую сетевую карту или на Bond-интерфейс.

Две сетевые карты образуют новый Bond-интерфейс. Сетевая карта и Bond-интерфейс добавляют сетевую карту к существующему Bond-интерфейсу.

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

В выпадающих меню выберите Имя Bond (Bond Name) и Режим бондинга (Bonding Mode). Подробности см. в разделе Режимы бондинга.
При выборе режима Настраиваемый (Custom) можно ввести параметры бондинга в текстовом поле Пользовательский режим, как показано в следующих примерах:
- Если среда не сообщает о состоянии канала с помощью программы ethtool, то можно настроить мониторинг ARP, введя mode=1 arp_interval=1 arp_ip_target=192.168.0.2.
- Сетевую карту с более высокой пропускной способностью можно назначить основным интерфейсом, введя mode=1 primary=eth0.
Полный список параметров бондинга и их описания см. в документе Linux Ethernet Bonding Driver HOWTO на сайте Kernel.org.
Нажмите OK.
Подключите логическую сеть к новому Bond-интерфейсу и настройте ее. Инструкции см. в разделе Изменение сетевых интерфейсов хоста и назначение логических сетей хостам.

Логическую сеть нельзя подключить напрямую к отдельной сетевой карте на Bond-интерфейсе.
При желании можно выбрать Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine), если хост находится в режиме обслуживания.
Нажмите OK.

2.4.5.3. Создание Bond-интерфейса с помощью службы LLDP Labeler

Служба LLDP Labeler позволяет автоматически создать Bond-интерфейс со всеми необъединенными сетевыми картами для всех хостов в одном или нескольких кластерах или во всем центре данных. Создаваемый режим бондинга - (Mode 4) Динамическая агрегация каналов (802.3ad).

Нельзя объединять сетевые карты с несовместимыми логическими сетями.

Настройка службы LLDP Labeler

По умолчанию служба LLDP Labeler запускается раз в час. Этот вариант полезен, если вы меняете оборудование (например, сетевые карты, коммутаторы или кабели) или конфигурацию коммутаторов.

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

Интерфейсы должны быть подключены к коммутатору Juniper.
Коммутатор Juniper должен быть настроен для протокола управления агрегацией каналов (Link Aggregation Control Protocol, LACP) с использованием LLDP.

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

Задайте username и password в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf:
- username - имя администратора Менеджера управления. Значение по умолчанию - admin@internal.
- password - пароль администратора Менеджера управления. Значение по умолчанию - 123456.
Настройте службу LLDP Labeler, обновив следующие значения в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf:
- clusters - разделенный запятыми список кластеров, на которых должна работать служба. Символы подстановки поддерживаются. Например, значение Cluster* предпишет службе LLDP Labeler запуститься на всех кластерах, имя которых начинается со слова Cluster. Для запуска службы на всех кластерах в центре данных введите . Значение по умолчанию - Def.
- api_url - полный URL-адрес API Менеджера управления. Значение по умолчанию – https://<Manager_FQDN>/ovirt-engine/api
- ca_file - путь к файлу сертификата, выданного альтернативным Центром сертификации. Если альтернативные сертификаты не используются, оставьте значение empty. По умолчанию - empty.
- auto_bonding - включает функции бондинга, имеющиеся у службы LLDP Labeler. Значение по умолчанию - true.
- auto_labeling - включает функции присвоения меток, имеющиеся у службы LLDP Labeler. Значение по умолчанию - true.
При желании можно настроить службу на запуск с другой периодичностью, изменив значение OnUnitActiveSec в /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-labeler.timer. Значение по умолчанию - 1h.
Настройте службу на запуск прямо сейчас и при загрузке, введя следующую команду:
# systemctl enable --now ovirt-lldp-labeler
Чтобы вызвать службу вручную, введите следующую команду:
# /usr/bin/python /usr/share/ovirt-lldp-labeler/ovirt_lldp_labeler_cli.py
Подключите логическую сеть к новому объединенному сетевому устройству и настройте ее. Инструкции см. в разделе Изменение сетевых интерфейсов хоста и назначение логических сетей хостам.

Логическую сеть нельзя подключить напрямую к отдельной сетевой карте на Bond-интерфейсе.

2.4.5.4. Режимы бондинга

Алгоритм распределения пакетов определяется режимом бондинга (Подробности см. в документе Linux Ethernet Bonding Driver HOWTO). В zVirt режим бондинга по умолчанию - это (Mode 4) Динамическая агрегация каналов (802.3ad).

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

(Mode 1) Active-Backup

Активна одна сетевая карта. Если активная сетевая карта выйдет из строя, то одна из резервных сетевых карт заменит ее как единственную активную сетевую карту в Bond-интерфейсе. MAC-адрес этого Bond-интерфейса виден только на порту сетевого адаптера. Это предотвращает путаницу с MAC-адресами, которая может возникнуть, если MAC-адрес Bond-интерфейса изменится и будет показывать MAC-адрес новой активной сетевой карты.

(Mode 2) Load Balance (balance-xor)

Сетевая карта, которая передает пакеты, выбирается путем выполнения операции XOR над MAC-адресом источника и MAC-адресом приемника и умножения на modulo общего количества сетевых карт. Этот алгоритм обеспечивает выбор одной и той же сетевой карты для каждого MAC-адреса приемника.

(Mode 3) Broadcast

Пакеты передаются на все сетевые карты.

(Mode 4) Dynamic Link Aggregation(802.3ad) (Default)

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

Для (Mode 4) Dynamic Link Aggregation(802.3ad) требуется коммутатор, поддерживающий 802.3ad.

Объединенные сетевые карты должны иметь одинаковые идентификаторы агрегатора. Иначе на вкладке Сетевые интерфейсы (Network Interfaces) Менеджер управления покажет предупреждающий значок с восклицательным знаком на Bond-интерфейсе, а параметр ad_partner_mac Bond-интерфейса будет иметь значение: 00:00:00:00:00:00. Чтобы проверить идентификаторы агрегатора, введите следующую команду:

# cat /proc/net/bonding/bond0

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

(Mode 0) Round-Robin: Сетевые карты передают пакеты в последовательном порядке. Пакеты передаются по циклу, который начинается с первой доступной сетевой карты в Bond-интерфейсе и заканчивается последней доступной сетевой картой в нем. Последующие циклы начинаются с первой доступной сетевой карты.
(Mode 5) Balance-TLB (так же называемый Transmit Load-Balance): Исходящий трафик распределяется в зависимости от нагрузки по всем сетевым картам в Bond-интерфейсе. Входящий трафик принимается активной сетевой картой. Если сетевая карта, получающая входящий трафик, выйдет из строя, то будет назначена другая сетевая карта.
(Mode 6) Balance-ALB (так же называемый Adaptive Load-Balance): (Mode 5) Balance-TLB сочетается с балансировкой нагрузки по приему для трафика IPv4. Для балансировки нагрузки по приему используется согласование ARP.

2.5. Хосты

2.5.1. Общие сведения о хостах

Хосты, также именуемые гипервизорами – это физические серверы, на которых работают виртуальные машины. Полная виртуализация обеспечивается благодаря использованию загружаемого модуля ядра Linux, который носит название Kernel-based Virtual Machine (KVM).

KVM позволяет одновременно запускать несколько виртуальных машин под управлением Windows или Linux. Виртуальные машины работают как отдельные Linux процессы и потоки на хост-машине, а дистанционное управление ими осуществляет Менеджер управления. К среде zVirt подключены один или несколько хостов.

Для установки хостов zVirt используйте установочный носитель zVirt Node.

Тип отдельного хоста можно узнать в Менеджере управления, выбрав имя нужного хоста. Откроется подробное представление. Затем посмотрите Описание ОС (OS Description) в разделе Программное обеспечение (Software).

Хосты используют профили tuned, обеспечивающие оптимизацию виртуализации.

В среде исполнения zVirt включены функции безопасности. Security Enhanced Linux (SELinux) и межсетевой экран полностью настроены и включены по умолчанию. Состояние SELinux на выбранном хосте отображается под заголовком Режим SELinux (SELinux mode) на вкладке Общие (General) в подробном представлении. Менеджер управления может открывать необходимые порты на хостах, когда он добавляет их в среду.

Хост – это физический 64-разрядный сервер с расширениями AMD-V™ или Intel VT®, на котором работает соответствующая версия ОС.

Физический хост на платформе zVirt:

Должен принадлежать только одному кластеру в системе.
Должен иметь ЦП, которые поддерживают расширения для виртуализации аппаратного обеспечения AMD-V™ или Intel VT®.
Должен иметь ЦП, поддерживающие всю функциональность, предоставляемую типом виртуального процессора, который был выбран при создании кластера.
Должен иметь объем ОЗУ не менее 4 ГБ.
Может иметь назначенного системного администратора с системными разрешениями.

2.5.2. Среда исполнения zVirt Node

Среда исполнения zVirt Node устанавливается с помощью специальной сборки, содержащей только те пакеты, которые необходимы для хостинга виртуальных машин. Она использует интерфейс установки Anaconda и может обновляться с помощью Менеджера управления или команд yum или dnf. Использование команд yum и dnf - это единственный способ установить дополнительные пакеты.

zVirt Node имеет веб-интерфейс Cockpit для мониторинга ресурсов хоста и выполнения административных задач. Веб-интерфейс Cockpit предлагает графический пользовательский интерфейс для задач, которые выполняются до добавления хоста в Менеджер управления, таких как настройка сети или выполнение терминальных команд на вкладке Терминал (Terminal).

Для доступа к веб-интерфейсу Cockpit в веб-браузере введите https://<HostFQDNorIP>:9090. В Cockpit для zVirt Node есть настраиваемый дашборд Virtualization, отображающий состояние хоста, SSH ключ хоста, статус hosted engine, виртуальные машины и статистику виртуальных машин.

zVirt Node использует инструмент автоматического создания отчетов об ошибках (ABRT) для сбора значимой отладочной информации о сбоях приложений.

Пользовательские аргументы ядра загрузки можно добавить в zVirt Node с помощью инструмента grubby. Инструмент grubby вносит постоянные изменения в файл grub.cfg. Перейдите на вложенную вкладку Терминал (Terminal) в веб-интерфейсе хоста Cockpit для использования команд grubby.

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

2.5.3. Задачи в отношении хоста

2.5.3.1. Добавление стандартных хостов в Менеджер управления

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

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

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

На Портале администрирования выберите Ресурсы (Compute) Хосты (Hosts).
Нажмите Новый (New).
В выпадающем списке Хост кластера (Host Cluster) выберите Центр данных (Data Center) и Кластер для нового хоста.
Введите имя и адрес нового хоста в поля Имя (Name) и FQDN/IP. Стандартный для SSH порт 22 автоматически вводится в поле Порт SSH (SSH Port).
Выберите способ аутентификации, который Менеджер управления будет использовать для доступа к хосту:
- Укажите пароль root-пользователя, чтобы использовать аутентификацию по паролю.
- Либо скопируйте ключ, отображаемый в поле Публичный ключ SSH (SSH PublicKey), в /root/.ssh/authorized_keys на хосте, чтобы использовать аутентификацию по открытому ключу.
При желании можно нажать Дополнительные параметры (Advanced Parameters), чтобы изменить следующие дополнительные настройки хоста:
- Отключить автоматическую настройку межсетевого экрана.
- Добавить Публичный ключ SSH хоста, чтобы повысить безопасность. Его можно добавить вручную или подтянуть автоматически.
При необходимости настройте управление питанием, если хост имеет поддерживаемую карту с управлением питания. Информацию о настройках параметров управления питанием см. в разделе Описание настроек управления питанием хоста.
Нажмите OK.

Новый хост отображается в списке хостов со статусом Установка (Installing) ; за ходом установки можно следить в разделе События (Events) EventsIcon на Панели уведомлений (Notification Drawer). После небольшой задержки статус хоста изменится на Включен (Up) running .

2.5.3.2. Настройка хоста для сквозного доступа PCI

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

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

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

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

Настройка хоста для сквозного доступа PCI

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

Включите расширение виртуализации и расширение IOMMU в BIOS.
Включите флаг IOMMU в ядре, установив флажок Passthrough устройств хоста и SR-IOV (Hostdev Passthrough & SR-IOV) при добавлении хоста в Менеджер управления или изменив конфигурационный файл grub вручную.
- Чтобы включить флаг IOMMU на Портале администрирования, см. разделы Добавление стандартных хостов в Менеджер управления и Описание настроек ядра.
- Чтобы изменить конфигурационный файл grub вручную, см. Включение IOMMU вручную.
Для включения сквозного доступа к графическому процессору нужно выполнить дополнительные действия по настройке как на хосте, так и в гостевой системе. Дополнительную информацию см. в документе Настройка прямого проброса видеокарты NVIDIA в виртуальную машину (zVirt 3.Х)

Включение IOMMU вручную

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

Включите IOMMU, изменив конфигурационный файл grub.

Если используется Intel, загрузите машину и добавьте intel_iommu=on в конец строки GRUB_CMDLINE_LINUX в конфигурационном файле grub.
```
# vi /etc/default/grub
...
GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... intel_iommu=on
...
```

Если используется AMD, загрузите машину и добавьте amd_iommu=on в конец строки GRUB_CMDLINE_LINUX в конфигурационном файле grub.

# vi /etc/default/grub
...
GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... amd_iommu=on
...

В случае обнаружения intel_iommu=on или amd_iommu=on можно попытаться добавить iommu=pt. Опция pt включает IOMMU только для устройств в сквозном доступе и обеспечивает более высокую производительность хоста. Однако эта опция поддерживается не на всем оборудовании. Если опция pt для вашего хоста не работает, вернитесь к предыдущей опции.

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

# vi /etc/modprobe.d
options vfio_iommu_type1 allow_unsafe_interrupts=1

Обновите файл grub.cfg и перезагрузите хост, чтобы эти изменения вступили в силу:
```
# grub2-mkconfig -o /boot/grub2/grub.cfg
# reboot
```

2.5.3.3. Включение вложенной виртуализации

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

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

Вложенная виртуализация позволяет одним виртуальным машинам осуществлять хостинг других виртуальных машин. Для ясности назовем их родительскими виртуальными машинами (parent virtual machines) и вложенными виртуальными машинами (nested virtual machines).

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

По умолчанию вложенная виртуализация в zVirt выключена. Чтобы включить вложенную виртуализацию, установите хук VDSM vdsm-hook-nestedvt на все хосты в кластере. Затем все виртуальные машины, работающие на этих хостах, смогут работать как родительские.

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

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

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

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
Выберите хост в кластере, где хотите включить вложенную виртуализацию, и нажмите Управление (Management) → Обслуживание (Maintenance) и затем OK.
Выберите хост снова, нажмите Консоль хоста (Host Console) и авторизуйтесь на консоли хоста.
Установите хук VDSM:
```
# dnf install vdsm-hook-nestedvt
```
Перезагрузите хост.
Снова авторизуйтесь на консоли хоста и убедитесь, что вложенная виртуализация включена:
$ cat /sys/module/kvm*/parameters/nested
Если эта команда вернет Y или 1, то вложенная виртуализация включена.
Повторите эту процедуру для всех хостов в кластере.
Дополнительные ресурсы
Хуки VDSM

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

Вложенные виртуальные машины видимы и управляются только пользователями, имеющими доступ к родительской виртуальной машине. Они невидимы для администраторов zVirt (RHV).

Чтобы включить вложенную виртуализацию не на всех, а лишь на некоторых виртуальных машинах, настройте хост или хосты на поддержку вложенной виртуализации. Затем настройте виртуальную машину или виртуальные машины на запуск на этих конкретных хостах и включите Сквозной доступ ЦП хоста (Pass-Through Host CPU). Эта опция позволяет виртуальным машинам использовать настройки вложенной виртуализации, которые вы только что задали на хосте. Эта опция также указывает, на каких хостах могут работать виртуальные машины, и требует ручной миграции.

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

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

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

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

Настройка хостов на поддержку вложенной виртуализации

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

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
Выберите хост в кластере, где хотите включить вложенную виртуализацию, и нажмите Управление (Management)→ Обслуживание (Maintenance) и затем OK.
Выберите хост снова, нажмите Консоль хоста (Host Console) и авторизуйтесь на консоли хоста.
В окне Изменить хост (Edit Host) выберите вкладку Ядро (Kernel).
Если в блоке Параметры загрузки ядра (Kernel boot parameters) флажки неактивны, нажмите Сброс (RESET).
Выберите Вложенная виртуализация (Nested Virtualization) и нажмите OK.

Это действие выведет параметр kvm-<architecture>.nested=1 в Командной строке ядра (Kernel command line). Выполнение следующих действий добавит этот параметр в Текущую cmdline ядра (Current kernel CMD line).
Нажмите Настройки (Installation) → Переустановить (Reinstall).
Когда хост вернется в состояние Включен (Up) , нажмите Управление (Management) → Перезапустить (Restart)*в блоке Управление питанием (Power Management) или Управление SSH (SSH Management).
Убедитесь, что вложенная виртуализация включена. Авторизуйтесь на консоли хоста и введите:
$ cat /sys/module/kvm*/parameters/nested
Если эта команда вернет Y или 1, то вложенная виртуализация включена.
Повторите эту процедуру для всех хостов, на которых нужно запускать родительские виртуальные машины.

Включение вложенной виртуализации на отдельных виртуальных машинах

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

На Портале администрирования нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Выберите виртуальную машину и нажмите Изменить (Edit).
В окне Изменить виртуальную машину (Edit Vitual Machine) нажмите Показать расширенные настройки (Show Advanced Options) и выберите вкладку Хост (Host).
В блоке Запустить на (Start Running On) нажмите Указанном хосте (Specific Host) и выберите хост или хосты, которые вы настроили на поддержку вложенной виртуализации.
В блоке Параметры ЦП (CPU Options) выберите Passthrough ЦП хоста (Pass-Through Host CPU). Это действие автоматически установит Режим миграции (Migration mode) в значение Разрешить только ручную миграцию (Allow manual migration only).

2.5.3.4. Перевод хоста в режим обслуживания

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

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

Виртуальные машины, которые закреплены за хостом и не могут быть перенесены, выключаются. Чтобы выяснить, какие виртуальные машины закреплены за хостом, нажмите Прикреплён к текущему хосту (Pinned to Host) на вкладке Виртуальные машины (Virtual Machines) в подробном представлении хоста.

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите нужный хост.
Нажмите Управление (Management) → Обслуживание (Maintenance). Откроется окно подтверждения Обслуживание хоста (Maintenance Host(s)).
Если нужно, укажите Причину (Reason) перевода хоста в режим обслуживания, которая будет отображаться в журналах и при повторной активации хоста. Затем нажмите OK
Если нужно, установите необходимые флажки для хостов, поддерживающих Gluster.

Установите флажок в поле Игнорировать кворум Gluster и проверки в целях самовосстановления (Ignore Gluster Quorum and Self-Heal Validations), чтобы избежать выполняемых по умолчанию проверок. По умолчанию Менеджер управления проверяет, не потеряется ли кворум Gluster при переводе хоста в режим обслуживания. Менеджер управления также проверяет, не выполняется ли операция самовосстановления, которую может затронуть перевод хоста в режим обслуживания. Если будет потерян кворум Gluster или затронута операция самовосстановления, Менеджер управления не позволит перевести хост в режим обслуживания. Устанавливайте этот флажок только в том случае, если нет другого способа перевести хост в режим обслуживания.

Установите флажок в поле Остановить службу Gluster (Stop Gluster Service), чтобы остановить все службы Gluster при переводе хоста в режим обслуживания.

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

Все работающие виртуальные машины переносятся на альтернативные хосты. Если хост выполняет роль Менеджера пула хранения (SPM), то эта роль переносится на другой хост. Поле Статус (Status) хоста меняется на Подготовка к обслуживанию (Preparing for Maintenance) host prepare to migrate и наконец на Обслуживание (Maintenance) host maintenance , когда операция успешно завершается. VDSM не останавливается, пока хост находится в режиме обслуживания.

Если миграция какой-либо виртуальной машины заканчивается неудачей, нажмите Управление (Management) → Включить (Activate) на хосте, чтобы остановить операцию перевода в режим обслуживания, затем нажмите Отменить миграцию (Cancel Migration) на виртуальной машине, чтобы остановить миграцию.

2.5.3.5. Активация хоста из режима обслуживания

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Включить (Activate).

Статус хоста меняется на Unassigned stat down и наконец на Включен (Up) running , когда операция завершается. Теперь на хосте могут работать виртуальные машины. Виртуальные машины, которые были перенесены с хоста при его переводе в режим обслуживания, не переносятся автоматически обратно на хост при его активации, но их можно перенести вручную. Если перед переводом в режим обслуживания хост выполнял роль Менеджера пула хранения, эта роль не возвращается автоматически при активации хоста.

2.5.3.6. Настройка правил межсетевого экрана для хостов

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

Изменение зоны firewalld не поддерживается.

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

Чтобы добавить пользовательский порт межсетевого экрана, в машине Менеджера управления измените ovirt-host-deploy-post-tasks.yml.example:

# vi /etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml.example
---
#
# Any additional tasks required to be executing during host deploy process can
# be added below
#
- name: Enable additional port on firewalld
firewalld:
    port: "_12345/tcp_"
    permanent: yes
    immediate: yes
    state: enabled

Сохраните файл под именем ovirt-host-deploy-post-tasks.yml.

Новые или переустановленные хосты настраиваются с помощью обновленных правил межсетевого экрана.

Существующие хосты нужно переустановить, нажав Настройки (Installation) → Переустановить (Reinstall) и выбрав Автоматически настроить межсетевой экран хоста (Automatically configure host firewall).

2.5.3.7. Удаление хоста

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance).
Как только хост перейдет в режим обслуживания, нажмите Удалить (Remove). Откроется окно с запросом на подтверждение удаления хостов Удалить хост(ы) (Remove Host(s)).
Если хост является частью кластера Gluster Storage и на нем находятся брики томов либо если хост не реагирует на запросы (non-responsive), то установите флажок Принудительно удалить (Force Remove).
Нажмите OK.

2.5.3.8. Обновление хостов

Процедура обновления зависит от текущей версии zVirt и от режима развертывания (HostedEngine, StandAlone или StandAlone-All-in-One).

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

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

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

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

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

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

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

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

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

2.5.3.10. Просмотр состояния хоста

Кроме обычного Статуса (Status), у хостов есть внешний статус состояния. О внешнем статусе состояния сообщают подключаемые модули или внешние системы, его может задать администратор, и он отображается слева от Имени (Name) хоста в виде одного из следующих значков:

OK: Без значка
Информация (Info):
Предупреждение (Warning):
Ошибка (Error):
Отказ (Failure):

Чтобы просмотреть дополнительные сведения о статусе состояния хоста, нажмите его имя, Откроется подробное представление, далее выберите вкладку События (Events).

Статус состояние хоста также можно посмотреть через REST API. Запрос GET на хост будет включать в себя элемент external_status, который содержит статус состояния.

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

2.5.3.11. Просмотр устройств хоста

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

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

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Устройства хоста (Host Devices).

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

2.5.3.12. Доступ к Cockpit с Портала администрирования

Cockpit доступен по умолчанию на хостах с zVirt Node. Доступ к веб-интерфейсу Cockpit можно получить, набрав адрес в браузере, или через Портал администрирования.

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

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Консоль хоста (Host Console).

В новом окне браузера откроется страница авторизации Cockpit.

2.5.3.13. Настройка устаревшего шифра SPICE

По умолчанию консоли SPICE используют FIPS-совместимое шифрование и строку шифра. По умолчанию используется следующая строка шифра SPICE: kECDHE+FIPS:kDHE+FIPS:kRSA+FIPS:!eNULL:!aNULL

Этой строки обычно бывает достаточно. Однако для виртуальной машины с более старой ОС или более старым клиентом SPICE, где ОС или клиент не поддерживает FIPS-совместимое шифрование, следует использовать более слабую строку шифра. В противном случае может возникнуть ошибка безопасности подключения, если установить новый кластер или новый хост в существующем кластере и попытаться подключиться к этой виртуальной машине.

Можно изменить строку шифра, используя Ansible-плейбук.

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

На машине с Менеджером управления перейдите в каталог /usr/share/ovirt-engine/ansible-runner-service-project/
```
# cd /usr/share/ovirt-engine/ansible-runner-service-project/
```
В подкаталоге project/ cоздайте файл плейбука. Например:
```
# vim project/change-spice-cipher.yml
```
Введите в файл следующие данные и сохраните его:
- name: oVirt - setup weaker SPICE encryption for old clients hosts: <hostname> vars: host_deploy_spice_cipher_string: 'DEFAULT:-RC4:-3DES:-DES' roles: - ovirt-host-deploy-spice-encryption
где, <hostname> - имя хоста или группы хостов, на котором нужно внести изменения.
Запустите только что созданный файл с указанием инвентарного файла:
```
# ansible-playbook ansible-playbook project/change-spice.yml -i inventory/hosts
```

Либо можно переконфигурировать хост Ansible-плейбуком ovirt-host-deploy, используя опцию --extra-vars с переменной host_deploy_spice_cipher_string:

Следующая команда, для сокращения путей, предполагает запуск из каталога /usr/share/ovirt-engine/ansible-runner-service-project/

# ansible-playbook -l _hostname_ \
  --extra-vars host_deploy_spice_cipher_string=”DEFAULT:-RC4:-3DES:-DES” \
  -i inventory/hosts \
  project/ovirt-host-deploy.yml

2.5.3.14. Настройка параметров управления питанием хоста

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

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance), нажмите OK для подтверждения.
Как только хост перейдет в режим обслуживания, нажмите Изменить (Edit).
Откройте вкладку Управление питанием (Power Management).
Отметьте флажком Включить управление питанием (Enable Power Management), чтобы поля стали активными.

Отметьте флажком Интеграция Kdump (Kdump integration), чтобы предотвратить изоляцию хоста, пока создается аварийный дамп ядра.

После включения или выключения Интеграции Kdump (Kdump integration) на существующем хосте необходимо переустановить хост, чтобы можно было сконфигурировать kdump.

При желании можно установить флажок Выключить политику управления питанием (Disable policy control of power management), и тогда питание хоста не будет контролироваться Политикой планирования (Scheduling Policy) кластера, к которому относится этот хост.
Нажмите , чтобы добавить новое устройство управления питанием. Откроется окно Изменить fence-агента (Edit fence agent).
Заполните поля Имя пользователя (User Name) и Пароль (Password) устройства управления питанием.
В выпадающем списке выберите Тип (Type) устройства управления питанием.
Введите IP-адрес в поле Адрес (Address).
Введите номер Порта (Port), который устройство управления питанием использует для связи с хостом.
Введите номер Слота (Slot), который используется для идентификации блейда устройства управления питанием.
Укажите Настройки (Options) устройства управления питанием. Используйте список записей в формате key=значение, разделенных запятыми.
- Если можно использовать и IPv4-адреса, и IPv6-адреса (по умолчанию), то оставьте поле Настройки (Options) пустым.
- Если можно использовать только IPv4-адреса, то введите inet4_only=1.
- Если можно использовать только IPv6-адреса, то введите inet6_only=1.
Поставьте флажок Безопасность (Secure), чтобы позволить устройству управления питанием безопасно соединяться с хостом.
Нажмите Тестировать (Test), чтобы убедиться в правильности настроек. После успешной проверки появится сообщение Test Succeeded, Host Status is: on.
Нажмите OK, чтобы закрыть окно Изменить fence-агента (Edit fence agent).
На вкладке Управление питанием (Power Management) можно при желании развернуть блок Дополнительные параметры (Advanced Parameters) и кнопками "вверх" и "вниз" задать порядок, в котором Менеджер управления будет искать изолирующий прокси в кластере и центре данных хоста.
Нажмите OK.

zVirt поддерживает только статическую адресацию для IPv6.
Одновременная адресация (IPv4 и IPv6) не поддерживается.

Выпадающий список в разделе Управление (Management) → Управление питанием (Power Management) теперь стал активным на Портале администрирования.

2.5.3.15. Настройка параметров для Менеджера пула хранения хоста

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

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Изменить (Edit).
Откройте вкладку SPM.
С помощью кнопок-переключателей выберите для хоста подходящий приоритет SPM.
Нажмите OK.

2.5.3.16. Перенос хостов с ролью hosted engine на другой кластер

Хост с ролью hosted engine mgmt net можно перенести только в центр данных или кластер, в котором работает виртуальная машина с ролью hosted engine . Все хосты с ролью hosted engine должны находиться в одном и том же центре данных и кластере. Необходимо забрать у хоста роль hosted engine mgmt net , удалив конфигурацию hosted engine с хоста.

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance). Статус хоста изменится на Обслуживание (Maintenance) .
Нажмите Настройки (Installation) → Переустановить (Reinstall). Откроется окно Настройка хоста (Install Host).
На вкладке Hosted Engine в выпадающем меню Настроить хост для размещения на нём ВМ HostedEngine (Choose hosted engine deployment action) выберите UNDEPLOY.
Нажмите OK.

Кроме того, можно воспользоваться параметром REST API undeploy_hosted_engine.
После окончания процедуры переустановки и перехода хоста в состояние Включен (UP) снова переведите его в режим обслуживания и нажмите Изменить (Edit).
Выберите целевой центр данных и кластер.
Нажмите OK.
Нажмите Управление (Management) → Включить (Activate).
Дополнительные ресурсы
Перевод хоста в режим обслуживания

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

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

2.5.4.1. Описание общих настроек хоста

В таблице Общие настройки содержится информация, которая должна быть указана на вкладке Общие (General) окон Новый хост (New Host) или Изменить хост (Edit Host).

Имя поля Описание

Хост кластера (Host Cluster)

Кластер и центр данных, к которым относится хост.

Имя (Name)

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

Комментарий (Comment)

Поле для добавления обычного текста в читаемой человеком форме – комментариев, относящихся к хосту.

FQDN/IP (Hostname/IP)

IP-адрес или разрешимое имя хоста. Если используется разрешимое имя хоста, то необходимо убедиться, что все адреса, по которым разрешается имя хоста, соответствуют IPv4- и IPv6-адресам, используемым сетью управления хоста.

Порт SSH (SSH port)

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

Пароль (Password)

Пароль root-пользователя хоста. Установите пароль при добавлении хоста. После этого пароль нельзя изменить.

Включить хост после установки (Activate host after install)

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

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

Перезагрузить хост после установки (Reboot host after install)

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

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

Публичный ключ SSH (SSH Public Key)

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

Автоматически настроить межсетевой экран хоста (Automatically configure host firewall)

При добавлении нового хоста Менеджер управления может открывать требуемые порты на межсетевом экране хоста. Флажок стоит по умолчанию. Это – Дополнительный параметр (Advanced Parameter).

Публичный ключ SSH хоста (Host ssh public key (PEM))

Можно получить (fetch) публичный ключ SSH хоста и сравнить его с ключом, который ожидается от хоста, чтобы убедиться, что они совпадают. Это – Дополнительный параметр (Advanced Parameter).

2.5.4.2. Описание настроек управления питанием хоста

В таблице Настройки Управления питанием содержится информация, которая должна быть указана на вкладке Управление питанием (Power Management) окон Новый хост (New Host) или Изменить хост (Edit Host). Управление питанием можно настроить, если у хоста есть поддерживаемая карта управления питанием.

Таблица 50. Настройки Управления питанием
Имя поля	Описание
Включить управление питанием (Enable Power Management)	Включает управление питанием на хосте. Установите этот флажок, чтобы сделать активными остальные поля на вкладке Управление питанием (Power Management).
Интеграция Kdump (Kdump integration)	Предотвращает изоляцию хоста во время создания аварийного дампа ядра, чтобы процесс не прерывался. Если kdump доступен на хосте, но его конфигурация недействительна (служба kdump не может быть запущена), включение Интеграции Kdump (Kdump integration) приведет тому, что (повторная) установка хоста завершится ошибкой. В этом случае см. раздел Расширенная конфигурация fence_kdump.
Выключить политику управления питанием (Disable policy control of power management)	Управление питанием контролируется Политикой планирования (Scheduling Policy) кластера хоста. Если управление питанием включено и заданный нижний порог загрузки достигнут, то Менеджер управления отключит питание на хосте и перезапустит его снова, когда потребуется балансировка нагрузки или в кластере не будет достаточно свободных хостов. Поставьте флажок, чтобы отключить контроль со стороны этой политики.
Агенты в последовательном порядке (Agents by Sequential Order)	Выдает список агентов изоляции хоста. Агенты изоляции могут быть последовательными, параллельными или сочетать оба варианта. Если агенты изоляции используются последовательно, то для остановки или запуска хоста сначала используется первый агент, а если это не срабатывает, то используется второй агент. Если агенты изоляции используются параллельно, то оба агента изоляции должны отреагировать на команду Stop, чтобы остановить хост. Если один агент отреагирует на команду Start, то хост запустится. По умолчанию агенты изоляции работают последовательно. Чтобы изменить порядок использования агентов изоляции, воспользуйтесь кнопками и . Чтобы два агента изоляции работали параллельно, выберите один агент изоляции из выпадающего списка Параллельно с (Concurrent with) рядом с другим агентом изоляции. К группе параллельных агентов изоляции можно добавить дополнительных агентов изоляции, выбрав группу из выпадающего списка Параллельно с (Concurrent with) рядом с дополнительным агентом изоляции.
Добавить агент управления питанием (Add Fence Agent)	Нажмите , чтобы добавить нового агента изоляции. Откроется окно Изменить fence-агента (Edit fence agent). Более подробная информация о полях этого окна приведена в таблице ниже.
Предпочтения прокси управления питанием (Power Management Proxy Preference)	По умолчанию указано, что Менеджер управления будет искать изолирующий прокси в том же кластере, к которому относится хост, а если изолирующий прокси не найден, то Менеджер управления будет искать его в том же центре данных. Чтобы изменить порядок использования этих ресурсов, воспользуйтесь кнопками и . Это поле доступно в разделе Дополнительные параметры (Advanced Parameters).

В таблице ниже приведена информация, необходимая в окне Изменить fence-агента (Edit fence agent)

Таблица 51. Настройки окна Изменить fence-агента (Edit fence agent)
Имя поля	Описание
Адрес (Address)	Адрес для доступа к устройству управления питанием хоста. Укажите разрешимое имя хоста или IP-адрес.
Имя пользователя (User Name)	Учётная запись пользователя, используемая для доступа к устройству управления питанием. Можно задать пользователя на устройстве или использовать пользователя по умолчанию.
Пароль (Password)	Пароль для пользователя, получающего доступ к устройству управления питанием.
Тип (Type)	Тип устройства управления питанием на хосте. Выберите один из следующих вариантов: `apc` – сетевой переключатель питания APC MasterSwitch. Не подходит для использования с устройствами коммутации питания APC 5.x. `apc_snmp` – используется с устройствами коммутации питания APC 5.x. `bladecenter` – IBM Bladecenter Remote Supervisor Adapter. `cisco_ucs` – Cisco Unified Computing System. `drac5` – Dell Remote Access Controller для компьютеров Dell. `drac7` – Dell Remote Access Controller для компьютеров Dell. `eps` – сетевой переключатель питания ePowerSwitch 8M+. `hpblade` – HP BladeSystem. `ilo`, `ilo2`, `ilo3`, `ilo4`, `ilo_ssh` – HP Integrated Lights-Out. `ipmilan` – Intelligent Platform Management Interface и устройства управления Sun Integrated Lights Out. `redfish` - спецификация и открытый индустриальный стандарт, который пришёл на смену устаревшему IPMI. Он используется для управления серверным оборудованием посредством RESTful интерфейса. `rsa` – IBM Remote Supervisor Adapter. `rsb` – интерфейс управления Fujitsu-Siemens RSB. `wti` – сетевой переключатель питания WTI. Дополнительные сведения об устройствах управления питанием см. в разделе Управление питанием в Техническом справочнике.
Порт (Port)	Номер порта, который устройство управления питанием использует для связи с хостом.
Слот (Slot)	Номер, который используется для идентификации блейда устройства управления питанием.
Профиль службы (Service Profile)	Имя профиля службы, которое используется для идентификации блейда устройства управления питанием. Это поле появляется вместо поля Слот (Slot), когда тип устройства - `cisco_ucs`.
Настройки (Options)	Специальные опции устройства управления питанием. Указываются в формате `key=значение`. См. доступные опции в документации на устройство управления питанием хоста.
Безопасность (Secure)	Поставьте этот флажок, чтобы разрешить устройству управления питанием безопасно соединяться с хостом. Для этого можно использовать ssh, ssl или другие протоколы аутентификации в зависимости от агента управления питанием.

2.5.4.3. Описание настроек приоритета SPM

В таблице Настройки SPM содержится информация, которая должна быть указана на вкладке SPM окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 52. Настройки SPM
Имя поля	Описание
Приоритет SPM (SPM Priority)	Определяет вероятность того, что хосту будет назначена роль SPM. Возможные варианты выбора приоритета: `Никогда` (`Never`) `Низкий` (`Low`) `Нормальный` (`Normal`) `Высокий` (`High`) `Низкий` означает низкую вероятность того, что хосту будет назначена роль SPM, а `Высокий` означает высокую вероятность. По умолчанию выбирается вариант `Нормальный`.

2.5.4.4. Описание настроек консоли хоста

В таблице Настройки консоли (Console settings) содержится информация, которая должна быть указана на вкладке Консоль (Console) окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 53. Настройки консоли (Console settings)
Имя поля	Описание
Переопределить отображаемый адрес (Override display address)	Поставьте этот флажок, чтобы переопределить отображаемый адрес хоста. Это полезная опция, если хосты определяются внутренним IP-адресом и располагаются за межсетевым экраном NAT. Когда пользователь подключается к виртуальной машине не из внутренней сети, виртуальная машина возвращает не частный адрес хоста, на котором она работает, а публичный IP-адрес или FQDN (который разрешается во внешней сети в публичный IP-адрес).
Отображаемый адрес (Display address)	Указанный здесь адрес будет использоваться для всех виртуальных машин, работающих на данном хосте. Адрес должен иметь формат FQDN или IP-адреса.
Размещение vGPU(vGPU Placement)	Указывает предпочтительное размещение vGPU: Объединённый (Consolidated): Выберите этот параметр, если вы предпочитаете использовать больше vGPU на доступных физических картах. Разделённый (Separated): Выберите этот параметр, если вы предпочитаете запускать каждый vGPU на отдельной физической карте.

2.5.4.5. Описание настроек ядра

В таблице Настройки ядра описана информация, которая должна быть указана на вкладке Ядро (Kernel) окон Новый хост (New Host) или Изменить хост (Edit Host). Общие загрузочные параметры ядра перечислены в виде флажков, с которыми легко работать.

Если нужно внести более сложные изменения, используйте текстовое поле для ввода текста в свободной форме рядом с Командной строкой ядра (Kernel command line), чтобы добавить любые необходимые параметры. После изменения любых параметров командной строки ядра переустановите хост.

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

Таблица 54. Настройки ядра
Имя поля	Описание
Passthrough устройств хоста и SR-IOV (Hostdev Passthrough & SR-IOV)	Включает флаг IOMMU в ядре, чтобы виртуальная машина могла использовать устройство хоста, как если бы оно было подключено непосредственно к виртуальной машине. Аппаратное и микропрограммное обеспечение хоста также должны поддерживать IOMMU. На оборудовании должны быть включены расширение виртуализации и расширение IOMMU. См. раздел Настройка хоста для сквозного доступа PCI.
Вложенная виртуализация (Nested Virtualization)	Включает флаг vmx или svm, позволяющий виртуальным машинам работать внутри виртуальных машин. Вложенная виртуализация – это предварительная версия технологии, представленная для оценки (Technology Preview): Она предназначена только для оценки и не поддерживается в продуктивных средах. Чтобы использовать эту настройку, установите хук `vdsm-hook-nestedvt` на хосте. Дополнительную информацию см. в разделе Включение вложенной виртуализации
Небезопасные прерывания (Unsafe Interrupts)	Если IOMMU включен, но сквозной доступ не работает из-за того, что оборудование не поддерживает переназначение прерываний, можно попробовать установить этот флажок. Имейте в виду, что эту опцию следует включать только в том случае, если виртуальные машины на хосте являются доверенными, так как она потенциально подвергает хост MSI-атакам со стороны виртуальных машин. Выбирайте эту опцию только в качестве обходного решения при использовании несертифицированного оборудования в ознакомительных целях.
Перераспределение PCI (PCI Reallocation)	Если сетевая карта SR-IOV не может назначить виртуальные функции из-за проблем с памятью, попробуйте включить эту опцию. Аппаратное и микропрограммное обеспечение хоста также должны поддерживать переназначение PCI-устройств. Выбирайте эту опцию только в качестве обходного решения при использовании несертифицированного оборудования в ознакомительных целях.
Заблокировать Nouveau (Blacklist Nouveau)	Блокирует драйвер nouveau. Nouveau – это неофициальный драйвер для графических процессоров NVIDIA, который конфликтует с вендорскими драйверами. Драйвер nouveau следует блокировать, когда приоритет отдается вендорским драйверам.
Отключить SMT (SMT Disabled)	Отключает одновременную многопоточность (SMT). Отключение SMT может ослабить уязвимости, такие как L1TF или MDS.
FIPS mode	Включает режим FIPS. Дополнительную информацию см. в разделе Настройка хостов FIPS с помощью Менеджера управления.
Командная строка ядра (Kernel command line)	Это поле позволяет добавить дополнительные параметры ядра к параметрам по умолчанию.

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

2.5.4.6. Описание настроек Hosted Engine

В таблице Настройки Hosted Engine описана информация, которая должна быть указана на вкладке Hosted Engine окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 55. Настройки Hosted Engine
Имя поля	Описание
Настроить хост для размещения на нём ВМ HostedEngine (Choose hosted engine deployment action)	Доступны три варианта: `Нет` (`None`) – никакие действия не требуются. `Да` (`Deploy`) – выберите эту опцию, чтобы развернуть хост как узел с ролью hosted engine.

Выбор опции Настроить хост для размещения на нём ВМ HostedEngine (Choose hosted engine deployment action) влияет на роль Hosted Engine только для новых хостов. Для изменения роли Hosted Engine для уже добавленных хостов, используйте вкладку Hosted Engine в окне Настройка хоста, появляющееся в процессе переустановки хоста

2.5.5. Устойчивость хоста

2.5.5.1. Высокая доступность хоста

Менеджер управления использует изоляцию, чтобы поддерживать хосты в кластере в состоянии "responsive" (т.е. когда они реагируют на запросы). Хост, не реагирующий на запросы (Non Responsive) – это не то же самое, что неработоспособный (Non Operational) хост. Неработоспособные (Non Operational) хосты имеют неверную конфигурацию (например, у них отсутствует логическая сеть), но Менеджер управления может связаться с ними. С хостами, не реагирующими на запросы (Non Responsive), Менеджер управления связаться не может.

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

Для автоматической проверки параметров изоляции можно настроить параметры engine-config: PMHealthCheckEnabled (по умолчанию – false) и PMHealthCheckIntervalInSec (по умолчанию – 3600 секунд).

Если установить параметр PMHealthCheckEnabled в значение true, то он будет проверять все агенты хоста с периодичностью, указанной в параметре PMHealthCheckIntervalInSec, и выдавать предупреждения при обнаружении проблем. Дополнительную информацию о настройке параметров engine-config см. в разделе Синтаксис команды engine-config.

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

После запуска Менеджера управления он – по истечении времени ожидания (по умолчанию – 5 минут) – автоматически пытается изолировать не реагирующие на запросы хосты, для которых включено управление питанием. Время ожидания можно настроить, изменив значение параметра engine-config DisableFenceAtStartupInSec.

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

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

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

2.5.5.2. Управление питанием с прокси в zVirt

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

Варианты выбора:

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

Работоспособный изолирующий прокси-хост имеет статус либо Включен (UP) running , либо Обслуживание (Maintenance) host maintenance .

2.5.5.3. Установка параметров изоляции на хосте

Параметры изоляции хостов устанавливаются с помощью полей Управление питанием (Power Management) окон Новый хост (New Host) или Изменить хост (Edit Host). Управление питанием позволяет системе изолировать проблемный хост, используя дополнительный интерфейс, такой как карта удаленного доступа (RAC).

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Изменить (Edit).
Откройте вкладку Управление питанием (Power Management).
Установите флажок в поле Включить управление питанием (Enable Power Management), чтобы активировать поля.

Установите флажок Интеграция kdump (Kdump integration), чтобы предотвратить изолирование хоста, пока создается аварийный дамп ядра.

После установки или снятия флажка Интеграция kdump (Kdump integration) на имеющемся хосте необходимо переустановить хост.

При желании можно установить флажок Выключить политику управления питанием (Disable policy control of power management), и тогда питание хоста не будет контролироваться Политикой планирования (Scheduling Policy) кластера, к которому относится этот хост.
Нажмите , чтобы добавить новое устройство управления питанием. Откроется окно Изменить fence-агента (Edit fence agent).
Введите Адрес (Address), Имя пользователя (User Name) и Пароль (Password) устройства управления питанием.
В выпадающем списке выберите Тип (Type) устройства управления питанием.
Введите номер Порта (Port), который устройство управления питанием использует для связи с хостом.
Введите номер Слота (Slot), используемый для идентификации блейда устройства управления питанием.
Введите Настройки (Options) для устройства управления питанием. Используйте список записей в формате key=значение, разделенных запятыми.
Поставьте флажок Безопасность (Secure), чтобы позволить устройству управления питанием безопасно соединяться с хостом.

Нажмите Тестировать (Test), чтобы убедиться в правильности настроек. После успешной проверки появится сообщение Проверка прошла успешно, Статус хоста: включен (Test Succeeded, Host Status is: on).

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

Нажмите OK, чтобы закрыть окно Изменить fence-агента (Edit fence agent).
На вкладке Управление питанием (Power Management) при желании можно развернуть блок Дополнительные параметры (Advanced Parameters) и кнопками и задать порядок, в котором Менеджер управления будет искать изолирующий прокси в кластере и центре данныххоста.
Нажмите OK.

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

2.5.5.4. Расширенная конфигурация fence_kdump

kdump

Нажмите на имя хоста, чтобы увидеть статус службы kdump на вкладке Общие (General) подробного представления:

Включено (Enabled): служба kdump настроена правильно и работает.
Выключено (Disabled): служба kdump не работает (в этом случае интеграция kdump не будет работать должным образом).
Неизвестно (Unknown): так бывает только у хостов с более ранней версией VDSM, которая не сообщает статус kdump.

fence_kdump

Включение Интеграции kdump (Kdump integration) на вкладке Управление питанием (Power Management) окон Новый хост (New Host) или Изменить хост (Edit Host) формирует стандартную конфигурацию fence_kdump. Если сетевая конфигурация среды проста, а FQDN Менеджера управления разрешимо на всех хостах, то для использования достаточно стандартных настроек fence_kdump.

Однако бывает и так, что нужна расширенная конфигурация fence_kdump. В средах с более сложной организацией сети, возможно, потребуется вручную изменить конфигурацию Менеджера управления, прослушивающего процесса fence_kdump либо того и другого. Например, если FQDN Менеджера управления не разрешимо на всех хостах с включенной опцией Интеграция kdump (Kdump integration), можно указать нужное имя или IP-адрес хоста с помощью engine-config:

engine-config -s FenceKdumpDestinationAddress=_A.B.C.D_

Ниже приведены еще примеры, когда может потребоваться изменение конфигурации:

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

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

2.5.5.5. Конфигурация прослушивающего процесса fence_kdump

Измените конфигурацию прослушивающего процесса fence_kdump. Это необходимо только тогда, когда конфигурации по умолчанию недостаточно.

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

Создайте новый файл (например, my-fence-kdump.conf) в /etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/.

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

Отредактированные значения нужно также изменить в engine-config, как указано в таблице Параметры конфигурации kdump в разделе Настройка fence_kdump в Менеджере управления.

Перезапустите прослушивающий процесс fence_kdump:
```
# systemctl restart ovirt-fence-kdump-listener.service
```

При необходимости можно изменить следующие параметры:

Таблица 56. Параметры конфигурации прослушивающего процесса fence_kdump**
Переменная	Описание	Значение по умолчанию	Примечание
`LISTENER_ADDRESS`	Определяет IP-адрес, на который будут приниматься сообщения fence_kdump.	`0.0.0.0`	Если значение этого параметра будет изменено, то оно должно соответствовать значению параметра `FenceKdumpDestinationAddress` в engine-config.
`LISTENER_PORT`	Определяет порт, на который будут приниматься сообщения fence_kdump.	`7410`	Если значение этого параметра будет изменено, то оно должно соответствовать значению параметра `FenceKdumpDestinationPort` в engine-config.
`HEARTBEAT_INTERVAL`	Определяет интервал (в секундах) между сигналами работоспособности прослушивающего процесса.	`30`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза меньше значения параметра `FenceKdumpListenerTimeout` в engine-config.
`SESSION_SYNC_INTERVAL`	Определяет интервал (в секундах) синхронизации сеансов, во время которых в памяти прослушивающий процесс создает дамп ядра хоста, с базой данных.	`5`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза меньше значения параметра `KdumpStartedTimeout` в engine-config.
`REOPEN_DB_CONNECTION_INTERVAL`	Определяет интервал (в секундах) до следующей попытки установить соединение с базой данных, которая до этого была недоступна.	`30`	-
`KDUMP_FINISHED_TIMEOUT`	Определяет максимальное время ожидания (в секундах) после получения последнего сообщения от хостов, создающих дамп ядра, после чего поток kdump хоста помечается как Завершенный (FINISHED).	`60`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза больше значения параметра `FenceKdumpMessageInterval` в engine-config.

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

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

# engine-config -g _OPTION_

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

Измените конфигурацию kdump командой engine-config:

# engine-config -s _OPTION_=_value_

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

Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```
Если необходимо, переустановите все хосты с включенной Интеграцией kdump (Kdump integration) (см. таблицу ниже).

Следующие параметры можно настроить с помощью engine-config:

Таблица 57. Параметры конфигурации kdump
Переменная	Описание	Значение по умолчанию	Примечание
`FenceKdumpDestinationAddress`	Определяет имя (имена) или IP-адрес (адреса) хоста (хостов), куда будут отправляться сообщения fence_kdump. Пустое поле означает, что используется FQDN Менеджера управления.	Пустая строка (используется FQDN Менеджера управления)	Если значение этого параметра будет изменено, то оно должно соответствовать значению параметра `LISTENER_ADDRESS` в файле конфигурации прослушивающего процесса fence_kdump, а все хосты с включенной Интеграцией kdump (Kdump integration) должны быть переустановлены.
`FenceKdumpDestinationPort`	Определяет порт, на который будут отправляться сообщения fence_kdump.	`7410`	Если значение этого параметра будет изменено, то оно должно соответствовать значению параметра `LISTENER_PORT` в файле конфигурации прослушивающего процесса fence_kdump, а все хосты с включенной Интеграцией kdump (Kdump integration) должны быть переустановлены.
`FenceKdumpMessageInterval`	Определяет интервал (в секундах) между сообщениями, которые отправляет fence_kdump.	`5`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза меньше значения параметра `KDUMP_FINISHED_TIMEOUT` в файле конфигурации прослушивающего процесса fence_kdump, а все хосты с включенной Интеграцией kdump (Kdump integration) должны быть переустановлены.
`FenceKdumpListenerTimeout`	Определяет максимальное время ожидания (в секундах) с момента последнего сигнала работоспособности, в течение которого прослушивающий процесс fence_kdump считается работоспособным.	`90`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза больше значения параметра `HEARTBEAT_INTERVAL` в файле конфигурации прослушивающего процесса fence_kdump.
`KdumpStartedTimeout`	Определяет максимальное время ожидания (в секундах) до получения первого сообщения от хоста, создающего дамп ядра (чтобы определить, что поток kdump хоста запущен).	`30`	Если значение этого параметра будет изменено, то оно должно быть как минимум в два раза больше значения параметра `SESSION_SYNC_INTERVAL` в файле конфигурации прослушивающего процесса fence_kdump и параметра `FenceKdumpMessageInterval`.

2.5.5.7. 2.5.5.7. Программная изоляция хостов

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

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

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

При первом сбое сети статус хоста меняется на Подключается (connecting).
Затем Менеджер управления делает три попытки запросить статус у VDSM или ждет в течение интервала, определяемого нагрузкой на хост. Формула определения длительности интервала задается параметрами конфигурации TimeoutToResetVdsInSeconds (по умолчанию – 60 секунд) + [DelayResetPerVmInSeconds (по умолчанию – 0,5 секунд)] * (количество работающих виртуальных машин на хосте) + [DelayResetForSpmInSeconds (по умолчанию – 20 секунд)] * 1 (если хост работает как SPM) или 0 (если хост не работает как SPM). Чтобы дать VDSM максимальное время для ответа, Менеджер управления выбирает более продолжительный из двух вышеупомянутых вариантов (три попытки получить статус VDSM или интервал, определяемый вышеприведенной формулой).
Если хост не реагирует и после истечения этого интервала, то по SSH выполняется vdsm restart.
Если vdsm restart не помогает восстановить соединение между хостом и Менеджером управления, то статус хоста меняется на Не отвечает (Non Responsive) и, если управление питанием настроено, задача изоляции передается внешнему агенту изоляции.

Программную изоляцию по SSH можно выполнять на хостах, на которых не настроено управление питанием. Она отличается от просто изоляции, которая может выполняться только на хостах, на которых настроено управление питанием.

2.5.5.8. Использование функций управления питанием хоста

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.

Откройте выпадающее меню Управление (Management) и выберите один из следующих вариантов Управления питанием (Power Management):

Перезапустить (Restart): этот вариант предусматривает остановку хоста и ожидание изменения статуса хоста на Выключен (Down) . Когда агент убедился, что хост выключен, виртуальные машины с признаком высокой доступности перезапускаются на другом хосте в кластере. Затем агент перезапускает этот хост. Когда хост готов к использованию, его статус отображается как Включен (Up) .
Запустить (Start): этот вариант предусматривает запуск хоста и его присоединение к кластеру. Когда он готов к использованию, его статус отображается как Включен (Up) .
Остановить (Stop): в этом варианте предусматривается выключение хоста. Прежде чем выбрать этот вариант, убедитесь, что виртуальные машины, работающие на хосте, перенесены на другие хосты в кластере. В противном случае произойдет сбой в работе виртуальных машин, и лишь виртуальные машины с признаком высокой доступности будут перезапущены на другом хосте. Когда хост остановлен, его статус отображается как Неработоспособный (Non-Operational).

Если Управление питанием (Power Management) не включено, то для перезапуска или остановки хоста выберите его в выпадающем меню Управление (Management), затем в категории Управление SSH (SSH Management) выберите Перезапустить (Restart) или Остановить (Stop).

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

Нажмите OK.

2.5.5.9. Изолирование хоста, не реагирующего на запросы, вручную

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

Не выбирайте Подтвердить 'Хост был перезагружен' (Confirm 'Host has been Rebooted'), если не перезагружали его вручную. Использование этой опции во время работы хоста может вызвать повреждение образа виртуальной машины.

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

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts) и подтвердите, что хост имеет статус Не отвечает (Non Responsive).
Вручную перезагрузите хост. Это может потребовать физического входа в лабораторию и перезагрузки хоста.
На Портале администрирования выберите хост и нажмите Дополнительные действия (More Actions) , затем нажмите Подтвердить 'Хост был перезагружен' (Confirm 'Host has been Rebooted').
Установите флажок в поле Подтвердить операцию (Approve operation) и нажмите OK.
Если хосты загружаются необычно долго, можно задать параметр ServerRebootTimeout, чтобы указать, через сколько секунд следует считать, что хост Не отвечает (Non Responsive):
```
# engine-config --set ServerRebootTimeout=_integer_
```

2.6. Хранилище

2.6.1. О хранилище zVirt

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

Network File System (NFS)
экспорта GlusterFS
других файловых систем, совместимых с POSIX
iSCSI
локального хранилища, подключенного непосредственно к хостам виртуализации
протокола оптоволоконного канала (Fibre Channel Protocol, FCP)
параллельной NFS (pNFS)

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

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

Для добавления доменов хранения нужен доступ к Порталу администрирования и хотя бы один подключенный хост со статусом Включен (Up) running .

В zVirt есть три типа доменов хранения:

Домен данных: Домен данных содержит виртуальные жесткие диски и файлы OVF всех виртуальных машин и шаблонов в центре данных. В нем же хранятся снимки виртуальных машин.

Домен данных не может использоваться несколькими центрами данных. К одному центру данных можно добавлять домены данных разных типов (iSCSI, NFS, FC, POSIX и Gluster) при условии, что все они являются общими, а не локальными.

Домен данных нужно подключать к центру данных до подключения доменов других типов.
Домен ISO: Домены ISO хранят файлы ISO (или логические CD), используемые для установки и загрузки операционных систем и приложений для виртуальных машин. Домен ISO избавляет центр данных от потребности в физических носителях. Домен ISO не может использоваться несколькими центрами данных. Домен ISO может базироваться только на NFS. К центру данных можно добавить только один домен ISO.
Домен экспорта: Домены экспорта – это репозитории временного хранения, используемые для копирования и перемещения образов между центрами данных и средами zVirt. Домены экспорта могут использоваться для резервного копирования виртуальных машин. Домен экспорта можно перемещать между центрами данных, но активным он может быть только в одном центре данных в каждый конкретный момент времени. Домен экспорта может базироваться только на NFS. К центру данных можно добавить только один домен экспорта.

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

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

2.6.2. Концепция доменов хранения

Домен хранения – это набор образов, имеющих общий интерфейс хранения. Домен хранения содержит полные образы шаблонов и виртуальных машин (включая моментальные снимки) или файлы ISO. Домен хранения может состоять из блочных устройств (SAN - iSCSI или FCP) или файловой системы (NAS - NFS, GlusterFS или иных POSIX-совместимых файловых систем).

По умолчанию домены GlusterFS и локальные домены хранения поддерживают блок размером 4 кБ. Блок размером 4 кБ может обеспечить лучшую производительность, особенно на больших файлах, а также необходим при использовании инструментов, требующих совместимости с 4-килобайтным блоком, например, VDO.

В NFS все виртуальные диски, шаблоны и моментальные снимки являются файлами.

В SAN (iSCSI/FCP) каждый виртуальный диск, шаблон или моментальный снимок представляет собой логический том. Блочные устройства объединяются в логическую сущность, называемую группой томов, а затем с помощью Менеджера логических томов (Logical Volume Manager, LVM) делятся на логические тома для использования в качестве виртуальных жестких дисков.

Виртуальные диски могут иметь один из двух форматов: QCOW2 или raw. Возможные типы хранилищ: динамически расширяемые (sparse) или предварительно размеченные (preallocated). Снимки всегда имеют формат sparse, но могут создаваться для дисков любого из этих форматов.

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

2.6.3. Подготовка и добавление хранилища NFS

2.6.3.1. Подготовка хранилища NFS

Настройте общие ресурсы NFS в файловом хранилище или на удаленном сервере, чтобы они служили доменами хранения в системах хостов zVirt. После экспорта общих ресурсов в удаленное хранилище и их настройки в Менеджере управления они будут автоматически импортированы на хосты с zVirt Node.

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

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

Установите пакет утилит NFS (utils).
```
# dnf install nfs-utils -y
```
Проверьте включенные версии:
```
# cat /proc/fs/nfsd/versions
```

Включите следующие службы:

# systemctl enable nfs-server
# systemctl enable rpcbind

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

Создайте группу kvm:
```
# groupadd kvm -g 36
```
Создайте пользователя vdsm в группе kvm:
```
# useradd vdsm -u 36 -g kvm
```
Создайте каталог storage и измените права доступа.
```
# mkdir /storage
# chmod 0755 /storage
# chown 36:36 /storage/
```
Добавьте каталог storage в /etc/exports с соответствующими разрешениями.
```
# vi /etc/exports
# cat /etc/exports
/storage *(rw)
```
Перезапустите следующие службы:
```
# systemctl restart rpcbind
# systemctl restart nfs-server
```
Чтобы посмотреть экспорты, доступные для конкретного IP-адреса, выполните:
```
# exportfs
/nfs_server/srv
 10.46.11.3/24
/nfs_server       <world>
```

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

2.6.3.2. Добавление хранилища NFS

Далее показано, как подключить существующее хранилище NFS к среде zVirt в качестве домена данных.

Если требуется домен ISO или домен экспорта, используйте эту процедуру, но выберите ISO или Экспорт (Export) в списке Функция домена (Domain Function).

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

На Портале администрирования нажмите Хранилище (Storage) Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Примите значения по умолчанию для списков Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type), Используемый хост (Host).
Введите Путь экспорта (Export Path), который должен использоваться для домена хранения. Путь экспорта должен иметь следующий формат: 123.123.0.10:/data (для IPv4), [2001:0:0:0:0:0:0:5db1]:/data (для IPv6), или domain.example.com:/data.
При желании можно настроить дополнительные параметры:
1. Нажмите Дополнительные параметры (Advanced Parameters).
2. Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
3. Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
4. Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
Нажмите OK.

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

2.6.3.3. Увеличение объема хранилища NFS

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

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения NFS. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center) и нажмите Обслуживание (Maintenance), чтобы перевести домен хранения в режим обслуживания. Это размонтирует существующий общий ресурс и позволит изменить размер домена хранения.
Измените размер хранилища на сервере NFS.
В подробном представлении откройте вкладку Центр данных (Data Center) и нажмите Включить (Activate), чтобы смонтировать домен хранения.

2.6.4. Подготовка и добавление локального хранилища

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

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

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

2.6.4.1. Подготовка локального хранилища

В среде исполнения zVirt Node локальное хранилище всегда должно определяться в файловой системе, отличной от / (root). Используйте отдельный логический том или диск, чтобы предотвратить возможную потерю данных во время обновления.

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

Создайте каталог локального хранилища:
# mkdir /data # lvcreate -n <lv_name> -L <size> <vg_name> # mkfs.ext4 /dev/mapper/<vg_name>-<lv_name> # echo "/dev/mapper/<vg_name>-<lv_name> /data ext4 defaults,discard 1 2" >> /etc/fstab # mount /data
где: * <vg_name> - имя нужной группы томов * <lv_name> - имя создаваемого логического тома * <size> - размер создаваемого тома
Смонтируйте новое локальное хранилище:
```
# mount -a
```
Убедитесь, что каталог имеет разрешения на чтение/запись для пользователя vdsm (UID 36) и группы kvm (GID 36):
```
# chown 36:36 /data
# chmod 0775 /data
```

2.6.4.2. Добавление локального домена хранения

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

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

Нажмите Ресурсы (Compute) Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK. Статус хоста меняется на Обслуживание (Maintenance) .
Нажмите Управление (Management) → Настроить локальное хранилище (Configure Local Storage).
Нажмите кнопки Изменить (Edit) рядом с полями Центр данных (Data Center), Кластер (Cluster) и Хранилище (Storage), чтобы настроить локальный домен хранения и дать ему имя.
Введите путь к локальному хранилищу в текстовое поле.
Если применимо, откройте вкладку Оптимизация (Optimization), чтобы настроить политику оптимизации памяти для нового кластера локального хранилища.
Нажмите OK.

Менеджер управления настроит локальный центр данных с локальным кластером и локальным доменом хранения. Он также поменяет статус хоста на Включен (Up) running .

Проверка (Verification):

Нажмите Хранилище (Storage) Домены (Domains).
Найдите локальный домен хранения, который только что добавили.

Домен должен иметь статус Активный (Active) , а значение в столбце Тип хранилища (Storage Type) должно быть Локальное на хосте (Local on Host). Теперь можно выгрузить образ диска в новый локальный домен хранения.

2.6.5. Подготовка и добавление хранилища на базе POSIX-совместимой файловой системы

2.6.5.1. Подготовка хранилища на базе POSIX-совместимой файловой системы

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

Любая POSIX-совместимая файловая система, используемая в zVirt в качестве домена хранения, должна быть кластерной файловой системой (такой как Global File System 2 (GFS2)), поддерживать динамически расширяемые файлы и прямой ввод/вывод. Так, например, Общая файловая система Интернета (Common Internet File System, CIFS) не поддерживает прямой ввод/вывод, что делает ее несовместимой с zVirt.

Не монтируйте хранилище NFS путем создания домена хранения на базе POSIX-совместимой файловой системы. Вместо этого всегда создавайте домен хранения NFS.

2.6.5.2. Добавление хранилища на базе POSIX-совместимой файловой системы

Далее показано, как подключить существующее хранилище на базе POSIX-совместимой файловой системы к среде zVirt в качестве домена данных.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Выберите Центр данных (Data Center), который нужно ассоциировать с доменом хранения. Выбранный центр данных должен иметь тип POSIX (POSIX compliant FS). Либо выберите (none).
Выберите Данные (Data) в выпадающем списке Функция домена (Domain Function) и POSIX compliant FS в выпадающем списке Тип хранилища (Storage Type).

Если применимо, выберите Формат (Format) в выпадающем меню.
Выберите хост в выпадающем списке Используемый хост (Host).
Введите Путь (Path) к файловой системе POSIX, как в обычной команде mount.
Введите Тип VFS (VFS Type), как в обычной команде mount, используя аргумент -t. Список действительных типов VFS см. в man mount.
Введите дополнительные Параметры монтирования (Mount Options), как в обычной команде mount, используя аргумент -o. Параметры монтирования следует указывать в виде списка через запятую. Список действительных параметров монтирования см. в man mount.
При желании можно настроить дополнительные параметры.
1. Нажмите Дополнительные параметры (Advanced Parameters).
2. Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
3. Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
4. Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
Нажмите OK.

2.6.6. Подготовка и добавление блочного хранилища

2.6.6.1. Подготовка хранилища iSCSI

zVirt поддерживает хранилище iSCSI, которое представляет собой домен хранения, созданный из группы томов, состоящей из логических устройств (LUN). Ни группы томов, ни LUN нельзя подключать более чем к одному домену хранения одновременно.

Если вы используете блочное хранилище и собираетесь развернуть виртуальные машины на неформатированных (raw) устройствах или подключенных напрямую LUN и управлять ими с помощью Менеджера логических томов (LVM), то создайте фильтр, чтобы скрыть гостевые логические тома. Это предотвратит активацию гостевых логических томов при загрузке хоста, что в противном случае могло бы привести к устареванию логических томов и повреждению данных. Используйте команду vdsm-tool config-lvm-filter, чтобы создать фильтры для LVM.

zVirt в настоящее время не поддерживает блочное хранилище с размером блока 4 кБ. Нужно настраивать блочное хранилище со стандартным размером блока – 512 байт.

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

Чтобы этого не произошло, добавьте в корневую файловую систему SAN файл конфигурации с несколькими путями для загрузочного LUN, чтобы убедиться, что он будет поставлен в очередь, как только подключение появится:

# cat /etc/multipath/conf.d/host.conf
multipaths {
    multipath {
wwid _boot_LUN_wwid_
no_path_retry queue
}

2.6.6.2. Добавление хранилища iSCSI

Далее показано, как подключить существующее хранилище iSCSI к среде zVirt в качестве домена данных.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для нового домена хранения.
Выберите Центр данных (Data Center) в раскрывающемся списке.
Выберите Данные (Data) в качестве Функция домена (Domain Function) и iSCSI в качестве Типа хранилища (Storage Type).

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

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

Менеджер управления может сопоставлять iSCSI-таргеты с LUN или LUN с iSCSI-таргетами. Если выбран тип хранилища iSCSI, то в окне Новый домен хранения (New Domain) будут автоматически отображаться известные таргеты с неиспользуемыми LUN. Если таргет, который вы используете для добавления хранилища, не отображается, то для его поиска можно использовать операцию обнаружения таргетов; в противном случае перейдите к следующему шагу.

Нажмите Обнаружение целей (Discover Targets), чтобы задать параметры обнаружения таргетов. После того как таргеты обнаружены и вход в них выполнен, в окне Новый домен хранения (New Domain) будут автоматически отображаться таргеты с LUN, которые не используются средой.

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

Параметры Обнаружение целей (Discover Targets) можно использовать для добавления LUN на несколько таргетов или нескольких путей к одному LUN.

Если для обнаружения iSCSI-таргетов используется метод REST API discoveriscsi, то можно использовать FQDN или IP-адрес, но нужно использовать подробные сведения iSCSI, взятые из результатов обнаружения таргетов, чтобы авторизоваться в таргетах, используя метод REST API iscsilogin. Дополнительную информацию см. в разделе discoveriscsi в руководстве REST API.

В поле Адрес (Address) укажите FQDN или IP-адрес iSCSI-хоста.
В поле Порт (Port) укажите порт для соединения с хостом в процессе поиска таргетов. Значение по умолчанию = 3260.

Если для защиты хранилища используется CHAP, установите флажок Аутентификация пользователей (User Authentication). Введите Имя пользователя CHAP (CHAP user name) и Пароль CHAP (CHAP password).

С помощью REST API можно задать учетные данные для iSCSI-таргета для конкретного хоста. Дополнительную информацию см. в разделе StorageServerConnectionExtensions: add в руководстве REST API.

Нажмите Обнаружение (Discover).

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

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

Когда для авторизации используется метод REST API iscsilogin, используйте подробные сведения iSCSI, взятые из результатов обнаружения таргетов, в методе discoveriscsi. Дополнительную информацию см. в разделе iscsilogin в руководстве REST API.

Нажмите рядом с нужным таргетом. Развернется соответствующая запись с отображением всех неиспользуемых LUN, подключенных к таргету.
Поставьте флажок для каждого LUN, который используете для создания домена хранения.
При желании можно настроить дополнительные параметры:
1. Нажмите Дополнительные параметры (Advanced Parameters).
2. Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
3. Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
4. Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
5. Установите флажок Освободить пространство после удаления (Discard After Delete), чтобы включить освобождение пространства после удаления. Этот параметр можно изменить после создания домена. Этот параметр доступен только на блочных доменах хранения.
Нажмите OK.

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

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

2.6.6.3. Настройка многоканального доступа iSCSI

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

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

В целях резервирования можно создавать bond-интерфейс iSCSI с несколькими таргетами и логическими сетями.

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

Один или несколько iSCSI-таргетов
Одна или несколько логических сетей, соответствующих следующим требованиям:
- Не определена как Обязательная (Required) или Сеть ВМ (VM Network)
- Назначена интерфейсу хоста
- Назначен статический IP-адрес в той же сети VLAN и подсети, что и другим логическим сетям в bond-интерфейсе iSCSI

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

Нажмите Ресурсы (Compute) Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку Многоканальный iSCSI (iSCSI Multipathing), нажмите Добавить (Add).
В окне Добавить bond iSCSI (Add iSCSI Bond), введите Имя (Name) и Описание (Description).
Выберите логическую сеть из раздела Логические сети (Logical Networks) и домен хранения из раздела Цели iSCSI (Storage Targets). Все выбранные пути должны идти к одному и тому же таргету.
Нажмите OK.

Хосты центра данных соединены с iSCSI-таргетами через логические сети и bond-интерфейс iSCSI.

2.6.6.4. Миграция логической сети в bond-интерфейс iSCSI

Если логическая сеть создана для iSCSI-трафика и настроена поверх существующего сетевого bond-интерфейса, то ее можно перенести в bond-интерфейс iSCSI в той же подсети без сбоя или простоя.

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

Измените текущую логическую сеть так, чтобы она не была Обязательной (Required):
1. Нажмите Ресурсы (Compute) Кластеры (Clusters).
2. Нажмите на имя кластера. Откроется подробное представление.
3. Во вкладке Логические сети (Logical Networks) выберите текущую логическую сеть (для примера, net-1) и нажмите Управление сетями (Manage Networks).
4. Уберите флажок Обязательная (Require) и нажмите OK.
Создайте новую логическую сеть, которая не обозначена как Обязательная (Required) или Сеть ВМ (VM network):
1. Нажмите Добавить сеть (Add Network). Откроется окно Новая логическую сеть (New Logical Network).
2. Во вкладке Общие (General) введите Имя (Name) (для примера, net-2) и уберите флажок Сеть ВМ (VM network).
3. Во вкладке Кластер (Cluster) уберите флажок Обязательная (Require) и нажмите OK.
Удалите текущий сетевой bond-интерфейс и переназначьте логические сети:
1. Нажмите Ресурсы (Compute) Хосты (Hosts).
2. Нажмите на имя хоста. Откроется подробное представление.
3. Во вкладке Сетевые интерфейсы (Network Interfaces) нажмите Настройка сетей хоста (Setup Host Networks).
4. Перетащите net-1 вправо, чтобы отменить назначение.
5. Перетащите текущий bond-интерфейс вправо, чтобы удалить его.
6. Перетащите net-1 и net-2 влево, чтобы назначить их физическим интерфейсам.
7. Нажмите на значок карандаша у net-2. Откроется окно Изменить сеть (Edit Network).
8. Во вкладке IPV4 выберите Статичная (Static).
9. Введите IP-адрес (IP) и Маску сети/префикс (Netmask/Routing Prefix) подсети и нажмите OK.
Создайте bond-интерфейс iSCSI:
1. Нажмите Ресурсы (Compute) Центры данных (Data Centers).
2. Нажмите на имя центра данных. Откроется подробное представление.
3. Выберите вкладку Многоканальный iSCSI (iSCSI Multipathing), нажмите Добавить (Add).
4. В окне Добавить bond iSCSI (Add iSCSI Bond) введите Имя (Name), выберите сети net-1 и net-2 и нажмите OK.

В центре данных имеется bond-интерфейс iSCSI, содержащий старые и новые логические сети.

2.6.6.5. Подготовка хранилища FCP

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

Системные администраторы zVirt должны иметь практические знания о работе SAN. SAN обычно использует Fibre Channel Protocol (FCP) для передачи трафика между хостами и общим внешним хранилищем. Поэтому SAN иногда может именоваться хранилищем FCP.

# cat /etc/multipath/conf.d/host.conf
multipaths {
    multipath {
wwid _boot_LUN_wwid_
no_path_retry queue
    }

2.6.6.6. Добавление хранилища FCP

Далее показано, как подключить существующее хранилище FCP к среде zVirt в качестве домена данных.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Выберите из раскрывающегося списка Центр данных (Data Center) FCP.

Если подходящего центра данных FCP пока нет, выберите (none).
Из выпадающих списков выберите Функцию домена (Domain Function) и Тип хранилища (Storage Type). Типы доменов хранения, не совместимые с выбранным центром данных, недоступны.

Выберите активный хост в поле Используемый хост (Host). Если это не первый домен данных в центре данных, нужно выбрать хост SPM в центре данных.

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

Если выбран тип хранилища Fibre Channel, то в окне Новый домен хранения (New Domain) будут автоматически отображаться известные таргеты с неиспользуемыми LUN. Поставьте флажок Код LUN (LUN ID), чтобы выбрать все доступные LUN.
При желании можно настроить дополнительные параметры.
1. Нажмите Дополнительные параметры (Advanced Parameters).
2. Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
3. Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
4. Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
5. Установите флажок Освободить пространство после удаления (Discard After Delete), чтобы включить освобождение пространства после удаления. Этот параметр можно изменить после создания домена. Этот параметр доступен только на блочных доменах хранения.
Нажмите OK.

Новый домен данных FCP останется со статусом Заблокирован (Locked) Lock во время подготовки к использованию. Затем он будет автоматически подключен к центру данных.

2.6.6.7. Увеличение объема хранилища iSCSI или FCP

Увеличить размер хранилища iSCSI или FCP можно несколькими способами:

Добавить существующий LUN в текущий домен хранения.
Создать новый домен хранения с новыми LUN и добавить его в существующий центр данных. См. раздел [Добавление хранилища iSCSI].
Расширить домен хранения, изменив размер используемых в нем LUN.

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

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

У домена хранения должен быть статус Включен (UP) .
LUN должен быть доступен всем хостам со статусом Включен (UP) , иначе операция не удастся, и LUN не будет добавлен в домен. Однако это не затронет сами хосты. Если вновь добавленный хост или хост, выходящий из режима обслуживания, или хост в состоянии Неработоспособен (Non Operational) не может получить доступ к LUN, то состояние хоста будет Неработоспособен (Non Operational).

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

Нажмите Хранилище (Storage) Домены (Domains) и выберете домен iSCSI или FCP.
Нажмите Управление доменом (Manage Domain).
Нажмите Цели (Targets) > LUNs и нажмите кнопку Обнаружение целей (Discover Targets), чтобы развернуть представление.
Введите информацию о соединении сервера хранения и нажмите Обнаружение (Discover), чтобы начать подключение.
Нажмите LUNs > Цели (Targets) и нажмите Добавить (Add) для доступного LUN.
Нажмите OK, чтобы добавить LUN в выбранный домен хранения.

Это увеличит домен хранения на размер добавленного LUN.

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

Обновление размера LUN

Нажмите Хранилище (Storage) Домены (Domains) и выберете домен iSCSI или FCP.
Нажмите Управление доменом (Manage Domain).
Нажмите LUNs → Цели (Targets).
В столбце Дополнительный размер (Additional Size) нажмите кнопку LUN Добавить (Add) для обновления.
Нажмите OK для обновления LUN, чтобы задать новый размер хранилища.

2.6.6.8. Повторное использование LUN

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

Physical device initialization failed. Please check that the device is empty and accessible by the host.

При установке hosted engine выдает следующую ошибку:

[ ERROR ] Error creating Volume Group: Failed to initialize physical device: ("[u'/dev/mapper/000000000000000000000000000000000']",)
[ ERROR ] Failed to execute stage 'Misc configuration': Failed to initialize physical device: ("[u'/dev/mapper/000000000000000000000000000000000']",)

Прежде чем LUN может быть использован повторно, следует очистить старую таблицу разделов.

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

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

Удалить сопоставления разделов в <LUN_ID>:
```
kpartx -dv /dev/mapper/<LUN_ID>
```
Стереть файловую систему или raid-подписи в <LUN_ID>:
```
wipefs -a /dev/mapper/<LUN_ID>
```
Сообщить операционной системе об изменениях в таблице разделов в <LUN_ID>:
```
partprobe
```

2.6.6.9. Удаление устаревших LUN

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

zVirt не управляет серверами iSCSI и, следовательно, не может автоматически удалить LUN при удалении домена хранения. Администратор может вручную удалить ссылки на устаревшие LUN с помощью роли Ansible remove_stale_lun.yml. С помощью этой роли можно удалить ссылки на устаревшие LUN со всех хостов, которые относятся к конкретному центру данных. Для получения дополнительной информации об этой роли и ее переменных см. Remove Stale LUN role in the oVirt Ansible collection

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Выберите вкладку Центр данных (Data Center).
Нажмите Обслуживание (Maintenance) и затем OK.
Нажмите Отсоединить (Detatch) и затем OK.
Нажмите Удалить (Remove).
Нажмите OK для удаления домена хранения из исходной среды.
Удалите LUN с сервера хранения.
Удалите устаревшие LUN с хоста, используя Ansible:
# ansible-playbook --extra-vars "lun=<LUN>" /usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/remove_stale_lun/examples/remove_stale_lun.yml
где LUN - это LUN, удаленный с вышеуказанного сервера хранения.

Если с помощью Ansible удалить устаревший LUN с хоста без предварительного удаления LUN с сервера хранения, то устаревший LUN снова появится на хосте при следующем iSCSI-сканировании, выполненном VDSM.

2.6.6.10. Создание фильтра LVM

Фильтр LVM может быть задан в /etc/lvm/lvm.conf, чтобы принимать или отклонять устройства из списка томов на основе запроса регулярного выражения. Например, чтобы проигнорировать /dev/cdrom, можно использовать filter=["r|^/dev/cdrom$|"] или добавить следующий параметр в команду lvm: lvs --config 'devices{filter=["r|cdrom|"]}'.

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

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

Можно использовать команду vdsm-tool config-lvm-filter, чтобы проанализировать текущую конфигурацию LVM и решить, требуется ли конфигурировать фильтр.

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

Сценарий 1: Несконфигурированный хост

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

# vdsm-tool config-lvm-filter
Analyzing host...
Found these mounted logical volumes on this host:
logical volume:  /dev/mapper/vg0-lv_home
mountpoint:      /home
devices: /dev/vda2
logical volume:  /dev/mapper/vg0-lv_root
mountpoint:      /
devices: /dev/vda2
logical volume:  /dev/mapper/vg0-lv_swap
mountpoint:      [SWAP]
devices: /dev/vda2
This is the recommended LVM filter for this host:
filter = [ "a|^/dev/vda2$|", "r|.*|" ]
This filter will allow LVM to access the local devices used by the
hypervisor, but not shared storage owned by VDSM. If you add a new
device to the volume group, you will need to edit the filter manually.
Configure LVM filter? [yes,NO] ? [NO/yes] yes
Configuration completed successfully!
Please reboot to verify the LVM configuration.

Сценарий 2: Сконфигурированный хост

Если хост уже конфигурирован, команда просто сообщает пользователю, что фильтр LVM уже сконфигурирован:

# vdsm-tool config-lvm-filter
Analyzing host...
LVM filter is already configured for Vdsm

Сценарий 3: Требуется конфигурирование вручную

Если конфигурация хоста не совпадает с конфигурацией, которая требуется для VDSM, то фильтр LVM нужно будет сконфигурировать вручную:

# vdsm-tool config-lvm-filter
Analyzing host...
Found these mounted logical volumes on this host:
logical volume:  /dev/mapper/vg0-lv_home
mountpoint:      /home
devices: /dev/vda2
logical volume:  /dev/mapper/vg0-lv_root
mountpoint:      /
devices: /dev/vda2
logical volume:  /dev/mapper/vg0-lv_swap
mountpoint:      [SWAP]
devices: /dev/vda2
This is the recommended LVM filter for this host:
filter = [ "a|^/dev/vda2$|", "r|.*|" ]
This filter will allow LVM to access the local devices used by the
hypervisor, but not shared storage owned by VDSM. If you add a new
device to the volume group, you will need to edit the filter manually.
This is the current LVM filter:
filter = [ "a|^/dev/vda2$|", "a|^/dev/vdb1$|", "r|.*|" ]
WARNING: The current LVM filter does not match the recommended filter,
Vdsm cannot configure the filter automatically.
Please edit /etc/lvm/lvm.conf and set the 'filter' option in the  'devices' section to the recommended value.
It is recommended to reboot after changing LVM filter.

2.6.7. Подготовка и добавление Gluster Storage

Информацию по настройке Gluster Storage см. в официальной документации, учитывая следующие особенности - тома Gluster Storage должны использовать либо трехстороннюю репликацию, либо арбитражную репликацию. Такой вариант снижает риск возникновения split-brain в кластере.

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

трехсторонне реплицированные и распределенные реплицированные тома (replica count 1)
арбитражные реплицированные или распределенные арбитражные реплицированные тома (replica 3 arbiter 1)

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

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

Техническая поддержка по службе Gluster Storage не оказывается.

2.6.8. Импортирование существующих доменов хранения

2.6.8.1. Общие сведения об импортировании существующих доменов хранения

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

Ниже рассмотрено импортирование каждого типа домена хранения:

Данные (Data)

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

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

ISO

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

Экспорт (Export)

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

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

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

2.6.8.2. Импортирование доменов хранения

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите Импортировать домен (Import Domain).
Выберите Центр данных (Data Center), в который вы хотите импортировать домен хранения.
Введите Имя (Name) для домена хранения.
В выпадающих списках выберите Функцию домена (Domain Function) и Тип хранилища (Storage Type).

Выберите хост в выпадающем списке Используемый хост (Host).

Введите сведения о домене хранения.

Поля для ввода сведений о домене хранения меняются в зависимости от значений, выбранных в списках Функции домена (Domain Function) и Типа хранилища (Storage Type). Это такие же поля, как и при добавлении нового домена хранения.

В разделе Дополнительные параметры (Advanced Parameters) установите флажок Включить домен в центре данных (Activate Domain in Data Center), чтобы активировать домен хранения после его подключения к выбранному центру данных.
Нажмите OK.

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

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

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

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

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

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

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

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

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

Выключите все виртуальные машины, работающие в необходимом домене хранения.
Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).
Нажмите Обслуживание (Maintenance), затем OK.
Нажмите Отсоединить (Detach), затем OK.
Нажмите Прикрепить (Attach).
Выберите центр данных, являющийся приемником, и нажмите OK.

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

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

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

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

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

Введите сведения о домене хранения.

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

В разделе Дополнительные параметры (Advanced Parameters) установите флажок Включить домен в центре данных (Activate Domain in Data Center), чтобы активировать домен хранения после его подключения.
Нажмите OK.

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

2.6.8.5. Импортирование шаблонов из импортированных доменов хранения данных

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя импортированного домена хранения. Откроется подробное представление.
Откройте вкладку Импортировать шаблон (Template Import).
Выберите один или несколько шаблонов для импорта.
Нажмите Импортировать (Import).
Для каждого шаблона в окне Импортировать шаблон(ы) (Import Templates(s)) убедитесь, что в списке Кластер (Cluster) выбран правильный кластер.
Сопоставьте внешние профили vNIC виртуальных машин с профилями в целевом кластере (кластерах):
1. Нажмите Сопоставление vNic-профилей (vNic Profiles Mapping).
2. Выберите профиль vNIC в выпадающем списке Целевой vNic-профиль (Target vNic Profile).
3. Если в окне Импортировать шаблоны (Import Templates) выбрано несколько целевых кластеров, то выберите каждый целевой кластер в выпадающем списке Целевой кластер (Target Cluster) и убедитесь в корректности сопоставления.
4. Нажмите OK.
Нажмите OK.

Импортированные шаблоны больше не отображаются в списке на вкладке Импортировать шаблон (Template Import).

2.6.9. Задачи, относящиеся к хранилищу

2.6.9.1. Выгрузка образов в домен хранения данных

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

Чтобы выгрузить образы с помощью REST API, см. IMAGETRANSFERS и IMAGETRANSFER в руководстве REST API.

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

Образы ISO могут подключаться к виртуальным машинами как CDROM или использоваться для загрузки виртуальных машин.

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

Функция выгрузки использует API-интерфейсы HTML 5, поэтому среда должна иметь следующее:

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

Чтобы импортировать центр сертификации, перейдите по адресу https://engine_address/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA и включите все настройки доверия. См. инструкции по установке центра сертификации в Firefox, Internet Explorer или Google Chrome.
Браузер с поддержкой HTML 5, такой как Firefox 35, Internet Explorer 10, Chrome 13 или более новые версии.

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

Нажмите Хранилище (Storage) Диски (Disks).
Выберите Начать (Start) в меню Загрузка (Upload).
Нажмите Выберите файл (Choose File) и выберите образ для выгрузки.
Заполните поля Настройки диска (Disk Options). Описания соответствующих полей см. в разделе Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

Индикатор выполнения отображает статус выгрузки. Выгрузку можно приостановить, отменить или возобновить из меню Загрузка (Upload).

Если во время выгрузки время ожидания истечет и будет выдано сообщение Причина: истекло время ожидания из-за неактивности соединения (Reason: timeout due to transfer inactivity), то увеличьте значение времени ожидания и перезапустите службу ovirt-engine:

# engine-config -s TransferImageClientInactivityTimeoutInSeconds=6000
# systemctl restart ovirt-engine

2.6.9.2. Выгрузка образов в домен ISO

Домен ISO считается устаревшим типом домена хранения. Инструмент ISO Uploader – ovirt-iso-uploader – исключен из zVirt. Выгружать образы ISO в домен данных следует на Портале администрирования или с помощью REST API. Подробности см. в разделе Выгрузка образов в домен хранения данных.

Хотя домен ISO считается устаревшим, эта информация предоставляется на случай, если вдруг его необходимо использовать.

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

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

Авторизуйтесь как root-пользователь на хосте, который относится к центру данных, где расположен ваш домен хранения ISO.

Отобразите дерево каталогов /rhv/data-center:

[root@host1 ~]# tree /rhev/data-center/
/rhev/data-center/
├── 39abb67e-e417-11ed-8902-00163e6489b9
│   ├── 3ca19deb-c642-420e-9c2c-40eefb8bb40c -> /rhev/data-center/mnt/nfs-kf:_storage_iso/
3ca19deb-c642-420e-9c2c-40eefb8bb40c
│   ├── aae384fe-7dc4-4f78-86d4-a22669524a48 -> /rhev/data-center/mnt/nfs-kf:_storage_data/
aae384fe-7dc4-4f78-86d4-a22669524a48
│   ├── b91e7617-0606-47b5-818d-641c777ba56d -> /rhev/data-center/mnt/
nfs-kf:_storage_domain/b91e7617-0606-47b5-818d-641c777ba56d
│   └── mastersd -> /rhev/data-center/mnt/nfs-kf:_storage_domain/
b91e7617-0606-47b5-818d-641c777ba56d
└── mnt
    ├── blockSD
    │   └── 9188dc27-254d-4285-ba5a-7112450ec27c
    │       ├── dom_md
    │       │   ├── ids -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/ids
    │       │   ├── inbox -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/inbox
    │       │   ├── leases -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/leases
    │       │   ├── master -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/master
    │       │   ├── metadata -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/metadata
    │       │   ├── outbox -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/outbox
    │       │   └── xleases -> /dev/9188dc27-254d-4285-ba5a-7112450ec27c/xleases
    │       └── images
    │   ├── 59e550ad-1497-49e0-a033-fb897bc6bc22
    │   │   └── 19d55adf-3a67-4d96-ac16-1f0fe76ee801 -> /dev/
      9188dc27-254d-4285-ba5a-7112450ec27c/19d55adf-3a67-4d96-ac16-1f0fe76ee801
    │   └── cb49b486-a95a-4300-bc45-895637452cdf
    │    └── 171d65ab-456e-41e7-be4b-026f4c81bc25 -> /dev/
      9188dc27-254d-4285-ba5a-7112450ec27c/171d65ab-456e-41e7-be4b-026f4c81bc25
    ├── nfs-kf:_storage_iso
    │   └── 3ca19deb-c642-420e-9c2c-40eefb8bb40c
    │       ├── dom_md
    │       │   ├── ids
    │       │   ├── inbox
    │       │   ├── leases
    │       │   ├── metadata
    │       │   ├── outbox
    │       │   └── xleases
    │       └── images
    │   ├── 11111111-1111-1111-1111-111111111111
(output trimmed)

Аккуратно скопируйте образ из исходного местоположения по полному пути 11111111-1111-1111-1111-111111111111:
```
# scp root@isosource:/isos/example.iso /rhev/data-center/mnt/nfs-kf:_storage_iso/3ca19deb-c642-420e-9c2c-40eefb8bb40c/images/11111111-1111-1111-1111-111111111111
```
Разрешения для только что скопированного файла образа ISO должны быть 36:36 (vdsm:*kvm*). Если это не так, измените принадлежность файла ISO пользователю и группе на 36:36:
```
# cd /rhev/data-center/mnt/10.96.4.50:_rhevisosd/b835cd1c-111c-468d-ba70-fec5346af227/images/11111111-1111-1111-1111-111111111111
# chown 36:36 example.iso
```

Теперь образ ISO должен стать доступным в домене ISO в центре данных.

2.6.9.3. Перевод доменов хранения в режим обслуживания

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

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

Расширять домены iSCSI путем добавления LUN можно, только когда домен активен.

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

Выключите все виртуальные машины, работающие в домене хранения.
Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).

Нажмите Обслуживание (Maintenance).

Флажок Игнорировать сбои обновлений OVF (Ignore OVF update failure) позволяет домену хранения переходить в режим обслуживания даже в случае ошибки обновления OVF.

Нажмите OK.

Домен хранения деактивируется и в списке результатов отображается со статусом Неактивен (Inactive). Теперь можно изменять, отключать, удалять или повторно активировать неактивные домены хранения из центра данных.

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

2.6.9.4. Изменение доменов хранения

Параметры домена хранения можно менять через Портал администрирования. В зависимости от состояния домена хранения (активен или неактивен), для изменения доступны разные поля. Такие поля как Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type) и Формат (Format) изменить невозможно.

Активен (Active): Когда домен хранения находится в активном состоянии, поля Имя (Name), Описание (Description), Комментарий (Comment), Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator), Порог блокировки при критическом значении свободного места в домене (Critical Space Action Blocker), Очистить после удаления (Wipe After Delete) и Освободить пространство после удаления (Discard After Delete) можно изменять. Поле Имя (Name) можно изменять только тогда, когда домен хранения активен. Все остальные поля можно изменять и тогда, когда домен хранения неактивен.
Неактивен (Inactive): Когда домен хранения находится в режиме обслуживания или не подключен, т.е. в неактивном состоянии, можно изменять все поля, кроме Имя (Name), Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type) и Формат (Format). Домен хранения должен быть неактивным, чтобы можно было изменять подключения к хранилищу, параметры монтирования и другие расширенные параметры. Это поддерживается только для типов хранилища NFS, POSIX и локального.

Подключения к хранилищу iSCSI невозможно изменять на Портале администрирования, но можно – через REST API. См. StorageServerConnectionExtension в руководстве REST API.

Изменение активного домена хранения

Нажмите Хранилище (Storage) Домены (Domains) и выберите домен хранения.
Нажмите Управление доменом (Manage Domain).
Измените редактируемые поля нужным образом.
Нажмите OK.

Изменение неактивного домена хранения

Нажмите Хранилище (Storage) Домены (Domains).
Если домен хранения активен, переведите его в режим обслуживания:
1. Нажмите на имя домена хранения. Откроется подробное представление.
2. Откройте вкладку Центр данных (Data Center).
3. Нажмите Обслуживание (Maintenance).
4. Нажмите OK.
Нажмите Управление доменом (Manage Domain).
Измените путь к хранилищу и прочие сведения нужным образом. В сведениях о новом подключении должен быть указан тот же тип хранилища, что и для исходного подключения.
Нажмите OK.
Активируйте домен хранения:
1. Нажмите на имя домена хранения. Откроется подробное представление.
2. Откройте вкладку Центр данных (Data Center).
3. Нажмите Включить (Activate).

2.6.9.5. Обновление OVF

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Выберите домен хранения и нажмите Дополнительные действия (More Actions) , затем нажмите Обновить OVF (Update OVFs).

OVF обновляются, и в поле События (Events) отобразится сообщение.

2.6.9.6. Активация доменов хранения из режима обслуживания

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя неактивного домена хранения. Откроется подробное представление.
Откройте вкладку Центры данных (Data Centers).
Нажмите Включить (Activate).

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

2.6.9.7. Отключение домена хранения от центра данных

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Выберите вкладку Центр данных (Data Center).
Нажмите Обслуживание (Maintenance).
Нажмите OK, чтобы перейти в режим обслуживания.
Нажмите Отсоединить (Detach).
Нажмите OK, чтобы отключить домен хранения.

Домен хранения отключен от центра данных, готов к подключению к другому центру данных.

2.6.9.8. Подключение домена хранения к центру данных

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).
Нажмите Прикрепить (Attach).
Выберите подходящий центр данных.
Нажмите OK.

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

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

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

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

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

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

2.6.9.10. Уничтожение домена хранения

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Выберите домен хранения и нажмите Дополнительные действия (More Actions) и затем Уничтожить (Destroy).
Установите флажок в поле Подтвердить операцию (Approve operation).
Нажмите OK.

2.6.9.11. Создание профиля диска

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

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

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения данных. Откроется подробное представление.
Откройте вкладку Профили диска (Disk Profiles).
Нажмите Новый (New).
Введите Имя (Name) и Описание (Description) для профиля диска.
Выберите политику QoS из списка QoS для применения к профилю диска.
Нажмите OK.

2.6.9.12. Удаление профиля диска

Удалите существующий профиль диска из среды zVirt.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения данных. Откроется подробное представление.
Откройте вкладку Профили диска (Disk Profiles).
Выберите профиль диска, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

Если профиль диска был назначен каким-либо виртуальным дискам, то он удаляется с этих виртуальных дисков.

2.6.9.13. Просмотр статуса состояния домена хранения

У домена хранения есть внешний статус состояния в дополнение к обычному Статусу (Status). Внешний статус состояния сообщается внешними системами и подключаемыми модулями или задается администратором и отображается слева от Имени (Name) домена хранения в виде одного из следующих значков:

OK: Без значка
Информация (Info):
Предупреждение (Warning):
Ошибка (Error):
Отказ (Failure):

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

Статус состояния домена хранения можно также посмотреть с помощью REST API. Запрос GET о домене хранения будет включать в себя элемент external_status, содержащий статус состояния.

Статус состояния домена хранения можно установить в REST API с помощью набора events. Для получения дополнительной информации см. Adding Events в руководстве REST API.

2.6.9.14. Установка флажка "Освободить пространство после удаления (Discard After Delete)" для домена хранения

Когда установлен флажок Сброс после удаления (Discard After Delete), на удаляемом логическом томе вызывается команда blkdiscard, и используемому хранилищу сообщается, что блоки свободны. Массив хранения может использовать освободившееся место и распределять его по запросу. Опция Сброс после удаления (Discard After Delete) работает только в блочном хранилище. Флажок не доступен в Менеджере управления для файлового хранилища такого, как NFS.

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

Опция Сброс после удаления (Discard After Delete) доступна только в доменах блочного хранилища таких, как iSCSI или Fibre Channel.
Используемое хранилище должно поддерживать опцию Освободить (Discard).

Опция Сброс после удаления (Discard After Delete) может быть включена при создании домена блочного хранилища или при его изменении. См. разделы Подготовка и добавление блочного хранилища и Изменение доменов хранения.

2.6.9.15. Мониторинг доступного места в домене хранения

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

Используя Виртуальный оптимизатор данных (VDO) и поддержку тонких пулов, можно увидеть больше доступного места, чем есть физически. Такое поведение ожидаемо для VDO, но Менеджер управления не может предсказать, какое количество данных можно фактически записать. Параметр Порог предупреждения о малом объеме свободного места в домене (Warning Low Space Indicator) сообщает, когда на домене физически заканчивается место и показывает сколько подтвержденного места осталось. Подтвержденное место - это пространство, фактически доступное для записи данных.

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

На Портале администрирования нажмите Хранилище (Storage) Домены (Domains) и нажмите на имя домена хранения.
Нажмите Управление доменом (Manage Domain). Откроется диалоговое окно Управление доменом (Manage Domain).
Разверните Дополнительные параметры (Advanced Parameters).
Для параметра Порог предупреждения о малом объеме свободного места в домене (%) (Warning Low Space Indicator (%)) задайте процентное значение. Когда доступное место в домене хранения достигает этого значения, Менеджер управления предупреждает, что место в домене заканчивается.
Для параметра Порог блокировки при критическом значении свободного места в домене (GB) (Critical Space Action Blocker (GB)) задайте значение в гигабайтах. Когда доступное место в домене хранения достигает этого значения, Менеджер управления производит выключение.
Для параметра Предупреждение об окончании свободного места на диске (%) (Warning Low Confirmed Space Indicator (%)) задайте процентное значение. Когда доступное место в домене хранения достигает этого значения, Менеджер управления предупреждает, что место, фактически доступное для записи данных, заканчивается.

2.7. Пулы

2.7.1. Введение в пулы виртуальных машин

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

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

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

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

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

2.7.2. Создание пула виртуальных машин

Можно создать пул виртуальных машин, в котором будет несколько виртуальных машин, основанных на одном шаблоне. Информацию о запечатывании виртуальной машины и создании шаблона см. в разделе Шаблоны (Templates) в Руководстве по управлению виртуальными машинами.

Варианты конфигурации файла Sysprep для виртуальных машин Windows

В зависимости от ваших требований доступно несколько вариантов конфигурации файла sysprep.

Если пул не нужно присоединять к домену, можно использовать стандартный файл sysprep, расположенный в /usr/share/ovirt-engine/conf/sysprep/.

Если пул необходимо присоединить к домену, то можно создать пользовательский файл sysprep для каждой операционной системы Windows:

Скопируйте соответствующие разделы для каждой операционной системы из файла /usr/share/ovirt-engine/conf/osinfo-defaults.properties в новый файл и сохраните как 99-defaults.properties.
В 99-defaults.properties укажите ключ активации продукта Windows и путь к новому пользовательскому файлу sysprep:
```
os.operating_system.productKey.value=Windows_product_activation_key …
os.operating_system.sysprepPath.value = ${ENGINE_USR}/conf/sysprep/sysprep.operating_system
```

Создайте новый файл sysprep, указав домен, пароль домена и администратора домена:

<Credentials>
    <Domain>__AD_Domain__</Domain>
    <Password>__Domain_Password__</Password>
    <Username>__Domain_Administrator__</Username>
</Credentials>

Если нужно настроить различные параметры sysprep для разных пулов виртуальных машин Windows, то можно создать пользовательский файл sysprep на Портале администрирования (см. раздел Создание пула виртуальных машин ниже). Дополнительные сведения см. в разделе Использование инструмента Sysprep для автоматизации настройки виртуальных машин в Руководстве по управлению виртуальными машинами.

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

Нажмите Ресурсы (Compute) Пулы (Pools).
Нажмите Новый (New).
Выберите Кластер (Cluster) в выпадающем списке.
Выберите Шаблон (Template) и версию в выпадающем меню. Шаблон содержит стандартные настройки для всех виртуальных машин в пуле.
Выберите Операционную систему (Operating System) в выпадающем списке.

Используйте Профиль нагрузки (Optimized for), чтобы оптимизировать виртуальные машины для Рабочей станции (Desktop) или Сервера (Server).

Оптимизация типа Высокая производительность (High Performance) не рекомендуется для пулов, поскольку высокопроизводительная виртуальная машина привязана к одному хосту и конкретным ресурсам. Пул, содержащий несколько виртуальных машин с такой конфигурацией, будет работать плохо. 7. Введите Имя (Name) и при желании Описание (Description) и Комментарий (Comment).

Имя (Name) пула применяется к каждой виртуальной машине в пуле с числовым суффиксом. Можно настроить нумерацию виртуальных машин с помощью знака ? в качестве заполнителя.

Пример 23. Примеры имен пулов и нумерации виртуальных машин

Пул: MyPool

Виртуальные машины: MyPool-1, MyPool-2, … MyPool-10
Пул: MyPool-???

Виртуальные машины: MyPool-001, MyPool-002, … MyPool-010

Укажите Количество ВМ (Number of VMs) в пуле.
Укажите количество виртуальных машин для предварительного запуска в поле Предзапускаемые ВМ (Prestarted).
Укажите Максимальное число ВМ на пользователя (Maximum number of VMs per user), которое одному пользователю разрешено запускать во время сеанса. Минимальное значение: 1.
Установите флажок Защита от удаления (Delete Protection), чтобы включить защиту от удаления.

Если вы создаете пул виртуальных машин не на базе Windows или используете стандартный файл sysprep, то пропустите этот шаг. Если вы создаете пользовательский файл sysprep для пула виртуальных машин Windows:

Нажмите кнопку Показать расширенные настройки (Show Advanced Options).
Перейдите на вкладку Запуск инициализации (Initial Run) и установите флажок Cloud-Init/Sysprep.

Нажмите на стрелку Аутентификация (Authentication) и введите Имя пользователя (User Name) и Пароль (Password) или выберите Пользователь уже установил пароль (Use already configured password).

Имя пользователя (User Name) – это имя локального администратора. Значение по умолчанию user можно изменить здесь в разделе Аутентификация (Authentication) или в пользовательском файле sysprep.

Нажмите на стрелку Пользовательский скрипт (Custom Script) и вставьте содержимое стандартного файла sysprep, расположенного в /usr/share/ovirt-engine/conf/sysprep/, в текстовое поле.

Можно изменить следующие значения файла sysprep:

Key (ключ). Если вы не хотите использовать предустановленный ключ активации продукта Windows, то замените <![CDATA[$ProductKey$]]> на действующий ключ продукта:
<ProductKey> <Key><![CDATA[$ProductKey$]]></Key> </ProductKey>
Пример 24. Пример ключа продукта Windows
<ProductKey> <Key>0000-000-000-000</Key> </ProductKey>

Domain (домен), к которому будут подключены виртуальные машины Windows, Password (пароль) и Username (имя пользователя) администратора домена:

<Credentials>
    <Domain>__AD_Domain__</Domain>
    <Password>__Domain_Password__</Password>
    <Username>__Domain_Administrator__</Username>
</Credentials>

Пример 25. Пример учетных данных домена**

<Credentials>
    <Domain>addomain.local</Domain>
    <Password>12345678</Password>
    <Username>Sarah_Smith</Username>
</Credentials>

Domain, Password и Username обязательны для подключения к домену. Key необходим для активации. Необязательно вам понадобятся сразу и пароль, и ключ.

Домен и учетные данные нельзя изменить на вкладке Запуск инициализации (Initial Run).

FullName (полное имя) локального администратора:
```
<UserData>
...
    <FullName>__Local_Administrator__</FullName>
...
</UserData>
```

DisplayName (Отображаемое имя) и Name (имя) локального администратора:

<LocalAccounts>
    <LocalAccount wcm:action="add">
<Password>
 <Value><![CDATA[$AdminPassword$]]></Value>
 <PlainText>true</PlainText>
</Password>
<DisplayName>__Local_Administrator__</DisplayName>
<Group>administrators</Group>
<Name>__Local_Administrator__</Name>
    </LocalAccount>
</LocalAccounts>

Оставшиеся переменные в файле sysprep можно заполнить на вкладке Запуск инициализации (Initial Run).

Дополнительно. Задайте Тип пула (Pool Type):
- Откройте вкладку Тип (Type) и выберите Тип пула (Pool Type):
  - Руководство (Manual): администратор отвечает за то, чтобы виртуальная машина была возвращена в пул.
  - Автоматический (Automatic): виртуальная машина автоматически возвращается в пул виртуальных машин.
- Установите флажок Пул состояний (Stateful Pool), чтобы виртуальные машины запускались в режиме сохранения состояния. Это позволяет сохранять на виртуальной машине изменения, внесенные предыдущим пользователем.
Дополнительно. Переопределите SPICE-прокси:
- На вкладке Консоль (Console) установите флажок Перезаписать SPICE прокси(Override SPICE Proxy).
- В текстовом поле Перезаписать адрес SPICE прокси (Overridden SPICE proxy address) укажите адрес SPICE-прокси для переопределения глобального SPICE-прокси.
Нажмите OK
Для пула виртуальных машин Windows нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines), выберите каждую виртуальную машину из пула и в меню Запустить (Run) нажмите Однократный запуск (Run Once).

Если виртуальная машина не запускается и в журнале %WINDIR%\panther\UnattendGC\setupact.log появляется Info [windeploy.exe] Found no unattend file, добавьте ключ UnattendFile в реестр виртуальной машины Windows, которая использовалась для создания шаблона пула:

Убедитесь, что у виртуальной машины Windows есть подключенное вспомогательное устройство CD-ROM с файлом ответов (unattend), например, A:\Unattend.xml.
Выберите виртуальную машину и в меню Запустить (Run) нажмите Однократный запуск (Run Once).
В Параметрах загрузки (Boot Options) установите флажок Прикрепить CD c гостевыми дополнениями для Windows (Attach Windows guest tools CD).
Нажмите Пуск (Start), Выполнить (Run), введите regedit в текстовое поле Открыть (Open) и нажмите OK.
В левой панели перейдите в HKEY_LOCAL_MACHINE → SYSTEM → Setup.
Нажмите правой кнопкой мыши на правой панели и выберите Создать (New) → Строковый параметр (String Value).
Введите UnattendFile как имя ключа.
Дважды щелкните по новому ключу и введите имя и путь к файлу unattend, например, A:\Unattend.xml, в качестве значения ключа.
Сохраните реестр, запечатайте виртуальную машину Windows и создайте новый шаблон. Подробности см. в разделе Шаблоны (Templates) в Руководстве по управлению виртуальными машинами.

Вы создали и настроили пул виртуальных машин с указанным количеством идентичных виртуальных машин. Вы можете посмотреть эти виртуальные машины в разделе Ресурсы (Compute) Виртуальные машины (Virtual Machines), или щелкнув по имени пула, чтобы открыть его подробное представление; виртуальная машина в пуле отличается от независимых виртуальных машин своим значком.

2.7.3. Описание настроек и средств управления в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

2.7.3.1. Описание общих настроек в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице представлена информация, которая должна быть указана на вкладке Общие (General) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Новая виртуальная машина (New Virtual Machine).

Таблица 58. Общие настройки (General settings)**
Имя поля	Описание
Шаблон (Template)	Шаблон и подверсия шаблона, на котором основан пул виртуальных машин. Если вы создаете пул на основе самой последней подверсии шаблона, то все виртуальные машины в пуле при перезагрузке автоматически получат самую последнюю версию шаблона. Дополнительные сведения о настройке шаблонов для виртуальных машин см. в разделах Описание общих настроек виртуальной машины и Описание настроек в окнах "Новый шаблон (New Template)" и "Изменить шаблон (Edit Template)" в Руководстве по управлению виртуальными машинами.
Описание (Description)	Содержательное описание пула виртуальных машин.
Комментарий (Comment)	Поле для добавления комментариев о пуле виртуальных машин в виде обычного текста.
Предзапускаемые ВМ (Prestarted VMs)	Здесь можно указать количество виртуальных машин в пуле виртуальных машин, которые будут запущены до того, как их возьмет пользователь, и останутся в этом состоянии, чтобы пользователь мог их взять. Значение этого поля должно быть от 0 до суммарного количества виртуальных машин в пуле виртуальных машин.
Количество ВМ/Увеличить количество ВМ в пуле на (Number of VMs/Increase number of VMs in pool by)	Здесь можно указать количество виртуальных машин, которые будут созданы и доступны в пуле виртуальных машин. В окне изменения можно увеличить количество виртуальных машин в пуле виртуальных машин на указанное число. По умолчанию максимальное количество виртуальных машин, которое можно создать в пуле, равно 1 000. Это значение можно настроить с помощью ключа `MaxVmsInPool` команды `engine-config`.
Максимальное число ВМ на пользователя (Maximum number of VMs per user)	Здесь можно указать максимальное количество виртуальных машин, которые один пользователь может взять из пула виртуальных машин в любой момент времени. Значение этого поля должно быть в диапазоне от 1 до 32 767.
Защита от удаления (Delete Protection)	Здесь можно предотвратить удаление виртуальных машин в пуле.
Запечатать (Sealed)	Гарантия, что настройки конкретных машин по шаблону не будут воспроизведены в виртуальных машинах, предоставленных из шаблона. Дополнительные сведения о процессе запечатывания см. в Фиксация виртуальной машины Windows для развертывания в качестве шаблона руководства по управлению виртуальными машинами

2.7.3.2. Описание настроек типа в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице представлена информация, которая должна быть указана на вкладке Тип (Type) окон Новый пул (New Pool) и Изменить пул (Edit Pool).

Таблица 59. Настройки на вкладке Тип (Type)
Имя поля	Описание
Тип пула (Pool Type)	В этом выпадающем меню можно указать тип пула виртуальных машин. Доступны следующие опции: `Автоматически` (`Automatic`): После того как пользователь прекратил использовать виртуальную машину, взятую из пула виртуальных машин, она автоматически возвращается в пул. `Руководство` (`Manual`): После того как пользователь прекратил использовать виртуальную машину, взятую из пула виртуальных машин, администратор вручную возвращает ее в пул.
Пул состояний (Stateful Pool)	Здесь можно указать, что состояние виртуальной машины в пуле надо сохранять при ее передаче другому пользователю, т.е. изменения, внесенные предыдущим пользователем, сохранятся на виртуальной машине.

2.7.3.3. Описание настроек консоли в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице описана информация, которая должна быть указана на вкладке Консоль (Console) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Новая виртуальная машина (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine).

Таблица 60. Настройки на вкладке Консоль (Console)
Имя поля	Описание
Перезаписать SPICE прокси (Override SPICE proxy)	Поставьте флажок в это поле, чтобы разрешить переопределение SPICE-прокси, заданного в глобальной конфигурации. Эта функция полезна, когда пользователь (например, подключающийся через Пользовательский портал) располагается вне сети, в которой находятся хосты.
Перезаписать адрес SPICE прокси (Overridden SPICE proxy address)	Прокси-сервер, посредством которого клиент SPICE соединяется с виртуальными машинами. Этот прокси-сервер переопределяет как глобальный SPICE-прокси, заданный для среды zVirt, так и SPICE-прокси, заданный для кластера, к которому относится пул виртуальных машин, если таковой имеется. Адрес должен быть задан в следующем формате: `protocol://host:port`

2.7.3.4. Описание настроек хоста пула виртуальных машин

В следующей таблице описаны опции, имеющиеся на вкладке Хост (Host) окон Новый пул (New Pool) и Новый пул (New Pool).

Таблица 61. Пул виртуальных машин: настройки хоста
Имя поля	Доп. элемент	Описание
Запустить на (Start Running On)		Здесь указывается предпочтительный хост, на котором будет запущена виртуальная машина. Можно выбрать один из следующих вариантов: Любом хосте в кластере (Any Host in Cluster) – виртуальная машина может запускаться и работать на любом из доступных хостов кластера. Указанном хосте (Specific Host(s)) – виртуальная машина будет запускаться на конкретном хосте кластера. Однако Менеджер управления или администратор может перенести виртуальную машину на другой хост кластера в зависимости от настроек миграции и высокой доступности виртуальной машины. Выберите конкретный хост или группу хостов из списка доступных хостов.
Параметры ЦП (CPU options)	Passthrough ЦП хоста (Pass-Through Host CPU)	Если выбрана эта опция, то виртуальные машины могут использовать флаги ЦП хоста. Если выбрана эта опция, то Режим миграции (Migration mode) будет установлен в значение Разрешить только ручную миграцию (Allow manual migration only).
Параметры ЦП (CPU options)	Миграция только на хосты с одинаковой частотой TSC (Migrate only to hosts with the same TSC frequency)	Если выбрана эта опция, то эта виртуальная машина может быть перенесена только на хост с такой же частотой TSC. Эта опция подходит только для виртуальных машин с признаком высокой доступности.
Параметры миграции (Migration Options)	Режим миграции (Migration mode)	Здесь можно выбрать параметры запуска и миграции виртуальной машины. Если эти параметры не заданы, то запуск или перенос виртуальной машины будут осуществляться в соответствии с политикой соответствующего кластера. `Разрешить ручную и автоматическую миграцию` (`Allow manual and automatic migration`) – миграция виртуальной машины с одного хоста на другой может выполняться автоматически в соответствии со статусом среды или вручную администратором. `Разрешить только ручную миграцию` (`Allow manual migration only`) – миграция виртуальной машины с одного хоста на другой может выполняться только вручную администратором. `Не разрешать миграцию` (`Do not allow migration`) – автоматическая и ручная миграция виртуальной машины запрещены.
	Политика миграции (Migration policy)	Здесь определяется политика синхронизации состояния памяти при миграции. Если флажок не стоит, то политику определяет хост. * `Использовать кластер по умолчанию (Minimal downtime)` (`Cluster default (Minimal downtime)`) – переопределения в vdsm.conf все еще применяются. Гостевой хук-механизм выключен. * `Minimal downtime`: миграция виртуальных машин в типичных ситуациях разрешена. У виртуальных машин не должно быть значительного простоя. Процесс миграции будет прерван, если синхронизация состояния памяти слишком затянулась (зависит от итераций QEMU, максимум 500 миллисекунд). Гостевой хук-механизм включен. * `Post-copy migration`: когда применяется эта политика, она приостанавливает виртуальные ЦП мигрирующей виртуальной машины на хосте-источнике, переносит только минимальное количество страниц памяти, активирует виртуальные ЦП виртуальной машины на хосте-приемнике и переносит оставшиеся страницы памяти, пока виртуальная машина работает на хосте-приемнике. Политика миграции с пост-копированием сначала пытается провести предварительное копирование, чтобы убедиться, что синхронизация состояния памяти пройдет успешно. Миграция переключается в режим с пост-копированием, если при миграции виртуальной машины затянулась синхронизация состояния памяти. Так значительно сокращается время простоя мигрируемой виртуальной машины, а также гарантируется, что миграция завершится независимо от того, насколько быстро меняются страницы памяти виртуальной машины на хосте-источнике. Это оптимальный вариант для миграции виртуальных машин в условиях интенсивного непрерывного использования, когда их невозможно перенести стандартным способом с предварительным копированием. Недостаток этой политики заключается в том, что на этапе пост-копирования виртуальная машина может сильно замедлиться из-за переноса недостающих частей памяти между хостами. IMPORTANT: Если сетевое соединение прерывается до завершения процесса пост-копирования, то Менеджер управления приостанавливает, а затем выключает работающую виртуальную машину. Не прибегайте к миграции с пост-копированием, если доступность виртуальной машины критически важна или если сеть миграции нестабильна. * `Suspend workload if needed`: Эта политика разрешает миграцию виртуальных машин в большинстве случаев, включая перенос виртуальных машин, на которых запущены ресурсоемкие процессы, но из-за этого могут происходить более длительные простои ВМ, чем при других настройках. Миграция, тем не менее, может быть прервана при экстремальных нагрузках. Гостевой хук-механизм включен.
	Включить шифрование при миграции (Enable migration encryption)	Эта политика позволяет шифровать виртуальную машину в процессе миграции. * `Использовать кластер по умолчанию (не шифровать)` (`Cluster default (Don’t encrypt)`) * `Шифровать` (`Encrypt`) * `Не шифровать` (`Don’t encrypt`)
Конфигурировать NUMA (Configure NUMA)	Количество узлов NUMA (NUMA Node Count)	Количество виртуальных узлов NUMA, доступных в хосте, которые можно назначить виртуальной машине.
Конфигурировать NUMA (Configure NUMA)	Закрепление NUMA (NUMA Pinning)

2.7.3.5. Описание настроек выделения ресурсов в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице представлена информация, которая должна быть указана на вкладке Выделение ресурсов (Resource Allocation) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Новая виртуальная машина (New Virtual Machine). Дополнительные сведения см. в разделе Описание настроек выделения ресурсов виртуальных машин в Руководстве по управлению виртуальными машинами.

Таблица 62. Настройки выделения ресурсов
Имя поля	Доп. элемент	Описание
Выделение дискового пространства (Disk Allocation)	Автоматический выбор цели (Auto select target)	Установите этот флажок, чтобы автоматически выбрать домен хранения, в котором больше всего свободного места. Поля Цель (Target) и Профиль диска (Disk Profile) отключены.
Выделение дискового пространства (Disk Allocation)	Формат (Format)	Это поле только для чтения и всегда показывает QCOW2.

2.7.3.6. Изменение пула виртуальных машин

После создания пула виртуальных машин его свойства можно менять. Доступные для изменения свойства пула виртуальных машин идентичны тем, что доступны при создании нового пула виртуальных машин, за исключением того, что свойство Количество ВМ (Number of VMs) заменено на свойство Увеличить число ВМ в пуле на (Increase number of VMs in pool by).

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

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

Нажмите Ресурсы (Compute) Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
Измените свойства пула виртуальных машин.
Нажмите OK.

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

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

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

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

Нажмите Ресурсы (Compute) Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
В поле Предзапускаемые ВМ (Prestarted Vms) введите нужное количество виртуальных машин для предварительного запуска.
Откройте вкладку Тип (Type). Убедитесь, что для параметра Тип пула (Pool Type) установлено значение Автоматически (Automatic).
Нажмите OK.

2.7.3.8. Добавление виртуальных машин в пул виртуальных машин

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

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

Нажмите Ресурсы (Compute) Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
В поле Увеличить число ВМ в пуле на (Increase number of VMs in pool by) введите количество дополнительных виртуальных машин.
Нажмите OK.

2.7.3.9. Отключение виртуальных машин от пула виртуальных машин

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

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

Нажмите Ресурсы (Compute) Пулы (Pools).
Нажмите имя пула. Откроется подробное представление.
Откройте вкладку Виртуальные машины (Virtual Machines), чтобы посмотреть список виртуальных машин в пуле.
Убедитесь, что виртуальная машина имеет статус Выключено (Down) ; отключить работающую виртуальную машину нельзя.
Выберите одну или несколько виртуальных машин и нажмите Отсоединить (Detach).
Нажмите OK.

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

2.7.3.10. Удаление пула виртуальных машин

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

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

Нажмите Ресурсы (Compute) Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Удалить (Remove).
Нажмите OK.

2.8. Виртуальные диски

2.8.1. Общие сведения о хранилище виртуальной машины

zVirt поддерживает три типа хранилищ: NFS, iSCSI и FCP.

В каждом из этих типов хранилища хост, называемый Менеджером пула хранения (Storage Pool Manager, SPM), управляет операциями доступа между хостами и хранилищем. Хост SPM - это единственный узел, имеющий права полного доступа в пуле хранения. SPM может изменять метаданные домена хранения и метаданные пула. Все другие хосты могут только получать доступ к данным образа жесткого диска виртуальной машины.

По умолчанию в NFS, локальном или POSIX-совместимом центре данных SPM создает виртуальный диск, используя формат с динамическим выделением пространства, в виде файла в файловой системе.

В центрах данных с хранилищами iSCSI и другими блочными хранилищами SPM создает группу томов поверх предоставленных LUN и формирует логические тома для использования в качестве виртуальных дисков. Виртуальные диски в блочном хранилище являются по умолчанию дисками с предварительно выделенным пространством.

Если виртуальному диску предварительно выделено дисковое пространство, то создается логический том указанного размера в гигабайтах. Виртуальную машину можно смонтировать на сервере Linux, используя команды kpartx,` vgscan`, vgchange или mount для исследования процессов или проблем на виртуальной машине.

При использовании виртуального диска с динамическим выделением пространства создается логический том размером 1 ГБ. Хост, на котором запущена виртуальная машина, непрерывно ведет мониторинг логического тома. Как только использование приблизится к пороговому значению, хост оповестит SPM, и SPM увеличит размер логического тома на 1 ГБ. Хост отвечает за возобновление работы виртуальной машины после увеличения размера логического тома. Если виртуальная машина перейдет в состояние приостановки работы, то это будет означать, что SPM не смог вовремя увеличить размер диска. Это происходит, когда SPM слишком занят или когда в хранилище недостаточно дискового пространства.

Виртуальный диск формата raw (с предварительно выделенным пространством) обеспечивает намного более быструю запись, чем виртуальный диск формата QCOW2 (с динамическим выделением пространства. Создание виртуального диска с динамическим выделением пространства занимает гораздо меньше времени. Формат с динамическим выделением пространства подходит для виртуальных машин с не интенсивным потоком операций ввода-вывода. Формат с предварительно выделенным пространством рекомендуется для виртуальных машин с большим количеством операций записи при вводе-выводе. Если виртуальная машина способна записывать более 1 ГБ каждые четыре секунды, то по возможности используйте диски с предварительно выделенным пространством.

2.8.2. Общие сведения о виртуальных дисках

zVirt предусматривает хранилища двух типов: С предварительно размеченным пространством (Preallocated) (thick provisioned) и Динамически расширяемый (Sparse) (thin provisioned).

С предварительно размеченным пространством

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

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

Например, сразу после создания динамически расширяемый логический том размером 20 ГБ будет занимать 0 ГБ дискового пространства. Когда операционная система установлена, она может занять размер установленных файлов и по мере добавления данных продолжит увеличиваться до максимального размера 20 ГБ.

Чтобы просмотреть идентификатор ID виртуального диска, выберите Хранилище (Storage) Диски (Disks). ID используется для идентификации виртуального диска, так как имя его устройства (например, /dev/vda0) может измениться, что приведет к повреждению диска. Идентификатор виртуального диска также можно просмотреть в /dev/disk/by-id.

Можно просмотреть Виртуальный размер (Virtual Size) диска, выбрав Хранилище (Storage) Диски (Disks), а также на вкладке Диски (Disks) в подробном представлении доменов хранения, виртуальных машин и шаблонов.

Виртуальный размер (Virtual Size) - это общий объем дискового пространства, который может использовать виртуальная машина. Это число, которое вы вводите в поле Размер (ГБ) (Size (GB)) при создании или изменении виртуального диска.

Актуальный размер (Actual Size) диска можно просмотреть на вкладке Диски (Disks) в подробном представлении доменов хранения и шаблонов. Это объем дискового пространства, выделенный сейчас виртуальной машине. У дисков с предварительно размеченным пространством значения параметров Виртуальный размер (Virtual Size) и Актуальный размер (Actual Size) одинаковы. У динамически расширяемых дисков значения этих параметров могут быть разными в зависимости от размера выделенного дискового пространства.

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

Таблица 63. Допустимые комбинации типов и форматов хранилища
Хранилище	Формат	Тип	Примечание
NFS	Raw	С предварительно размеченным пространством	Неформатированный файл, изначальный размер которого равен размеру пространства, заданного для виртуального диска.
NFS	Raw	Динамически расширяемый	Неформатированный файл с изначальным размером, близким к нулю.
NFS	QCOW2	Динамически расширяемый	Файл формата QCOW2 с изначальным размером, близким к нулю. Последующие уровни будут отформатированы в формате QCOW2.
SAN	Raw	С предварительно размеченным пространством	Неформатированное блочное устройство, изначальный размер которого равен размеру пространства, заданного для виртуального диска.
SAN	QCOW2	Динамически расширяемый	Блочное устройство формата QCOW2, изначальный размер которого намного меньше размера, заданного для виртуального диска (сейчас - 1 ГБ) и которому дисковое пространство выделяется по мере необходимости (сейчас - с шагом 1 ГБ).

2.8.3. Настройки для очистки виртуальных дисков после удаления

Если поставить флаг wipe_after_delete, который на Портале администрирования отображается как Очистить после удаления (Wipe After Delete), то при удалении виртуального диска используемые данные будут заменены нулями. Если для него установлено значение false (это значение по умолчанию), то при удалении диска эти блоки будут доступны для повторного использования, но данные не будут стерты. Поэтому эти данные можно будет восстановить, так как блоки не были обнулены.

Флаг wipe_after_delete работает только с блочным хранилищем. В файловом хранилище, например, NFS, этот параметр бесполезен, так как файловая система гарантирует отсутствие данных.

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

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

В процессе настройки значение по умолчанию для флага wipe_after_delete можно изменить на true (см. раздел Настройка Менеджера управления) или с помощью инструмента engine-config в Менеджере управления. Чтобы изменение настроек вступило в силу, перезапустите службу ovirt-engine.

Изменение значения по умолчанию для флага wipe_after_delete не повлияет на свойство Очистить после удаления (Wipe After Delete) уже существующих дисков.

Установка для параметра SANWipeAfterDelete значения по умолчанию True с помощью утилиты Engine Configuration Tool

Запустите утилиту engine-config, задав следующее действие --set:
```
# engine-config --set SANWipeAfterDelete=true
```
Перезапустите службу ovirt-engine, чтобы изменения вступили в силу:
```
# systemctl restart ovirt-engine.service
```

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

В случае успешной очистки файл журнала будет содержать запись storage_domain_id/volume_id was zeroed and will be deleted. Например:

a9cb0625-d5dc-49ab-8ad1-72722e82b0bf/a49351a7-15d8-4932-8d67-512a369f9d61 was zeroed and will be deleted

В случае успешного удаления файл журнала будет содержать запись finished with VG:storage_domain_id LVs: list_of_volume_ids, img: image_id. Например:

finished with VG:a9cb0625-d5dc-49ab-8ad1-72722e82b0bf LVs: {'a49351a7-15d8-4932-8d67-512a369f9d61':
ImgsPar(imgs=['11f8b3be-fa96-4f6a-bb83-14c9b12b6e0d'], parent='00000000-0000-0000-0000-000000000000')}, img: 11f8b3be-fa96-4f6a-bb83-14c9b12b6e0d

В случае неудачной попытки очистки будет показано сообщение журнала zeroing storage_domain_id/volume_id failed. Zero and remove this volume manually. В случае неудачной попытки удаления будет показано сообщение Remove failed for some of VG: storage_domain_id zeroed volumes: list_of_volume_ids.

2.8.4. Общие диски в zVirt

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

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

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

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

2.8.5. Диски "только для чтения (Read Only)" в zVirt

Некоторые приложения требуют, чтобы администраторы открывали общий доступ к данным только для чтения. Это можно сделать при создании или изменении диска, подключенного к виртуальной машине: откройте вкладку Диски (Disks) в подробном представлении виртуальной машины и установите флажок Только для чтения (Read Only). Таким образом несколько гостевых машин, учитывающих особенности кластера, могут читать один и тот же диск, при этом администратор сохраняет за собой права на запись.

Статус диска "только для чтения" нельзя изменить во время работы виртуальной машины.

Для монтирования журналируемой файловой системы требуется доступ с правами на чтение и запись. Использование параметра Только для чтения (Read Only) не подходит для виртуальных дисков, содержащих файловые системы EXT3, EXT4 или XFS.

2.8.6. Задачи, относящиеся к виртуальному диску

2.8.6.1. Создание виртуального диска

Созданием диска типа Образ (Image) полностью управляет Менеджер управления. Для дисков Прямой LUN (Direct LUN) требуются уже существующие таргеты, подготовленные извне. Можно создать виртуальный диск, подключенный к конкретной виртуальной машине. Дополнительные параметры доступны при создании подключенного виртуального диска, как указано в разделе Описание настроек в окне "Новый диск (New Virtual Disk)".

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

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Нажмите имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks).
Нажмите Новый (New).
Нажатием соответствующей кнопки задайте тип создаваемого виртуального диска: Образ (Image) или Прямой LUN (Direct LUN).
Выберите параметры, необходимые для виртуального диска. Параметры меняются в зависимости от выбранного типа диска. Подробное описание каждого параметра для каждого типа диска см. в разделе Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

Можно также создать плавающий виртуальный диск, не принадлежащий ни одной виртуальной машине. Этот диск можно подключить к одной или к нескольким виртуальным машинам, если его можно сделать общим. При создании виртуального диска недоступны некоторые параметры, указанные в разделе [Описание настроек в окне "Новый диск (New Virtual Disk)](#2862-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BA-%D0%B2-%D0%BE%D0%BA%D0%BD%D0%B5-%D0%9D%D0%BE%D0%B2%D1%8B%D0%B9-%D0%B4%D0%B8%D1%81%D0%BA-New-Virtual-Disk).

Создание плавающего виртуального диска

Нажмите Хранилище (Storage) Диски (Disks).
Нажмите Новый (New).
Нажатием соответствующей кнопки задайте тип создаваемого виртуального диска: Образ (Image) или Прямой LUN (Direct LUN).
Выберите параметры, необходимые для виртуального диска. Параметры меняются в зависимости от выбранного типа диска. Подробное описание каждого параметра для каждого типа диска см. в разделе Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)"

Поскольку окна "Новый диск (New Virtual Disk)" для создания плавающих и подключенных виртуальных дисков очень похожи, их настройки описываются в одном разделе.

Таблица 64. Настройки в окнах "Новый диск (New Virtual Disk)" и "Изменить диск (Edit Virtual Disk)": Образ (Image)
Имя поля	Описание
Размер (GiB) (Size (GB))	Размер нового виртуального диска в ГБ.
Имя (Alias)	Имя виртуального диска (не более 40 знаков).
Описание (Description)	Описание виртуального диска. Это поле является рекомендованным, но не обязательным.
Интерфейс (Interface)	Это поле появляется только при создании подключенного диска. Виртуальный интерфейс, который диск представляет виртуальным машинам. VirtIO обеспечивает более высокую скорость, но для него требуются драйверы. В Linux, как правило, эти драйверы уже есть. В Windows этих драйверов нет, но их можно установить из ISO-образа virtio-win. Для устройств IDE и SATA никаких особых драйверов не требуется. Тип интерфейса можно обновить после остановки всех виртуальных машин, к которым подключен диск.
Центр данных (Data Center)	Это поле появляется только при создании плавающего диска. Центр данных, в котором будет доступен виртуальный диск.
Домен хранения (Storage Domain)	Домен хранения, в котором будет храниться виртуальный диск. В раскрывающемся списке показаны все домены хранения, доступные в конкретном центре данных, а также общее и доступное сейчас дисковое пространство в домене хранения.
Политика выделения (Allocation Policy)	Политика предоставления ресурсов новому виртуальному диску `Предварительно размеченный` (`Preallocated`): при создании виртуального диска ему выделяется все пространство диска в домене хранения. У диска с предварительно размеченным пространством виртуальный размер и актуальный размер совпадают. Создание виртуальных дисков с предварительно размеченным пространством занимает больше времени, чем создание виртуальных дисков с динамическим выделением пространства, но они обеспечивают более высокую скорость операций чтения и записи. Виртуальные диски с предварительно размеченным пространством рекомендуются для серверов и других виртуальных машин с интенсивным потоком операций ввода-вывода. Если виртуальная машина способна записывать более 1 ГБ каждые четыре секунды, то по возможности используйте диски с предварительно размеченным пространством. `Динамически расширяемый (Thin Provision)`: при создании виртуального диска ему выделяется 1 ГБ и устанавливается максимально допустимый размер, до которого может увеличиваться его емкость. Виртуальный размер диска равен максимально допустимому размеру; актуальный размер диска - это пространство, выделенное по состоянию на сейчас. Диски с динамическим выделением пространства создаются быстрее, чем диски с предварительно размеченным пространством, и допускают избыточное выделение ресурсов хранилища. Виртуальные диски с динамическим выделением пространства рекомендуются для рабочих станций.
Профиль диска (Disk Profile)	Профиль диска, назначенный виртуальному диску. Профили дисков определяют максимальную пропускную способность и максимальный уровень операций ввода-вывода для виртуального диска в домене хранения. Профили дисков определяются на уровне домена хранения в зависимости от качества хранения записей службы, созданных для центров данных.
Включение дисков (Activate Disk(s))	Это поле появляется только при создании подключенного диска. Активирует виртуальный диск сразу после создания.
Очистить после удаления (Wipe After Delete)	Позволяет включить повышенную защиту для удаления конфиденциальных материалов при удалении виртуального диска.
Загрузочный (Bootable)	Это поле появляется только при создании подключенного диска. Позволяет пометить виртуальный диск флагом "Загрузочный (Bootable)".
Может быть общим (Shareable)	Позволяет подключить виртуальный диск одновременно к нескольким виртуальным машинам.
Только для чтения (Read-Only)	Это поле появляется только при создании подключенного диска. Позволяет для диска установить атрибут "только для чтения". Один и тот же диск можно подключить к одной виртуальной машине как доступный только для чтения, а к другой - как перезаписываемый.
Включить инкрементное резервное копирование (Enable Incremental Backup)	Включает инкрементное резервное копирование на виртуальный диск. Для инкрементного резервного копирования необходимо, чтобы диски были отформатированы в формате QCOW2, а не в формате RAW. См. раздел [3.2.5.Резервное копирование и восстановление виртуальных машин с помощью API инкрементного резервного копирования и восстановления].
Включить Discard (Enable Discard)	Это поле появляется только при создании подключенного диска. Позволяет уменьшать размер диска с динамическим выделением пространства во время работы виртуальной машины. Для блочного хранилища базовое устройство хранения должно поддерживать вызовы функции `discard`, и этот параметр нельзя использовать с параметром Очистить после удаления (Wipe After Delete), если базовое хранилище не поддерживает свойство `discard_zeroes_data`. Для хранилища файлов базовая файловая система и блочное устройство должны поддерживать вызовы функции `discard`. Если все требования удовлетворены, то QEMU передает команды SCSI UNMAP с гостевых виртуальных машин в базовое хранилище для высвобождения неиспользуемого пространства.

Чтобы показать настройки Прямого LUN (Direct LUN), выберите Цели (Targets) > LUNs или LUNs > Цели (Targets). Если выбрать Цели (Targets) > LUNs, то доступные LUN будут отсортированы в соответствии с хостом, на котором они обнаружены, а если выбрать LUNs > Цели (Targets), то будет показан один общий список LUN.

Заполните поля в разделе Обнаружение целей (Discover Targets) и нажмите Обнаружение (Discover), чтобы обнаружить целевой сервер. Затем нажмите кнопку Войти везде (Login All), чтобы просмотреть список доступных LUN на целевом сервере, и нажатием кнопки-переключателя Добавить (Add) рядом с каждым LUN выберите LUN для добавления.

Использование Прямого LUN (Direct LUN) в качестве образов жестких дисков виртуальных машин устраняет слой абстракции между виртуальными машинами и их данными.

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

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

Таблица 65. Настройки в окнах "Новый диск (New Virtual Disk) и "Изменить диск (Edit Virtual Disk)": Прямой LUN (Direct LUN)
Имя поля	Описание
Имя (Alias)	Имя виртуального диска (не более 40 знаков).
Описание (Description)	Описание виртуального диска. Это поле является рекомендованным, но не обязательным. По умолчанию в это поле вставляются последние 4 знака идентификатора LUN ID. Действие по умолчанию можно настроить, установив для ключа конфигурации `PopulateDirectLUNDiskDescriptionWithLUNId` соответствующее значение с помощью команды `engine-config`. Для ключа конфигурации можно установить значение `-1`, чтобы использовать полный LUN ID, или значение `0`, чтобы игнорировать эту функцию. Если задать положительное целое число, то описание будет заполнено соответствующим количеством знаков LUN ID.
Интерфейс (Interface)	Это поле появляется только при создании подключенного диска. Виртуальный интерфейс, который диск представляет виртуальным машинам. VirtIO обеспечивает более высокую скорость, но для него требуются драйверы. В Linux, как правило, эти драйверы уже есть. В Windows этих драйверов нет, но их можно установить из ISO-образа virtio-win. Для устройств IDE и SATA никаких особых драйверов не требуется. Тип интерфейса можно обновить после остановки всех виртуальных машин, к которым подключен диск.
Центр данных (Data Center)	Это поле появляется только при создании плавающего диска. Центр данных, в котором будет доступен виртуальный диск.
Хост (Host)	Хост, на который будет смонтирован LUN. Можно выбрать любой хост в центре данных.
Тип хранилища (Storage Type)	Тип внешнего LUN для добавления. Можно выбрать либо `iSCSI`, либо `Fibre Channel`.
Обнаружение целей (Discover Targets)	Этот раздел можно развернуть, когда используются внешние LUN iSCSI и выбрана панель Цели (Targets) > LUNs. Адрес (Address) - имя хоста или IP-адрес целевого сервера. Порт (Port) - порт, через который нужно попытаться подключиться к целевому серверу. Порт по умолчанию – 3260. Аутентификация пользователя (User Authentication) - для сервера iSCSI требуется аутентификации пользователя. Поле Аутентификация пользователя (User Authentication) отображается при использовании внешних iSCSI LUN. Имя пользователя CHAP (CHAP user name) - имя пользователя, которому разрешен вход в LUN. Это поле доступно, если установлен флажок Аутентификация пользователя (User Authentication). Пароль CHAP (CHAP password) - пароль пользователя, которому разрешен вход в LUN. Это поле доступно, если установлен флажок Аутентификация пользователя (User Authentication).
Включение дисков (Activate Disk(s))	Это поле появляется только при создании подключенного диска. Активирует виртуальный диск сразу после создания.
Загрузочный (Bootable)	Это поле появляется только при создании подключенного диска. Позволяет пометить виртуальный диск флажком "Загрузочный (Bootable)".
Может быть общим (Shareable)	Позволяет подключить виртуальный диск одновременно к нескольким виртуальным машинам.
Только для чтения (Read-Only)	Это поле появляется только при создании подключенного диска. Позволяет для диска установить атрибут "только для чтения". Один и тот же диск можно подключить к одной виртуальной машине как доступный только для чтения, а к другой - как перезаписываемый.
Включить Discard (Enable Discard)	Это поле появляется только при создании подключенного диска. Позволяет уменьшать размер диска с динамическим выделением пространства во время работы виртуальной машины. Если этот параметр включен, то QEMU передает команды SCSI UNMAP с гостевых виртуальных машин в базовое хранилище для высвобождения неиспользуемого пространства.
Включить интерфейс SCSI (Enable SCSI Pass-Through)	Это поле появляется только при создании подключенного диска. Доступно, когда для параметра Интерфейс (Interface) установлено значение VirtIO-SCSI. Установка этого флажка включает сквозной доступ с физического устройства SCSI на виртуальный диск. Интерфейс VirtIO-SCSI с включенным сквозным доступом SCSI автоматически включает поддержку функции `discard` для SCSI. Только для чтения (Read-Only) не поддерживается, когда установлен этот флажок. Если этот флажок не установлен, то виртуальный диск использует эмулируемое устройство SCSI. Только для чтения (Read-Only) поддерживается на эмулируемых дисках VirtIO-SCSI.
Разрешить привилегированный ввод-вывод SCSI (Allow Privileged SCSI I/O)	Это поле появляется только при создании подключенного диска. Доступно, если установлен флажок Включить интерфейс SCSI (Enable SCSI Pass-Through). Установка этого флажка включает нефильтруемый доступ SCSI Generic I/O (SG_IO) и разрешает использование привилегированных команд SG_IO на диске. Это необходимо для постоянных резервирований.
Используется резервирование SCSI (Using SCSI Reservation)	Это поле появляется только при создании подключенного диска. Доступно, если установлены флажки Включить интерфейс SCSI (Enable SCSI Pass-Through) и Разрешить привилегированный ввод-вывод SCSI (Allow Privileged SCSI I/O). Установка этого флажка отключает миграцию для всех виртуальных машин, использующих этот диск, чтобы виртуальные машины, использующие резервирование SCSI, не утратили доступ к диску.

Для монтирования журналируемой файловой системы требуется доступ с правами на чтение и запись. Использование параметра Только для чтения (Read-Only) не подходит для виртуальных дисков, содержащих файловые системы EXT3, EXT4 или XFS.

2.8.6.3. Общие сведения о миграции между хранилищами "на лету"

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

Обратите внимание на следующее при выполнении миграции между хранилищами "на лету":

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

2.8.6.4. Перемещение виртуального диска

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

Обратите внимание на следующее при переносе диска:

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

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

Нажмите Хранилище (Storage) Диски (Disks) и выберите один или несколько виртуальных дисков для переноса.
Нажмите Переместить (Move).
Из списка Цель (Target) выберите домен хранения, в который виртуальный(е) диск(и) будет(ут) перенесены.
Из списка Профиль диска (Disk Profile) выберите профиль для диска(ов), если применимо.
Нажмите OK.

Виртуальные диски перемещаются в целевой домен хранения. Во время перемещения в столбце Статус (Status) высвечивается Заблокирован (Locked), а индикатор выполнения отображает прогресс выполнения переноса.

2.8.6.5. Изменение типа интерфейса диска

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

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

Изменение типа интерфейса диска

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

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

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

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines) и остановите соответствующую(ие) виртуальную(ые) машину(ы).
Нажмите на имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks) и выберите диск.
Нажмите Удалить (Remove), затем OK.
Вернитесь к разделу Виртуальные машины (Virtual Machines) и нажмите на имя новой виртуальной машины, к которой будет подключен диск.
Откройте вкладку Диски (Disks), затем нажмите Прикрепить (Attach).
Выберите диск в окне Прикрепить виртуальные диски (Attach Virtual Disks) и выберите соответствующий интерфейс из выпадающего списка Интерфейс (Interface).
Нажмите OK.

2.8.6.6. Копирование виртуального диска

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

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

Нажмите Хранилище (Storage) Диски (Disks) и выберите виртуальный(ые) диск(и).
Нажмите Копировать (Copy).
При желании задайте новое имя в поле Имя (Alias).
Из списка Цель (Target) выберите домен хранения, в который диск(и) будет(ут) скопирован(ы).
Из списка Профиль диска (Disk Profile) выберите профиль для диска(ов), если применимо.
Нажмите OK.

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

2.8.6.7. Повышение производительности диска

На Портале администрирования в окнах Новая виртуальная машина (New virtual machine) и Изменить виртуальную машину (Edit virtual machine) на вкладке Выделение ресурсов (Resource Allocation) устанавливается (включается) настройка по умолчанию Количество потоков I/O (I/O Threads Enabled), а количество потоков равно 1.

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

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

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

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

В разделе Ресурсы (Compute) Виртуальные машины (Virtual Machines) выберите нужную машину и нажмите Выключить (Power Off).
Нажмите на имя виртуальной машины.
В подробном представлении откройте вкладку Устройства ВМ (Vm Devices).
Посчитайте количество контроллеров с Типом (Type) virtio или virtio-scsi.
Нажмите Изменить (Edit).
В окне Изменить виртуальную машину (Edit Virtual Machine) откройте вкладку Выделение ресурсов (Resource Allocation).
Подтвердите установку (включение) настройки Количество потоков I/O (I/O Threads Enabled).
Справа от настройки Количество потоков I/O (I/O Threads Enabled) увеличьте количество потоков так, чтобы оно не превышало количество контроллеров с типом virtio или virtio-scsi.
Нажмите OK.
В подробном представлении откройте вкладку Диски (Discs).
Для каждого диска используйте раздел Дополнительные действия (More Actions) , чтобы Выключить (Deactivate) и Включить (Activate) диск. Это действие пересопоставит диски с контроллерами.
Нажмите Запустить (Run), чтобы запустить виртуальную машину.

Действия по проверке:

Для просмотра контроллеров с потоком ввода-вывода нажмите Устройства ВМ (Vm Devices) в подробном представлении и в столбце Специальные параметры (Spec Params) найдите ioThreadid=.
Чтобы увидеть сопоставление дисков контроллерам, авторизуйтесь на машине хоста и введите следующую команду:
```
# virsh -r dumpxml virtual_machine_name
```
Дополнительные ресурсы
Настройка высокопроизводительных виртуальных машин
Описание настроек выделения ресурсов виртуальных машин

2.8.6.8. Выгрузка образов в домен хранения данных

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

2.8.6.9. Импортирование образа диска из импортированного домена хранения

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

Только диски, совместимые с QEMU, можно импортировать в Менеджер управления.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя импортированного домена хранения. Откроется подробное представление.
Откройте вкладку Импорт диска (Disk Import).
Выберите один или несколько дисков и нажмите Импортировать (Import).
Выберите подходящий Профиль диска (Disk Profile) для каждого диска.
Нажмите OK.

2.8.6.10. Импортирование незарегистрированного образа диска из импортированного домена хранения

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

Только диски, совместимые с QEMU, можно импортировать в Менеджер управления.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Нажмите Дополнительные действия (More Actions) , затем нажмите Сканировать диски (Scan Disks), чтобы Менеджер управления мог обнаружить незарегистрированные диски.
Откройте вкладку Импорт диска (Disk Import).
Выберите один или несколько образов дисков и нажмите Импортировать (Import).
Выберите подходящий Профиль диска (Disk Profile) для каждого диска.
Нажмите OK.

2.8.6.11. Импортирование виртуального диска из OpenStack Image Service

Виртуальные диски, управляемые службой OpenStack Image Service, можно импортировать в Менеджер управления, если служба OpenStack Image Service была добавлена в Менеджер управления как внешний провайдер.

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

Нажмите Хранилище (Storage) Домены (Domains).
Нажмите на имя домена OpenStack Image Service. Откроется подробное представление.
Откройте вкладку Образы (Images) и выберите образ.
Нажмите Импортировать (Import).
Выберите Центр данных (Data Center), в который будет импортирован образ.
Из выпадающего списка Имя домена (Domain Name) выберите домен хранения, в котором будет храниться образ.
При желании из выпадающего списка Квота (Quota) выберите квоту для применения к образу.
Нажмите OK.

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

2.8.6.12. Экспортирование виртуального диска в OpenStack Image Service

Виртуальные диски можно экспортировать в службу OpenStack Image Service, которая была добавлена в Менеджер управления как внешний провайдер.

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

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

Нажмите Хранилище (Storage) Диски (Disks) и выберите диски для экспорта.
Нажмите Дополнительные действия (More Actions) и затем Экспортировать (Export).
Из выпадающего списка Имя домена (Domain Name) выберите службу OpenStack Image Service, куда будут экспортированы диски.
Из выпадающего списка Квота (Quota) выберите квоту для дисков, если применимо.
Нажмите OK.

2.8.6.13. Высвобождение пространства виртуального диска

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

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

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

В домене хранения NFS должна использоваться версия NFS 4.2 или выше.
На диске с Прямым LUN нельзя высвободить пространство.
Нельзя высвободить пространство на диске с предварительно выделенным пространством. При создании виртуальной машины из шаблона нужно выбрать Динамический (Thin) в поле Выделение хранилища (Storage Allocation) или при выборе варианта Клонировать (Clone) убедитесь, что шаблон основан на виртуальной машине с динамическим выделением пространства.
Высвобождать пространство можно только на активных снимках.

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

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines) и остановите нужную виртуальную машину.
Нажмите на имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks). Убедитесь, что статус диска - OK.
Нажмите Дополнительные действия (More Actions) и затем Оптимизация диска (Sparsify).
Нажмите OK.

Событие Высвобождение пространства началось (Started to sparsify) появится на вкладке События (Events) во время выполнения операции высвобождения пространства, а у диска будет статус Заблокирован (Locked). После завершения операции на вкладке События (Events) появится событие Высвобождение пространства прошло успешно (Sparsified successfully), а у диска будет статус OK. Неиспользуемое место на диске было возвращено на хост и доступно для использования другими виртуальными машинами.

2.9. Внешние провайдеры

2.9.1. Общая информация о внешних провайдерах в zVirt

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

Сейчас в zVirt поддерживаются следующие внешние провайдеры:

KubeVirt/Openshift Virtualization

Служба OpenStack Image Service (Glance) для управления образами

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

VMware для выделения виртуальных машин

Виртуальные машины, созданные в VMware, можно преобразовать, используя V2V (virt-v2v), и импортировать в среду zVirt. После добавления провайдера VMware в Менеджер управления можно импортировать виртуальные машины, которые он предоставляет. Преобразование V2V выполняется на указанном прокси-хосте в рамках импортирования.

KVM для выделения виртуальных машин

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

Open Virtual Network (OVN) для выделения сетей

Open Virtual Network (OVN) - расширение Open vSwitch (OVS), предоставляющее программно-определяемые сети. После добавления OVN в Менеджер управления можно импортировать существующие сети OVN и создать новые сети OVN из Менеджера управления. Можно также автоматически установить OVN на Менеджер управления, используя engine-setup.

2.9.2. Добавление внешних провайдеров

2.9.2.1. Добавление экземпляра OpenStack Image (Glance) для управления образами

Добавьте экземпляр OpenStack Image (Glance) в Менеджер управления для управления образами.

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

Нажмите Управление (Administration) Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробности на вкладке Общие (General Settings). Дополнительные сведения об этих полях см. в разделе Описание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
Из выпадающего списка Тип (Type) выберите OpenStack Image.
В текстовом поле URL провайдера (Provider URL) введите URL или FQDN машины, на которой установлен экземпляр OpenStack Image.
При желании установите флажок Требуется авторизация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для пользователя экземпляра OpenStack Image, зарегистрированного в Keystone. Нужно также задать URL-адрес аутентификации сервера Keystone, задав Протокол (Protocol) (должен быть HTTP), Имя хоста (Hostname) и Порт API (API Port).

Укажите Доменное имя пользователя (User Domain Name), Название проекта (Project Name) и Доменное имя проекта (Project Domain Name) для экземпляра OpenStack Image.
Проверка учетных данных:
1. Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на экземпляре OpenStack Image с использованием предоставленных учетных данных.
2. Если в экземпляре OpenStack Image используется SSL, то откроется окно Импортировать сертификаты провайдера. Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром OpenStack Image, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

2.9.2.2. Добавление KubeVirt/Openshift Virtualization в качестве внешнего провайдера

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

Эта функция называется OpenShift Virtualization.

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

На платформе OpenShift Container Platform ваш кластер конфигурируется для OpenShift Virtualization.

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

На Портале администрирования выберите Управление (Administration) Провайдеры (Providers) и нажмите Добавить (Add).
В окне Добавить провайдер (Add Provider) выберите значение Виртуализация KubeVirt/Openshift (KubeVirt/Openshift Virtualization) для параметра Тип (Type).
Введите требуемые URL провайдера (Provider URL) и Токен (Token).
Дополнительно: Задайте значения таких Дополнительных параметров (Advanced parameters), как Центр сертификации (Certificate Authority), URL-адрес Prometheus и Центр сертификации Prometheus (Prometheus Certificate Authority).
Нажмите Тестировать (Test) для проверки подключения к новому провайдеру.
Нажмите OK для завершения добавления этого нового провайдера.

Действия по проверке:

На Портале администрирования нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя нового только что созданного кластера. Это имя кластера, например, kubevirt имеет в основе имя провайдера. Откроется подробное представление кластера.
Откройте вкладку Хосты (Hosts), чтобы убедиться, что рабочие узлы OpenShift Container Platform имеют статус Включен (up) . NOTE: Статус узлов панели управления будет Выключен (down), даже если они работают, так как они не могут разместить виртуальные машины.
Выберите Ресурсы (Compute) Виртуальные машины (Virtual Machines), чтобы развернуть виртуальную машину в новом кластере.
На веб-консоли OpenShift Container Platform, в представлении Администратор (Administrator) выберите Процессы (Workloads) → Виртуальные машины (Virtual Machines) для просмотра развернутой виртуальной машины.
Дополнительные ресурсы
Описание общих настроек при добавлении провайдера

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

Добавьте экземпляр VMware vCenter, чтобы импортировать виртуальные машины из VMware в Менеджер управления.

zVirt использует V2V, чтобы перед импортированием преобразовать виртуальные машины VMware в корректный формат. Пакет virt-v2v должен быть установлен хотя бы на одном хосте. Пакет virt-v2v доступен по умолчанию на хостах с zVirt Node и устанавливается на хостах как VDSM-зависимость при добавлении в среду zVirt.

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

Нажмите Управление (Administration) Провайдеры (Providers).
Нажмите Добавить (Add).
Введите Имя (Name) и Описание (Description).
Выберите VMware в выпадающем списке Тип (Type).
Выберите Центр данных (Data Center), в который будут импортироваться виртуальные машины VMware, либо Любой центр данных (Any Data Center), чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта.
Введите IP-адрес или FQDN экземпляра VMware vCenter в поле vCenter.
Введите IP-адрес или FQDN хоста, из которого будут импортироваться виртуальные машины, в поле ESXi.
Введите имя центра данных, в котором находится указанный хост ESXi, в поле Центр данных (Data Center).
Если вы обменивались SSL-сертификатом между хостом ESXi и Менеджером управления, то оставьте флажок Проверка SSL-сертификата сервера (Verify server’s SSL certificate) установленным, чтобы проверять сертификат хоста ESXi. В противном случае снимите этот флажок.
Выберите хост в выбранном центре данных с установленным пакетом virt-v2v, который будет служить Прокси-хостом (Proxy Host) во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера VMware vCenter. Если выше вы выбрали Любой центр данных (Any Data Center), то вы не можете выбирать здесь хост, но зато можете указывать хост для конкретной операции импорта.
Введите Имя пользователя (Username) и Пароль (Password) для экземпляра VMware vCenter. Пользователь должен иметь доступ к центру данных VMware и хосту ESXi, на котором находятся виртуальные машины.
Проверьте учетные данные:
1. Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на экземпляре VMware vCenter с использованием предоставленных учетных данных.
2. Если экземпляр VMware vCenter использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром VMware vCenter, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

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

2.9.2.4. Добавление хоста KVM в качестве провайдера виртуальных машин

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

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

Включите аутентификацию с открытым ключом между прокси-хостом и хостом KVM:
1. Авторизуйтесь на прокси-хосте и сгенерируйте SSH-ключи для пользователя vdsm.
  # sudo -u vdsm ssh-keygen
2. Скопируйте открытый ключ пользователя vdsm на хост KVM. Файл known_hosts на прокси-хосте также обновится и включит в себя хост-ключ хоста KVM.
  # sudo -u vdsm ssh-copy-id root@_kvmhost.example.com_
3. Авторизуйтесь на хосте KVM, чтобы убедиться, что все работает правильно.
  # sudo -u vdsm ssh root@_kvmhost.example.com_
Нажмите Управление (Administration) Провайдеры (Providers).
Нажмите Добавить (Add).
Введите Имя (Name) и Описание (Description).
Выберите KVM в выпадающем списке Тип (Type).
Выберите Центр данных (Data Center), в который будут импортироваться виртуальные машины KVM, либо Любой центр данных (Any Data Center), чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта.
В поле URI укажите URI хоста KVM. Например:
```
qemu+ssh://root@host.example.com/system
```
Выберите хост в выбранном центре данных, который будет служить Прокси-хостом (Proxy Host) во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера KVM. Если выше вы выбрали Любой центр данных (Any Data Center) в поле Центр данных (Data Center), то вы не сможете выбрать хост здесь. Это поле неактивно, и в нем отображается Любой хост в центре данных (Any Host in Data Center). Вместо этого вы можете указать хост во время отдельных операций импорта.
При желании установите флажок Требуется авторизация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для хоста KVM. Пользователь должен иметь доступ к хосту KVM, на котором находятся виртуальные машины.
Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на хосте KVM с использованием предоставленных учетных данных.
Нажмите OK.

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

2.9.2.5. Добавление Open Virtual Network (OVN) в качестве внешнего провайдера сети

Вы можете использовать Open Virtual Network (OVN) для создания оверлейных виртуальных сетей, которые обеспечивают связь между виртуальными машинами без добавления VLAN или изменения инфраструктуры. OVN – это расширение Open vSwitch (OVS), которое обеспечивает встроенную поддержку виртуальных оверлейных сетей L2 и L3.

Вы можете установить новый провайдер сети OVN или добавить существующий.

Вы также можете подключить сеть OVN к собственной сети zVirt. Дополнительную информацию см. в разделе Подключение сети OVN к физической сети.

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

ovirt-provider-ovn предоставляет REST API для работы в сети OpenStack. Его можно использовать для создания сетей, подсетей, портов и маршрутизаторов. Подробности см. в документе OpenStack Networking API v2.0.

2.9.2.6. Установка нового провайдера сети OVN

Если пакет openvswitch уже установлен и имеет версию 1:2.6.1 (версия 2.6.1, эпоха 1), то установка OVN завершится ошибкой при попытке установить новейший пакет openvswitch.

При установке OVN с использованием engine-setup выполняются следующие шаги:

Установка центрального сервера OVN на машину с Менеджером управления.
Добавление OVN к zVirt в качестве внешнего провайдера сети.
Установка Провайдер сети по умолчанию (Default Network Provider) в значение ovirt-provider-ovn (только в кластере по умолчанию).

Установка OVN меняет настройку Провайдер сети по умолчанию (Default Network Provider) только в кластере по умолчанию, но не в других кластерах.
Изменение настройки Провайдер сети по умолчанию (Default Network Provider) не обновляет хосты в этом кластере так, чтобы они использовали Провайдера сети по умолчанию (Default Network Provider).
Чтобы хосты и виртуальные машины смогли использовать OVN, выполните дополнительные действия, описанные в подразделе "Дальнейшие шаги" в конце этого раздела.

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

Дополнительно: Если вы используете заранее сконфигурированный файл ответов для engine-setup, добавьте следующую запись, чтобы установить OVN:
```
OVESETUP_OVN/ovirtProviderOvn=bool:True
```
Запустите engine-setup на машине с Менеджером управления.

Если вы не используете заранее сконфигурированный файл ответов, ответьте Yes, когда engine-setup спросит:

Configuring ovirt-provider-ovn also sets the Default cluster's default network provider to ovirt-provider-ovn.
Non-Default clusters may be configured with an OVN after installation. Configure ovirt-provider-ovn (Yes, No) [Yes]

Ответьте на следующий вопрос:
Use default credentials (admin@internal) for ovirt-provider-ovn (Yes, No) [Yes]?:
Если Yes, то engine-setup использует имя и пароль пользователя engine, указанные ранее в процессе настройки в качестве значений по умолчанию. Эта опция доступна только во время новой установки.
oVirt OVN provider user[admin]: oVirt OVN provider password[empty]:

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

Чтобы изменить метод аутентификации позже, можно внести правки в файл /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf или создать новый файл /etc/ovirt-provider-ovn/conf.d/20_engine_setup.conf. Перезапустите службу ovirt-provider-ovn, чтобы изменение вступило в силу. Подробности об аутентификации OVN см. по ссылке.

Дальнейшие действия:

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

Добавьте сеть в кластер Default.
1. Для этого установите флажок Создать на внешнем провайдере (Create on external provider). Будет создана сеть на базе ovirt-provider-ovn.
2. Дополнительно: Чтобы подключить сеть OVN к физической сети, установите флажок Подключение к физической сети (Connect to physical network) и укажите сеть zVirt, которую нужно использовать.
3. Дополнительно: Если сеть должна использовать группы безопасности, убедитесь, что в выпадающем списке Безопасность сетевого порта (Network Port Security) установлено значение Включен (Enabled). Дополнительную информацию о доступных опциях см. в разделе Описание общих настроек логической сети.
Добавьте хосты к кластеру Default или переустановите хосты на нем, чтобы они использовали нового Провайдера сети по умолчанию (Default Network Provider) кластера – ovirt-provider-ovn.
Дополнительно: Измените кластеры, не являющиеся кластерами по умолчанию, и установите параметр Провайдер сети по умолчанию (Default Network Provider) в значение ovirt-provider-ovn.
1. Дополнительно: Переустановите хосты на каждом кластере, не являющемся кластером по умолчанию, чтобы они использовали нового Провайдера сети по умолчанию (Default Network Provider) кластера – ovirt-provider-ovn.

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

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

2.9.2.7. Добавление существующего провайдера сети OVN

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

Установите провайдер OVN, прокси, используемый Менеджером управления для взаимодействия с OVN. Провайдер OVN можно установить на любой машине, но он должен иметь возможность связываться с центральным сервером OVN и Менеджером управления.
Добавьте провайдера OVN в zVirt в качестве внешнего провайдера сети.
Создайте новый кластер, использующий OVN в качестве провайдера сети по умолчанию. Хосты, добавленные в этот кластер, автоматически настраиваются на связь с OVN.

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

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

openvswitch-ovn-central
openvswitch
openvswitch-ovn-common
python-openvswitch

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

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

Установите и настройте провайдер OVN.
1. Установите провайдер на машине провайдера:
  # dnf install ovirt-provider-ovn
2. Если вы не устанавливаете провайдер на одну машину с Менеджером управления, то добавьте следующую запись в файл /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует):
  [OVIRT] ovirt-host=https://__Manager_host_name__
  
  Это нужно для аутентификации, если она включена.
3. Если вы не устанавливаете провайдер на одну машину с центральным сервером OVN, то добавьте следующую запись в файл /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует):
  [OVN REMOTE] ovn-remote=tcp:__OVN_central_server_IP__:6641
4. Откройте порты 9696, 6641 и 6642 в межсетевом экране, чтобы разрешить взаимодействие между провайдером OVN, центральным сервером OVN и Менеджером управления. Это можно сделать либо вручную, либо добавив службы ovirt-provider-ovn и ovirt-provider-ovn-central в соответствующую зону:
  # firewall-cmd --zone=_ZoneName_ --add-service=ovirt-provider-ovn --permanent # firewall-cmd --zone=_ZoneName_ --add-service=ovirt-provider-ovn-central --permanent # firewall-cmd --reload
5. Запустите и включите службу:
  # systemctl start ovirt-provider-ovn # systemctl enable ovirt-provider-ovn
6. Настройте центральный сервер OVN на прослушивание запросов с портов 6642 и 6641:
  # ovn-sbctl set-connection ptcp:6642 # ovn-nbctl set-connection ptcp:6641
На Портале администрирования нажмите Управление (Administration) Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробные сведения на вкладке Общее (General Settings). Дополнительную информацию об этих полях см. в разделеОписание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
В списке Тип (Type) выберите Внешний провайдер сети (External Network Provider).
Нажмите на текстовое поле Сетевой модуль (Networking Plugin) и выберите Провайдер сети oVirt для OVN (oVirt Network Provider for OVN) в выпадающем меню.

Автоматическая синхронизация включена по умолчанию на провайдере сети ovirt-provider-ovn, созданном инструментом engine-setup.

Введите URL-адрес или FQDN провайдера OVN в текстовое поле URL провайдера (Provider URL) и далее номер порта. Если провайдер OVN и центральный сервер OVN находятся на разных машинах, то это URL-адрес машины провайдера, а не центрального сервера. Если провайдер OVN находится на той же машине, что и Менеджер управления, можно оставить URL-адрес, заданный по умолчанию: http://localhost:9696.
Снимите флажок Только для чтения (Read-Only), чтобы разрешить создание новых сетей OVN из Менеджера управления.
При желании установите флажок Требуется авторизация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для пользователя внешнего провайдера сети, зарегистрированного в Keystone. Необходимо также указать аутентификационный URL-адрес сервера Keystone, задав Протокол (Protocol), Имя хоста (Hostname) и Порт API (API Port).

Метод аутентификации должен быть настроен в файле /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует). Перезапустите службу ovirt-provider-ovn, чтобы изменение вступило в силу. Подробности об аутентификации OVN см. по ссылке.
Проверьте учетные данные:
1. Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию в OVN с использованием предоставленных учетных данных.
2. Если экземпляр OVN использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром OVN, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.
Создайте новый кластер, использующий OVN в качестве провайдера сети по умолчанию. См. раздел Создание нового кластера и выберите провайдера сети OVN в выпадающем списке Провайдер сети по умолчанию (Default Network Provider).
Добавьте хосты к кластеру. Хосты, добавленные в этот кластер, автоматически настраиваются на связь с OVN. Чтобы добавить новые хосты, см. раздел Добавление стандартных хостов в Менеджер управления.
Импортируйте или добавьте сети OVN к новому кластеру. Чтобы импортировать сети, см. раздел Импортирование сетей из внешних провайдеров. Чтобы создать новые сети с использованием OVN, см. раздел Создание новой логической сети в центре данных или кластере и установите флажок Создать на внешнем провайдере (Create on external provider). По умолчанию выбрано значение ovirt-provider-ovn.

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

Чтобы подключить сеть OVN к собственной сети zVirt, установите флажок Подключить к физической сети (Connect to physical network) и укажите сеть zVirt, которую нужно использовать. Дополнительную информацию и предварительные требования см. в разделе Подключение сети OVN к физической сети.

Теперь можно создавать виртуальные машины, использующие сети OVN.

2.9.2.8. Использование Ansible-плейбука для изменения сети туннелей OVN

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

Использование Ansible-плейбука для модификации сети туннелей OVN

# ansible-playbook \
    --key-file <path_to_key_file> \
    -i <path_to_inventory> \
    --extra-vars "cluster_name=<cluster_name> ovn_central=<ovn_central_ip_address> ovirt_network=<ovirt network name> ovn_tunneling_interface=<vdsm_network_name>" \
    ovirt-provider-ovn-driver.yml

Параметры

key-file - Файл ключа для авторизации на хосте. Файл ключа по умолчанию обычно находится в каталоге /etc/pki/ovirt-engine/keys.
inventory - Список виртуальных машин oVirt. Чтобы определить значение списка, используйте данный скрипт: /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory.
cluster_name - Имя кластера, на которое нужно заменить имя
ovn_central - IP-адрес центрального сервера OVN. Этот IP-адрес должен быть доступен для всех хостов.
ovirt_network - Имя сети oVirt.
ovn_tunneling_interface - Имя сети VDSM.

Ansible-плейбук ovirt-provider-ovn-driver поддерживает использование либо параметра ovirt_network, либо параметра ovn_tunneling_interface. Если в одном плейбуке присутствуют оба параметра, то этот плейбук не работает.

Пример 26. Плейбук с параметром ovirt_network

# ansible-playbook \
  --key-file /etc/pki/ovirt-engine/keys/engine_id_rsa \
  -i /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory \
  --extra-vars " cluster_name=test-cluster ovn_central=192.168.200.2 ovirt_network="Long_Network_Name_with_Ascii_character"" \
  ovirt-provider-ovn-driver.yml

Пример 27. Плейбук с параметром ovn_tunneling_interface

# ansible-playbook \
  --key-file /etc/pki/ovirt-engine/keys/engine_id_rsa \
  -i /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory \
  --extra-vars " cluster_name=test-cluster ovn_central=192.168.200.2 ovn_tunneling_interface=on703ea21ddbc34" \
  ovirt-provider-ovn-driver.yml

На машине с Менеджером управления перейдите в каталог /usr/share/ovirt-engine/playbooks, чтобы запускать Ansible-плейбуки.

2.9.2.9. Настройка хостов для сети туннелей OVN

Можно настроить свои хосты на использование существующей сети, отличной от сети по умолчанию ovirtmgmt, с помощью Ansible-плейбука ovirt-provider-ovn-driver. Сеть должна быть доступна для всех хостов в кластере.

Ansible-плейбук ovirt-provider-ovn-driver обновляет существующие хосты. При добавлении новых хостов в кластер необходимо снова запустить плейбук.

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

На машине с Менеджером управления перейдите в каталог playbooks:
```
# cd /usr/share/ovirt-engine/playbooks
```

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

# ansible-playbook \
    --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa \
    -i /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory \
    --extra-vars " cluster_name=Cluster_Name ovn_central=OVN_Central_IP ovn_tunneling_interface=VDSM_Network_Name" \
    ovirt-provider-ovn-driver.yml

Пример 28. Настройка хоста для сети туннелей OVN

# ansible-playbook \
 --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa \
 -i /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory \
 --extra-vars " cluster_name=MyCluster ovn_central=192.168.0.1 ovn_tunneling_interface=MyNetwork" \
 ovirt-provider-ovn-driver.yml

OVN_Central_IP может находиться в новой сети, но это не обязательно. OVN_Central_IP должен быть доступен для всех хостов.

Длина VDSM_Network_Name ограничена 15 знаками. Если вы задали имя логической сети, длина которого превышает 15 знаков или содержит знаки, отличные от ASCII, то будет автоматически создано 15-значное имя. Указания по визуализации сопоставления этих имен см. в разделе Инструмент сопоставления VDSM с именем сети.

Обновление сети туннелей OVN на одном хосте

Обновить сеть туннелей OVN на одном хосте можно с помощью vdsm-tool:

# vdsm-tool ovn-config _OVN_Central_IP_ _Tunneling_IP_or_Network_Name_

Пример 29. Обновление хоста с помощью vdsm-tool

# vdsm-tool ovn-config 192.168.0.1 MyNetwork

2.9.2.10. Подключение сети OVN к физической сети

Данная возможность зависит от поддержки Open vSwitch, которая в zVirt доступна только как предварительная версия технологии, представленная для оценки (Technology Preview). Такие версии не поддерживаются соглашениями об уровне обслуживания (SLA) продуктивной среды и могут быть функционально неполными, и не рекомендуется использовать их в продуктивной среде. Тем не менее они дают возможность раннего доступа к будущим функциям продукта, позволяя заказчикам тестировать функциональность и оставлять отзывы в процессе разработки.

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

Если вы создали подсеть для сети OVN, то виртуальная машина, использующая эту сеть, получит IP-адрес оттуда. Если нужно, чтобы IP-адрес выделяла физическая сеть, не создавайте подсеть для сети OVN.

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

В качестве Типа коммутатора (Switch Type) в кластере должно быть выбрано Open vSwitch. Хосты, добавляемые в этот кластер, не должны иметь уже настроенных сетей zVirt, таких как мост (bridge) ovirtmgmt.
На хостах должна быть доступна физическая сеть. Это можно обеспечить, настроив физическую сеть в соответствии с требованиями кластера (в окне Управление сетями (Manage Networks) или на вкладке Кластер (Cluster) окна Новая логическая сеть (New Logical Network)).

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

Нажмите Ресурсы (Compute) Кластеры (Clusters).
Нажмите на имя кластера, Откроется подробное представление.
Откройте вкладку Логические сети (Logical Networks) и нажмите Добавить сеть (Add Network).
Введите Имя (Name) для сети.
Установите флажок Создать на внешнем провайдере (Create on external provider). По умолчанию выбрано ovirt-provider-ovn.
Установите флажок Подключение к физической сети (Connect to physical network), если он не установлен по умолчанию.
Выберите физическую сеть, к которой будет подключаться новая сеть:
- Нажмите кнопку-переключатель Сеть центра данных (Data Center Network) и выберите физическую сеть в выпадающем списке. Это – рекомендуемый параметр.
- Нажмите кнопку-переключатель Пользовательские (Custom) и введите имя физической сети. Если в физической сети включено тегирование VLAN, то необходимо также установить флажок Включить тегирование VLAN (Enable VLAN tagging) и ввести VLAN-тег физической сети.
Имя физической сети не должно быть длиннее 15 знаков и не должно содержать специальных знаков.
Нажмите OK.

2.9.2.11. Добавление внешнего провайдера сети

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

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

Нажмите Управление (Administration) Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробные сведения на вкладке Общее (General Settings). Дополнительную информацию об этих полях см. в разделе Описание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
Выберите Внешнего провайдера сети (External Network Provider) в выпадающем списке Тип (Type).
При желании нажмите на текстовое поле Сетевой модуль (Networking Plugin) и выберите соответствующий драйвер в выпадающем меню.

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

Введите URL-адрес или FQDN машины с установленным внешним провайдером сети в текстовое поле URL провайдера (Provider URL) и далее номер порта. По умолчанию установлен флажок Только для чтения (Read-Only). Это не позволит пользователям внести изменения в провайдер внешней сети.
При желании установите флажок Требуется авторизация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для пользователя внешнего провайдера сети, зарегистрированного в Keystone. Необходимо также указать аутентификационный URL-адрес сервера Keystone, задав Протокол (Protocol), Имя хоста (Hostname) и Порт API (API Port).
Проверьте учетные данные:
1. Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на провайдере внешней сети с использованием предоставленных учетных данных.
2. Если провайдер внешней сети использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный внешним провайдером сети, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

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

2.9.2.12. Описание общих настроек при добавлении провайдера

На вкладке Общее (General) в окне Добавить провайдера (Add Provider) можно регистрировать основные сведения о внешнем провайдере.

Таблица 66. Добавление провайдера: общие настройки
Параметр	Пояснение
Имя (Name)	Имя, под которым провайдер представляется в Менеджере управления.
Описание (Description)	Удобочитаемое описание провайдера в виде неформатированного текста.
Тип (Type)	Тип внешнего провайдера. Изменение этой настройки изменяет поля, доступные для конфигурирования провайдера. Внешний провайдер сети (External Network Provider) Сетевой модуль (Networking Plugin): Определяет, какая реализация драйвера будет использоваться на хосте для организации работы сетевой карты. Если внешний провайдер сети с плагином oVirt Network Provider for OVN добавляется в качестве провайдера сети по умолчанию для кластера, то этот параметр также определяет, какой драйвер будет устанавливаться на хостах, добавляемых к кластеру. Автоматическая синхронизация (Automatic Synchronization): Позволяет указать, будет ли провайдер автоматически синхронизироваться с существующими сетями. URL провайдера (Provider URL): URL-адрес или FQDN машины, на которой размещен внешний провайдер сети. В конец URL-адреса или FQDN необходимо добавить номер порта для внешнего провайдера сети. Номер порта по умолчанию – 9696. Только для чтения (Read Only): Позволяет указать, можно ли изменять внешний провайдер сети с Портала администрирования. Требуется авторизация (Requires Authentication): Позволяет указать, требуется ли аутентификация для доступа к внешнему провайдеру сети. Имя пользователя (Username): Имя пользователя для подключения к внешнему провайдеру сети. Если для аутентификации используется Active Directory, то имя пользователя должно иметь формат `имя_пользователя@домен@профиль_авторизации` вместо формата, используемого по умолчанию: `имя_пользователя@домен`. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. Протокол (Protocol): Протокол, используемый для взаимодействия с сервером Keystone. Значение по умолчанию – `HTTPS`. Имя хоста (Hostname): IP-адрес или имя хоста сервера Keystone. Порт API (API port): Номер порта API сервера Keystone. Версия API (API Version): Версия сервера Keystone. Значение равно v2.0, и это поле неактивно. Наименование арендатора (Tenant Name): Необязательно. Имя арендатора, членом которого является внешний провайдер сети. KubeVirt/OpenShift Virtualization URL провайдера (Provider URL): URL-адрес или FQDN и номер порта API-интерфейса контейнерной платформы OpenShift. Номер порта по умолчанию – 6443. Токен (Token): Токен доступа OAuth для аутентификации этого подключения к API-интерфейсу. Центр сертификации (Certificate Authority): Сертификат ЦС, которому следует доверять при выполнении https-запросов. URL-адрес Prometheus (Prometheus URL): URL-адрес службы prometheus кластера OpenShift. Если не указать этот URL-адрес, программа попытается автоматически определить его. Центр сертификации Prometheus (Prometheus Certificate Authority): Сертификат X509 для prometheus. Если не указать этот Центр сертификации, провайдер использует вместо него KubeVirt. OpenStack Image URL провайдера (Provider URL): URL-адрес или FQDN машины, на которой размещена служба OpenStack Image. В конец URL-адреса или FQDN необходимо добавить номер порта для службы OpenStack Image. Номер порта по умолчанию – 9292. Требуется аутентификация (Requires Authentication): Позволяет указать, требуется ли аутентификация для доступа к службе OpenStack Image. Имя пользователя (Username): Имя пользователя для подключения к серверу Keystone. Это имя пользователя должно представлять собой имя пользователя для службы OpenStack Image, зарегистрированное в экземпляре Keystone, членом которого является служба OpenStack Image. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. Этот пароль должен представлять собой пароль для службы OpenStack Image, зарегистрированный в экземпляре Keystone, членом которого является служба OpenStack Image. Протокол (Protocol): Протокол, используемый для взаимодействия с сервером Keystone. Необходимо задать значение HTTP. Имя хоста (Hostname): IP-адрес или имя хоста сервера Keystone. Порт API (API Port): Номер порта API сервера Keystone. Версия API (API Version): Версия службы Keystone. Значение равно v2.0, и это поле неактивно. Наименование арендатора (Tenant Name): Необязательно. Имя арендатора, членом которого является внешний провайдер сети. OpenStack Networking Сетевой модуль (Networking Plugin): Сетевой плагин для подключения к серверу OpenStack Networking. Для OpenStack Networking единственным параметром является Open vSwitch, и он выбран по умолчанию. Автоматическая синхронизация (Automatic Synchronization): Позволяет указать, будет ли провайдер автоматически синхронизироваться с существующими сетями. URL провайдера (Provider URL): URL-адрес или FQDN машины, на которой размещен экземпляр OpenStack Networking. В конец URL-адреса или FQDN необходимо добавить номер порта для экземпляра OpenStack Networking. Номер порта по умолчанию – 9696. Только для чтения (Read Only): Позволяет указать, можно ли изменять экземпляр OpenStack Networking с Портала администрирования. Требуется авторизация (Requires Authentication): Позволяет указать, требуется ли аутентификация для доступа к службе OpenStack Networking. Имя пользователя (Username): Имя пользователя для подключения к экземпляру OpenStack Networking. Это имя пользователя должно представлять собой имя пользователя для OpenStack Networking, зарегистрированное в экземпляре Keystone, членом которого является экземпляр OpenStack Networking. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. Этот пароль должен представлять собой пароль для OpenStack Networking, зарегистрированный в экземпляре Keystone, членом которого является экземпляр OpenStack Networking. Протокол (Protocol): Протокол, используемый для взаимодействия с сервером Keystone. Значение по умолчанию – `HTTPS`. Имя хоста (Hostname): IP-адрес или имя хоста сервера Keystone. Порт API (API Port): Номер порта API сервера Keystone. Версия API (API Version): Версия сервера Keystone. Она отображается в URL-адресе. Если отобразится v2.0, выберите `v2.0`. Если отобразится `v3`, выберите `v3`. Если в поле Версия API (API Version) выбрать `v3`, появляются следующие поля Имя доменного пользователя (User Domain Name): Имя пользователя, определенного в домене. При использовании версии v3 API-интерфейса Keystone домены используются для определения административных границ служебных объектов в OpenStack. Домены позволяют объединять пользователей в группы для различных целей, например для настройки конфигурации конкретного домена или параметров безопасности. Имя проекта (Project Name): Определяет имя проекта для версии v3 API-интерфейса службы OpenStack Identity. Доменное имя проекта (Project Domain Name): Определяет имя домена проекта для версии v3 API-интерфейса службы OpenStack Identity. Если в поле Версия API (API Version) выбрать `v2.0`, появляется следующее поле Наименование арендатора (Tenant Name): Появляется только, когда в поле Версия API (API Version) выбрано `v2.0`. Имя арендатора OpenStack, членом которого является экземпляр OpenStack Networking. OpenStack_Volume Центр данных (Data Center): Центр данных, к которому будут подключены тома хранилища OpenStack Volume. URL провайдера (Provider URL): URL-адрес или FQDN машины, на которой размещен экземпляр OpenStack Volume. В конец URL-адреса или FQDN необходимо добавить номер порта для экземпляра OpenStack Volume. Номер порта по умолчанию – 8776. Требуется авторизация (Requires Authentication): Позволяет указать, требуется ли аутентификация для доступа к службе OpenStack Volume. Имя пользователя (Username): Имя пользователя для подключения к серверу Keystone. Это имя пользователя должно представлять собой имя пользователя для OpenStack Volume, зарегистрированное в экземпляре Keystone, членом которого является экземпляр OpenStack Volume. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. Этот пароль должен представлять собой пароль для OpenStack Volume, зарегистрированный в экземпляре Keystone, членом которого является экземпляр OpenStack Volume. Протокол (Protocol): Протокол, используемый для взаимодействия с сервером Keystone. Необходимо задать значение HTTP. Имя хоста (Hostname): IP-адрес или имя хоста сервера Keystone. Порт API (API Port): Номер порта API сервера Keystone. Версия API (API Version): Версия сервера Keystone. Значение равно `v2.0`, и это поле неактивно. Наименование арендатора (Tenant Name): Имя арендатора OpenStack, членом которого является экземпляр OpenStack Volume. VMware Центр данных (Data Center): Укажите Центр данных (Data Center), в который будут импортироваться виртуальные машины VMware, либо выберите `Любой центр данных (Any Data Center)`, чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines)). vCenter: IP-адрес или FQDN экземпляра VMware vCenter. ESXi: IP-адрес или FQDN хоста, из которого будут импортироваться виртуальные машины. Центр данных (Data Center): Имя центра данных, в котором находится указанный хост ESXi. Кластер (Cluster): Имя кластера, в котором находится указанный хост ESXi. Проверять SSL-сертификат сервера (Verify server’s SSL certificate): Укажите, будет ли сертификат хоста ESXi проверяться при подключении. Хост прокси (Proxy Host): Выберите хост в выбранном центре данных с установленным пакетом virt-v2v, который будет служить хостом во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера VMware vCenter. Если вы выбрали `Любой центр данных (Any Data Center)`, то вы не сможете выбрать хост здесь, но сможете указывать хост во время конкретных операций импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines). Имя пользователя (Username): Имя пользователя для подключения к экземпляру VMware vCenter. Пользователь должен иметь доступ к центру данных VMware и хосту ESXi, на котором находятся виртуальные машины. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. KVM Центр данных (Data Center): Укажите центр данных, в который будут импортироваться виртуальные машины KVM, либо выберите `Любой центр данных (Any Data Center)`, чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines)). URI: URI хоста KVM. Хост прокси (Proxy Host): Выберите хост в выбранном центре данных, который будет служить хостом во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера KVM. Если вы выбрали `Любой центр данных (Any Data Center)`, то вы не сможете выбрать хост здесь, но зато сможете указывать хост во время конкретных операций импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines). Требуется авторизация (Requires Authentication): Позволяет указать, требуется ли аутентификация для доступа к хосту KVM. Имя пользователя (Username): Имя пользователя для подключения к хосту KVM. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем.
Тестирование (Test)	Позволяет пользователям проверить указанные учетные данные. Эта кнопка доступна для провайдеров всех типов.

2.9.3. Изменение внешнего провайдера

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

Нажмите Управление (Administration) Провайдеры (Providers) и выберите внешнего провайдера, который нужно изменить.
Нажмите Изменить (Edit).
Измените текущие значения параметров провайдера на желаемые.
Нажмите OK.

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

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

Нажмите Управление (Administration) Провайдеры (Providers) и выберите внешнего провайдера, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подключитесь к одному из узлов с ролью hosted engine :
```
$ ssh root@__host_address__
```
Переведите hosted engine в глобальный режим обслуживания:
```
# hosted-engine --set-maintenance --mode=global
```
Проверьте, имеется ли уже запущенный экземпляр виртуальной машины с Менеджером управления:
# hosted-engine --vm-status
Если экземпляр виртуальной машины с Менеджером управления уже работает, подключитесь к его хосту:
# ssh root@__host_address__
Выключите виртуальную машину:
# hosted-engine --vm-shutdown
Если виртуальная машина не выключается, выполните следующую команду:

# hosted-engine --vm-poweroff
Запустите виртуальную машину с Менеджером управления в режиме паузы:
```
#hosted-engine --vm-start-paused
```
Задайте временный пароль VNC:
#hosted-engine --add-console-password
Эта команда выводит информацию, необходимую для авторизации на виртуальной машине с Менеджером управления с помощью VNC.
Авторизуйтесь на виртуальной машине с Менеджером управления с помощью VNC. Виртуальная машина с Менеджером управления по-прежнему в режиме паузы, поэтому кажется, что она зависла.

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

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

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

Загрузите виртуальную машину с Менеджером управления в режиме восстановления.
Отключите глобальный режим обслуживания
```
# hosted-engine --set-maintenance --mode=none
```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# engine-backup --mode=backup

# engine-backup --mode=restore

# engine-backup --mode=verify

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ INFO  ] skipping: [localhost]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ INFO  ] skipping: [localhost]

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

В пункте, где необходимо указать путь к архиву с OVA файлом, оставьте рекомендуемое значение по умолчанию.
Введите пароль root для менеджера управления.
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя root, и укажите, следует ли разрешить доступ SSH для пользователя root.
Введите количество vCPU и объем ОЗУ.
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
Выберите способ получения IP-адреса: DHCP или Static. Если вы укажете Static , введите IP-адрес менеджера.
Укажите, следует ли добавлять записи для менеджера управления в /etc/hosts.
Укажите данные для отправки уведомлений по электронной почте.
Введите пароль для пользователя admin@internal.
Если на шаге Pause after adding the host? был выбран вариант ответа Yes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке. В примере это адрес https://host2.example.com:6900/ovirt-engine/ к которому можно подключиться и произвести необходимые настройки, например: добавить обязательные сети VLAN, запустить домены хранения.
[ INFO ] You can now connect to https://host2.example.com:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up' [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost -> localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]
После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера.
Выберите тип используемого хранилища и укажите данные для подключения.
Выберите размер диска менеджера управления.
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

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

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

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

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH на новый хост. Проверьте командой dnf update, что репозиторий zVirt включен и доступен.
Выполните установку пакета ovirt-engine-appliance из репозитория:
```
dnf install -y ovirt-engine-appliance
```
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и начните процедуру развертывания:
```
hosted-engine --deploy --restore-from-file=backup.bck
```
На вопрос об имени центра данных необходимо ввести новое (ранее не использовавшееся) имя центра данных.
```
--== VM CONFIGURATION ==--
Please enter the name of the datacenter where you want to deploy this hosted-engine host. [Default]:
```
На вопрос об имени кластера необходимо ввести новое (ранее не использовавшееся) имя кластера.
```
Please enter the name of the cluster where you want to deploy this hosted-engine host. [Default]:
```

На вопрос о паузе после добавления хоста необходимо выбрать Yes.

[ INFO  ] skipping: [localhost]
        Pause the execution after adding this host to the engine?
        You will be able to connect to the restored engine in order to manually review and remediate its configuration.
        This is normally not required when restoring an up to date and coherent backup.
        Pause after adding the host? (Yes, No)[No]:  Yes

На вопрос … reinstalled from the engine to update their hosted-engine configuration необходимо выбрать Yes.

[ INFO  ] Stage: Environment setup
        During customization use CTRL-D to abort.
        Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine.
        The provided engine backup file will be restored there,
        it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored.
        If a reference to this host is already contained in the backup file, it will be filtered out at restore time.
        The locally running engine will be used to configure a new storage domain and create a VM there.
        At the end the disk of the local VM will be moved to the shared storage.
        The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it.
        Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration.
        Are you sure you want to continue? (Yes, No)[Yes]: Yes;

Настройте сеть. Сценарий определит возможные сетевые адаптеры для использования, выберите необходимый.

На вопрос о перевыпуске сертификат необходимо ответить Yes

[ INFO  ] skipping: [localhost]

        Renew engine CA on restore if needed?
        Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine.
        Renew CA if needed? (Yes, No)[No]: Yes;

В пункте, где необходимо указать путь к архиву с OVA файлом, оставьте рекомендуемое значение по умолчанию.
Введите пароль root для менеджера управления.
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя root, и укажите, следует ли разрешить доступ SSH для пользователя root.
Введите количество vCPU и объем ОЗУ.
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
Выберите способ получения IP-адреса: DHCP или Static. Если вы укажете Static, введите IP-адрес менеджера.
Укажите, следует ли добавлять записи для менеджера управления в /etc/hosts.
Укажите данные для отправки уведомлений по электронной почте.
Введите пароль для пользователя admin@internal.

Если на шаге Pause after adding the host? был выбран вариант ответа Yes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке.

[ INFO  ] You can now connect to https://host2.example.com:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost -> localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]

После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера.

Выберите тип используемого хранилища и укажите его данные.
Выберите размер диска менеджера управления.
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
В результате развёртывания:
- группа хостов (обозначена 1) находившаяся в кластере Default и центре данных Default, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домен хранения вышел из строя);
- группа хостов (обозначена 2) находившаяся в кластере NewCluster2 и центре данных DataCenter2, может быть доступна / недоступна в зависимости от домен хранения;
- группа хостов (обозначена 3) находившаяся во вновь созданном кластере MyCluster2022 и центре данных MyDataCenter2022, будет доступна;
В результате развёртывания, домены хранения:
- группа доменов хранения (обозначена 1) находившаяся в кластере Default и центре данных Default, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домены хранения вышли из строя). Удалить данные домены хранения нельзя, т.к. недоступен хост SPM, выполнявший роль по управлению хранилищем;
- группа доменов хранения (обозначена 2) находившаяся в кластере NewCluster2 и центре данных DataCenter2, может быть доступна / недоступна в зависимости от домен хранения;
- группа доменов хранения (обозначена 3) находившаяся во вновь созданном кластере MyCluster2022 и центре данных MyDataCenter2022, будет доступна;

Восстановление работы менеджера управления из резервной копии до предыдущего состояния.

Если менеджер управления доступен, но в нем возникла проблема, (например повреждение базы данных или ошибка конфигурации) можно восстановить менеджер управления в предыдущее состояние, используя резервную копию, сделанную до возникновения проблемы.

Перед развертыванием необходимо:

Соблюсти условия, описанные в инструкции.
Старое хранилище должно быть доступно (в случае недоступности хранилища будет ошибка Cannot access the Storage Domain attached to the DataCenter).
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;

Далее необходимо выполнить следующие шаги:

Подключитесь на любой из хостов, ранее находившихся в кластере (в данном кластере ранее был расположен менеджер управления). Если они доступны, командой hosted-engine --vm-status проверьте, на каком из хостов запущен менеджер управления.
Подключитесь по SSH к этому хосту.
Включите режим глобального обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Проверьте, что режим глобального обслуживания включен:
```
hosted-engine --vm-status
```
Подключитесь по SSH к менеджеру управления, остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```

В процессе выполнения скрипт предупредит, что будет остановлена служба engine. Необходимо подтвердить операцию:

[root@manager-drp ~]# engine-cleanup
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
        Configuration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf, /etc/ovirt-engine-setup.conf.d/10-packaging.conf, /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
        Log file: /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
        Version: otopi-1.9.6 (otopi-1.9.6-1.el8)
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment customization
[ INFO  ] Stage: Setup validation
        During execution engine service will be stopped (OK, Cancel) [OK]: OK

В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
        All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/filename.bak --restore-permissions
```

Выполните команду:

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

Запустить engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

Setup can automatically configure the firewall on this system.
Note: automatic configuration of the firewall may overwrite current settings.
Do you want Setup to configure the firewall? (Yes, No) [Yes]: Yes

В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:

    If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
    Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
    A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
    Are you sure you do not want to backup the DWH database?(Yes, No) [No]: No

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

В случае успешного выполнения необходимо запустить службу ovirt-engine и подключаться к менеджеру управления.

        Please run the following command on the engine machine manager.my.local, for SSO to work:
        systemctl restart ovirt-engine
[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20221222141208-co86sp.log
[ INFO  ] Generating answer file /var/lib/ovirt-engine/setup/answers/20221222141507-setup.conf
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of setup completed successfully

Ошибки при восстановлении

Ошибка "codec can’t decode byte 0xd0 in position 0:"

Во время восстановления может возникнуть ошибка:

ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Environment customization': 'utf-8' codec can't decode byte 0xd0 in position 0: invalid continuation byte

Решение: Был введён недопустимый символ. Из таблицы ASCII символ 0xd0 - Р (на кириллице). Необходимо вводить символы только на латинице.

Ошибка "Unable to stop service libvirtd"

Во время восстановления может возникнуть ошибка:

ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:110 fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to stop service libvirtd: Job for libvirtd.service canceled.\n"}

Решение: перед началом повторной инсталляции не была выполнена процедура очистки предыдущей установки. Необходимо выполнить команду ovirt-hosted-engine-cleanup, перезагрузить сервер и повторно запустить процедуру развёртывания.

Ошибка "Your system is configured to use a proxy, please add an exception"

Во время восстановления может возникнуть ошибка:

2022-12-01 12:17:41,122+0300 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:106
{'results': [{'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for http://name.domain.ru/ with no_proxy directive.\n',
'_ansible_no_log': False, 'changed': False, 'url': 'http://name.domain.ru/', 'ansible_loop_var': 'url', '_ansible_item_label':
'http://name.domain.ru/'}, {'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for
https://name.domain.ru/ with no_proxy directive.\n', '_ansible_no_log': False, 'changed': False, 'url': 'https://name.domain.ru/',
'ansible_loop_var': 'url', '_ansible_item_label': 'https://name.domain.ru/'}], 'msg': 'All items completed', 'changed': False}

Решение: эта ошибка возникает по причине того, что в процессе развертывания менеджер управления (который находится за NAT хоста), будет происходить обращение к прокси-серверу. В свою очередь у прокси-сервера не будет доступа до менеджера управления. Для устранения ошибки необходимо сделать исключение для менеджера. Перед развертыванием менеджера управления необходимо выполнить команду на хосте:

export no_proxy="FQDN-engine"

где FQDN-engine - полное доменное имя менеджера управления. Например mynewmanager.test.ru

Ошибка "Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service"

Во время восстановления может возникнуть ошибка:

Failed to restart abrtd.service: Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service. Probably contradicting requirement dependencies configured.
See system logs and 'systemctl status abrtd.service' for details.

Решение: необходимо остановить и запустить сервис:

systemctl stop abrtd.service
systemctl start abrtd.service

3.2.1.4. Резервное копирование в режиме Stand Alone

Исходные данные

Первый центр данных. Имя - Default.
- Хост с менеджером управления: manager.example.com.
- Имя кластера - Default. В кластере два хоста: host1.example.com и host2.example.com.
- Имя домена хранения - storage_iscsi. Тип iSCSI.
- Имя домена хранения - storage_nfs. Тип NFS.
- Два гипервизора с обязательными сетями VLAN 100, 101.
Второй центр данных. Имя - DataCenter2.
- Имя кластера - Cluster2. В кластере один хост: host3.example.com.
- Имя домена хранения - storage-nfs-datacenter2. Тип NFS.
- Гипервизор с обязательной сетью VLAN 102.

Адрес менеджера управления - https://manager.example.com/ovirt-engine/

Процедура резервного копирования

Рекомендуется регулярно выполнять процедуру резервного копирования базы данных менеджера управления. Данную процедура рекомендуется выполнять в нерабочее время.

Рекомендуемый способ резервного копирования

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine:
```
systemctl stop ovirt-engine.service
```
Создайте эталонную резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.

Выполните команду:

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Результат выполнения:

# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"
fn_db_delete_config_value
---------------------------
(1 row)

Создайте ещё одну резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Запустите сервис ovirt-engine:
```
systemctl start ovirt-engine.service
```

Процедура восстановления

Из резервной копии на вновь созданный (чистый хост)
Из резервной копии до предыдущего состояния

Требования для восстановления.

Для восстановления, необходимы соблюсти ряд условий:

Исходные домены хранения должны быть доступны.
Режим multipath должен быть настроен. Рекомендуемые настройки для multipath.
Произведена настройка фильтра LVM по инструкции.
Произведена настройка IP адресов, маски подсети, DNS.
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления

Восстановление работы менеджера управления из резервной копии на вновь созданный (чистый хост).

Подключитесь по SSH к хосту с установленным zVirt
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и и выполните обновление:
```
engine-backup --mode=restore --file=backup.bck --provision-all-databases
```
Выполните команду:
```
engine-setup --offline
```

В процессе развертывания будет задан ряд вопросов, отвечайте на них в соответствии с Вашими предпочтениями, но на вопросы указанные ниже необходимо ответить следующим образом:

Would you like to backup the existing database before upgrading it? (Yes, No) No
Are you sure you do not want to backup the DWH database? (Yes, No) Yes
One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details.
Renew certificates? (Yes, No) Yes

Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
```
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
```
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

Восстановление работы менеджера управления из резервной копии до предыдущего состояния.

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```
Выполните команду очистки БД менеджера управления:
```
engine-cleanup
```
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
        All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
        Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions
```

В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

Выполните команду:

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Запустить engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

        Setup can automatically configure the firewall on this system.
        Note: automatic configuration of the firewall may overwrite current settings.
        Do you want Setup to configure the firewall? (Yes, No) [Yes]:

В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:

        If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
        Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
        A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
        Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

В случае успешного выполнения необходимо перезапустить службу ovirt-engine и подключаться к менеджеру управления:
```
systemctl restart ovirt-engine.service
```

3.2.1.5. Резервное копирование в режиме Stand Alone All-in-One

Исходные данные

Первый центр данных. Имя - Default.
- Хост с менеджером управления: manager.example.com
- Имя кластера - Default. В кластере два хоста: host1.example.com и host2.example.com.
- Имя домена хранения - storage_iscsi. Тип iSCSI.
- Имя домена хранения - storage_nfs. Тип NFS.
- На двух хостах добавлены обязательные сети VLAN 100, 101.
Второй центр данных. Имя - DataCenter2.
- Имя кластера - Cluster2. В кластере один хост: host3.example.com.
- Имя домена хранения - storage-nfs-datacenter2. Тип NFS.
- На хост добавлена обязательная сеть VLAN 102.

Адрес менеджера управления - https://manager.example.com/ovirt-engine/

===== Процедура резервного копирования

Рекомендуется регулярно выполнять процедуру резервного копирования базы данных менеджера управления. Данная процедура должна выполняться в нерабочее время.

Рекомендуемый способ резервного копирования

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine:
```
systemctl stop ovirt-engine.service
```
Cоздайте эталонную резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.

Выполните команду:

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Корректный результат выполнения:

# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"
fn_db_delete_config_value
---------------------------
(1 row)

Создайте ещё одну резервную копию базы данных менеджера управления:
```
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
```
Сохраните полученные файлы в хранилище вне среды виртуализации.
Запустите сервис ovirt-engine:
```
systemctl start ovirt-engine.service
```

Процедура восстановления

Из резервной копии на вновь созданный (чистый хост).
Из резервной копии до предыдущего состояния.

Требования для восстановления.

Для восстановления, необходимы соблюсти ряд условий:

Исходные домены хранения должны быть доступны.
Режим multipath должен быть настроен. Рекомендуемые настройки для multipath.
Произведена настройка фильтра LVM по инструкции.
Произведена настройка IP адресов, маски подсети, DNS.
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления

Восстановление работы менеджера управления из резервной копии на вновь созданный (чистый хост)

Подключитесь по SSH к хосту с установленным zVirt
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
Перейдите в директорию с резервной копией и и выполните обновление:
```
engine-backup --mode=restore --file=backup.bck --provision-all-databases
```
Выполните команду:
```
engine-setup --offline
```

Would you like to backup the existing database before upgrading it? (Yes, No) - выбрать No
Are you sure you do not want to backup the DWH database? (Yes, No) - выбрать Yes
One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details.
Renew certificates? (Yes, No) - выбрать Yes

Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
```
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.*
```
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.

Для возвращения хоста с Менеджером управления в кластер, необходимо зайти в веб-интерфейс Менеджера управления и перейти ко вкладке Ресурсы Хосты и добавить новый хост. Предыдущий хост нужно удалить из кластера.

Восстановление работы менеджера управления из резервной копии до предыдущего состояния.

Далее необходимо выполнить следующие шаги:

Подключитесь по SSH к менеджеру управления.
Остановите сервис ovirt-engine и выполните команду очистки БД менеджера управления:
```
systemctl stop ovirt-engine.service
```
Выполните команду очистки БД менеджера управления:
```
engine-cleanup
```
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
```
[ INFO  ] Hosted Engine HA is in Global Maintenance mode.
    All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK
```

В случае успешного завершения операции сообщение будет следующим:

[ INFO  ] Stage: Clean up
    Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of cleanup completed successfully

Выполните команду для загрузки из резервной копии:
```
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions
```

В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:

Please note:
The engine database was backed up at 2022-12-12 15:28:42.
Objects that were added, removed or changed after this date, such as virtual
machines, disks, etc., are missing in the engine, and will probably require
recovery or recreation.
- DWH database ovirt_engine_history
- Grafana database /var/lib/grafana/grafana.db
You should now run engine-setup.
Done

Выполните команду:

sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"

Запустите engine-setup соответствующей командой.

В процессе развертывания, на вопрос о конфигурации firewall необходимо ответить Yes.

    Setup can automatically configure the firewall on this system.
    Note: automatic configuration of the firewall may overwrite current settings.
    Do you want Setup to configure the firewall? (Yes, No) [Yes]:

В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:

    If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
    Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No
[WARNING] Are you sure you do not want to backup the DWH database?
    A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state.
    Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes

В процессе развертывания, на два вопроса об операциях vacuum и full vacuum необходимо ответить No.

This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

--== OVIRT ENGINE CONFIGURATION ==--

Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/sql-vacuum.html
(Yes, No) [No]: No

В случае успешного выполнения необходимо перезапустить службу ovirt-engine и подключаться к менеджеру управления:
```
systemctl restart ovirt-engine.service
```

После восстановления, хост, на котором установлен Менеджер управления, будет в выключенном состоянии. Чтобы вернуть хост с Менеджером управления в кластер в качестве гипервизора, необходимо выполнить следующие шаги:

Перейди на вкладку Ресурсы Хосты в Менеджере управления.
Выберите хост, на котором развёрнут Менеджер управления и переведите его в режим обслуживания Управление → Обслуживание;
Переустановите хост, выбрав хост и нажав кнопку Настройки → Переустановить, в дополнительных параметрах ничего менять не нужно;
Дождитесь окончания процесса переустановки гипервизора;
По окончанию загрузки, Менеджер управления будет перезагружен и вновь добавлен в кластер в качестве хоста гипервизора.

3.2.1.6. Резервное копирование Менеджера управления через портал администрирования

Процедуры, описанные в этой инструкции актуальны для версии zVirt 3.2 и выше

В zVirt имеется возможность ручного резервного копирования менеджера управления через Портал администрирования, а также добавления расписания, в соответствии с которым создание резервных копий будет выполняться в автоматическом режиме.

Управление хранилищами резервных копий

На Портале администрирования есть возможность указания удаленного хранилища для сохранения файла резервной копии как в ручном режиме, так и при настройке заданий резервного копирования. Это позволяет сохранить файл резервной копии на хосте/ВМ, отличном от того, на котором расположен менеджер управления и даёт возможность воспользоваться файлом резервной копии, если хост/ВМ с менеджером управления вышли из строя.

Просмотр списка хранилищ резервных копий

Для просмотра и проверки конфигурации хранилищ резервных копий на Портале администрирования нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup), а затем перейдите на на вкладку Хранилища резервных копий (Backup storages).

Список хранилищ резервных копий представлен в виде таблицы, по умолчанию отображающей следующие сведения о хранилищах:

Хост (Host) - FQDN/IP-адрес хоста, на который отправляются файлы резервных копий
Порт (Port) - порт, используемый для передачи файлов резервных копий
Путь к резервной копии (Backup path) - абсолютный путь к каталогу на удалённой машине, в котором сохраняются файлы резервных копий
Пользователь (User) - имя учетной записи пользователя, от имени которого выполняется подключение к удалённой машине для передачи файлов резервных копий
Описание (Description) - описание хранилища

Для быстрого поиска нужного хранилища можно воспользоваться строкой поиска.

Поиск осуществляется по значениям во всех столбцах таблицы независимо от видимости столбцов.

При необходимости, видимость столбцов можно изменить в меню настройки settIcon .

Добавление хранилища резервных копий

Для добавления нового хранилища резервных копий, на Портале администрирования выполните следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Хранилища резервных копий (Backup storages)
Нажмите Добавить хранилище (Add Storage)

В появившемся окне "Добавление хранилища" ("Adding Storage") настройте следующие параметры:

В поле Хост (Host) введите FQDN или IP-адрес хоста, на который будут отправляться файлы резервных копий

В поле Порт (Port) укажите порт, который будет использоваться для передачи файлов резервных копий (по умолчанию - 22)

Передача файлов резервных копий осуществляется утилитой scp, поэтому используемый по умолчанию порт имеет значение 22. Если на удалённой машине изменён стандартный порт для доступа по SSH, в этом поле также необходимо установить соответствующее значение

В поле Путь к резервной копии (Backup path) укажите абсолютный путь к каталогу на удалённой машине, в котором необходимо сохранять файлы резервных копий
В поле Пользователь (User) введите имя учетной записи пользователя, от имени которого необходимо подключаться к удалённой машине для передачи файлов резервных копий (по умолчанию root)
В поле Пароль (Password) введите пароль учётной записи, указанной в поле Пользователь (User)
Дополнительно: в поле Описание (Description) введите описание хранилища

Нажмите Проверить соединение (Check the connection).

Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения

В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.
Нажмите Добавить хранилище (Add Storage)

После выполнения описанной процедуры, в списке хранилищ резервных копий появится новая запись.

Изменение хранилища резервных копий

Чтобы изменить настройки существующего хранилища резервных копий, выполните следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Хранилища резервных копий (Backup storages)
Выделите нужное хранилище и нажмите Редактировать (Edit)
Измените нужные настройки
Нажмите Проверить соединение (Check the connection).

Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения

В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.
Нажмите Редактировать хранилище (Edit Storage)

Если операция обновления прошла успешно, появится следующее уведомление:

Удаление хранилища резервных копий

Если некоторые из хранилищ резервных копий больше не требуются, то их можно удалить, выполнив следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Хранилища резервных копий (Backup storages)
Отметьте нужные хранилища галочками и нажмите Удалить (Delete)
Подтвердите операцию удаления в появившемся окне

Ручное резервное копирование менеджера управления

Пользователи, имеющие определённое разрешение (см. раздел Управление разрешением на резервное копирование менеджера управления), могут создать резервную копию выбранных компонентов менеджера управления через Портал администрирования.

Ручное создание резервной копии менеджера управления

Для запуска резервного копирования менеджера управления выполните следующие действия.

Если требуется хранение резервной копии на удалённом хранилище, перед выполнением процедуры убедитесь, что подключено хранилище резервных копий (См. раздел Управление хранилищами резервных копий)

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Убедитесь, что активна вкладка Ручное резервное копирование (Manual backup)
Настройте параметры резервного копирования (полное описание параметров см. в таблице Настройки на вкладке "Ручное резервное копирование" ("Manual backup"):
- В поле Расположение файла резервной копии (Backup file location) введите абсолютный путь к локальному каталогу, в котором будет храниться резервная копия
- В группе Состав компонентов (Composition of components) выберите компоненты менеджера управления, резервную копию которых необходимо сделать
- Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.
Нажмите Создать резервную копию (Create a backup)

После нажатия на Создать резервную копию (Create a backup) будет отображено уведомление о создании задачи резервного копирования.

Проконтролировать процесс создания резервной копии можно через раздел Задачи tasksIcon , а также в блоке уведомлений EventsIcon в подразделе События.

Пример 30. Отображение выполненной задачи резервного копирования в разделе "Задачи"

Пример 31. Отображение события в блоке уведомлений

Описание настроек ручного резервного копирования

В таблице ниже представлено общее описание параметров, доступных для настройки на вкладке Ручное резервное копирование (Manual backup)

Таблица 70. Настройки на вкладке "Ручное резервное копирование" ("Manual backup")
Параметр	Описание
Расположение файла резервной копии (Backup file location)	Локальное расположение файла резервной копии. По умолчанию /var/lib/zvirt-engine-backup/
Состав компонентов (Composition of components)	Соответствует параметру `--scope` в утилите `engine-backup`. Должен быть выбран хотя бы один из компонентов. Список доступных для выбора пунктов: Все компоненты (All components) - при выборе данного пункта должны отмечаться все указанные ниже компоненты. В утилите `engine-backup` соответствует значению параметра `--scope=all`* Файлы конфигурации (Configuration files) - в утилите `engine-backup` соответствует значению параметра `--scope=files` База данных менеджера управления (Manager’s database) в утилите `engine-backup` соответствует значению параметра `--scope=db` База данных DWH (DWH database) - в утилите `engine-backup` соответствует значению параметра `--scope=dwhdb` База данных Cinderlib (Cinderlib database) - в утилите `engine-backup` соответствует значению параметра `--scope=cinderlibdb` База данных Grafana (Grafana database) - в утилите `engine-backup` соответствует значению параметра `--scope=grafanadb` Дополнительную информацию об утилите `engine-backup` и её параметрах см. в разделе Резервное копирование и восстановление Менеджера управления руководства администратора
Хранилище (Storage)	Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально

Управление задачами резервного копирования менеджера управления по расписанию

Просмотр задач резервного копирования

На Портале администрирования есть возможность просмотра созданных задач резервного копирования по расписанию.

Для этого нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup) и перейдите на вкладку Расписание резервного копирования (Backup schedule).

Список задач резервного копирования представлен в виде таблицы, по умолчанию отображающей следующие сведения:

Расписание (Schedule) - выражение в формате quartz cron, определяющее расписание запуска задачи
Последний удачный запуск (Last successful Launch) - дата и время последней успешной попытки запуска задачи. Если в поле стоит -, значит удачной попытки запуска ещё не было.
Следующий запуск (Next launch) - дата и время следующего запуска задачи. Если в поле стоит -, запуск не запланирован
Расположение файла (File location) - абсолютный путь к локальному каталогу, в котором сохраняются файлы резервных копий
Хранилище (Storage) - используемое для задачи хранилище резервных копий
Описание (Description)

Видимость колонок таблицы можно изменить в меню настройки settIcon .

Каждая запись в таблице имеет переключатель switch , позволяющий активировать/деактивировать соответствующую задачу.

Добавление задачи резервного копирования по расписанию

Для создания новой задачи выполните следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
Нажмите Добавить задачу (Add a task).
В появившемся окне "Добавление задачи" ("Adding a task") настройте параметры задания резервного копирования (полное описание параметров см. в [Таблице 3.2. Настройки задания резервного копирования](#t3-2)).
- Убедитесь в том, что переключатель выполнения задачи по расписанию находится в состоянии Задача включена (The task includes)
- В поле Расположение файла резервной копии (Backup file location) укажите абсолютный путь к локальному расположению файла резервной копии
- В поле Расписание (Schedule) укажите расписание. Это можно сделать двумя способами:
  - Задать расписание вручную, введя выражение в формате Quartz cron (см. раздел Использование формата Quartz cron для задания расписания)
  - Использовать графический помощник, нажав на кнопку рядом с полем ввода
- Дополнительно: в поле Описание (Description) введите описание задачи
- В группе Состав компонентов (Composition of components) отметьте компоненты, резервное копирование которых должна выполнять задача
- Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.
Нажмите Добавить задачу (Add a task)

При успешном добавлении задачи отобразится уведомление.

Также в списке задач появится новая запись.

Пример 32. Отображение выполненной задачи резервного копирования в разделе "Задачи"

Пример 33. Отображение события в блоке уведомлений

В случае каких-либо проблем с выполнением задачи резервного копирования, сервисом совершается до двух дополнительных (через 30 минут после очередного неуспешного запуска) попыток выполнения задачи резервного копирования. Если следующий момент (по расписанию) наступает раньше запланированного времени повторной попытки, то повторные попытки прекращаются.

Изменение задачи резервного копирования по расписанию

При необходимости, можно изменить параметры существующей задачи. Для этого выполните следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
Выделите нужную задачу и нажмите Редактировать (Edit)
Измените нужные настройки
Нажмите Сохранить задачу (Save the task)

Если операция обновления прошла успешно, появится следующее уведомление:

В списке задач также отобразятся обновлённые сведения о задаче.

Удаление задач резервного копирования по расписанию

Если некоторые из задач больше не требуются, то их можно удалить, выполнив следующие действия.

Порядок действий:

Нажмите Управление (Administration) Резервное копирование конфигурации (Configuration backup)
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
Отметьте нужные задачи галочками и нажмите Удалить (Delete)
Подтвердите операцию удаления в появившемся окне

После подтверждения операции удаления отобразится уведомление

Отправка результатов операции резервного копирования менеджера управления по расписанию на email

zVirt предоставляет возможность получать информацию о результатах операции резервного копирования, запущенного по расписанию, на указанный в настройках пользователя email-адрес, чтобы не приходилось каждый раз самостоятельно проверять результаты операции вручную.

Операция резервного копирования в общем случае имеет четыре этапа:

Начало операции резервного копирования
Завершение (успешное или неуспешное) операции резервного копирования
Начало переноса файла резервной копии на целевое хранилище
Завершение (успешное или неуспешное) переноса файла резервной копии на целевое хранилище

Для активации отправки оповещений о резервном копировании и переносе файла копии на email-адрес соответствующего пользователя выполните следующие действия.

Для получения уведомлений по электронной почте, убедитесь что почтовый сервер настроен и запущена служба ovirt-engine-notifier (подробнее о настройке уведомлений см. в разделе Уведомления о событиях руководства администратора)

Порядок действий:

Нажмите Управление (Administration) Пользователи (Users)
Нажмите на имя нужного пользователя. Откроется подробное представления
Перейдите на вкладку Уведомления о событиях (Event Notifier)
Нажмите Управлять событиями (Manage Events)
Разверните () раздел Общие события управления (General Management Events) и отметьте галочками нужные события, относящиеся к резервному копированию менеджера управления:
Проверьте корректность почтового адреса получателя в поле Получатель почты (Mail Recipient)
Нажмите OK

Так же в конфигурационном файле сервиса ovirt-engine-notifier (/usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf) есть три параметра, управляющих локализацией и объединением нотификационных email (см. таблицу ниже).

Таблица 71. Параметры локализации и объединения нотификационных email
Параметр	Значение по умолчанию	Описание
`MAIL_MERGE_LOG_TYPES`	-	Содержит в себе список типов уведомлений, для которых нужно объединять email, например: `MAIL_MERGE_LOG_TYPES=ENGINE_BACKUP_STARTED,ENGINE_BACKUP_COMPLETED,ENGINE_BACKUP_FAILED` Если данный параметр не задан - объединения email происходить не будет. В этом случае, если, например, запустить операцию резервного копирования с указанием `scope=all`, система сгенерирует 5 email оповещений (на каждый элемент из `scope` в отдельности) о начале резервного копирования, а потом еще 5 email о завершении (успешном или неуспешном) резервного копирования. Если в данном параметре указать типы уведомлений, как в примере выше, то каждая пятерка таких email будет объединена в один. Таким образом, получатели оповещений получат не 10 писем, а всего 2 (одно о начале, и одно об окончании).
`MAIL_MERGE_MAX_TIME_DIFFERENCE`	5000	Содержит в себе предел по разнице времени (в миллисекундах) между сообщениями для объединения в один email. Система отправки оповещений устроена так, что отправляет email уведомления не мгновенно, а с некоторыми интервалами. Соответственно, если перед отправкой имеется несколько уведомлений, которые необходимо объединить в один email (их типы прописаны `MAIL_MERGE_LOG_TYPES`), то будут объеденины только те уведомления, разница во времени появления которых не превышает значение данного параметра. Это полезно для случая, когда в достаточно короткий срок было запущено две операции резервного копирования, чтобы email уведомления разных операций не объединялись между собой.
`MAIL_LOCALE`	-	Содержит код языка, на который нужно переводить email уведомления. На данный момент поддерживается только два значения `en` (английский) и `ru` (русский). Если код языка не указан (или указан `en`), то содержимое email уведомлений будет на английском языке. Если указать значение `ru`, то на русском: `MAIL_LOCALE=ru`

Подробнее о настройке параметров уведомлений о событиях в ovirt-engine-notifier.conf см. в разделе Уведомления о событиях руководства администратора.

Описание настроек планировщика резервного копирования менеджера управления

В таблице ниже представлено общее описание параметров, доступных для настройки в окнах Добавление задачи (Adding a task) и Редактирование задачи (Editing a task)

Таблица 72. Настройки задания резервного копирования
Параметр	Описание
Расположение файла резервной копии (Backup file location)	Локальное расположение файла резервной копии. По умолчанию /var/lib/zvirt-engine-backup/
Расписание (Schedule)	Выражение в формате quartz cron, определяющее расписание запуска задачи
Описание (Description)	Описание добавляемого задания
Состав компонентов (Composition of components)	Соответствует параметру `--scope` в утилите `engine-backup`. Должен быть выбран хотя бы один из компонентов. Список доступных для выбора пунктов: Все компоненты (All components) - при выборе данного пункта должны отмечаться все указанные ниже компоненты. В утилите `engine-backup` соответствует значению параметра `--scope=all` Файлы конфигурации (Configuration files) - в утилите `engine-backup` соответствует значению параметра `--scope=files` База данных менеджера управления (Manager’s database) в утилите `engine-backup` соответствует значению параметра `--scope=db` База данных DWH (DWH database) - в утилите `engine-backup` соответствует значению параметра `--scope=dwhdb` База данных Cinderlib (Cinderlib database) - в утилите `engine-backup` соответствует значению параметра `--scope=cinderlibdb` База данных Grafana (Grafana database) - в утилите `engine-backup` соответствует значению параметра `--scope=grafanadb` Дополнительную информацию об утилите `engine-backup` и её параметрах см. в разделе Резервное копирование и восстановление Менеджера управления руководства администратора
Хранилище (Storage)	Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально

Использование формата Quartz cron для задания расписания

При ручном вводе выражения, определяющего расписание запуска задачи, ожидается использование формата Quartz cron. Данный формат состоит из 6 или 7 полей, разделенных пробелом. Каждое поле имеет определённую значимость.

Поля могут содержать любые допустимые значения, а также различные комбинации разрешенных специальных символов для этого поля. Допустимые значения и символы представлены в таблице ниже

Номер

Имя поля

Допустимые значения

Разрешенные специальные символы

Секунды

0-59

, - * /

Минуты

0-59

, - * /

Часы

0-23

, - * /

День месяца

1-31

, - * ? / L W

Месяц

1-12 или JAN-DEC

, - * /

День недели

1-7 или SUN-SAT

, - * ? / L #

Год (необязательное)

Пустое или 1970-2099

, - * /

Значение специальных символов

(все значения) - используется для выбора всех значений в поле. Например, в поле минут означает «каждую минуту»
? (любое значение) - полезно, когда нужно указать что-то в одном из двух полей, в которых этот символ разрешен, но не в другом. Например, если необходимо, чтобы задача запустилась в определенный день месяца (допустим, 10-го числа), но все равно, какой это будет день недели, то можно разместить 10 в поле "День месяца", а ? - в поле "День недели".
- - используется для указания диапазонов. Например, 10-12 в поле часов означает "часы 10, 11 и 12"
, - используется для указания дополнительных значений. Например, MON,WED,FRI в поле "день недели" означает "дни понедельник, среда и пятница".
/ - используется для указания приращений. Например, 0/15 в поле секунд означает "секунды 0, 15, 30 и 45". А 5/15 в поле секунд означает "секунды 5, 20, 35 и 50".
L (последний) - имеет разное значение в каждом из двух полей, в которых оно разрешено. Например, значение L в поле "день месяца" означает "последний день месяца" - 31 день для января, 28 день для февраля в невисокосные годы. Если это значение используется в поле дня недели само по себе, оно означает просто "7" или "SAT". Но если оно используется в поле дня недели после другого значения, оно означает "последний xxx день месяца" - например, 6L означает "последняя пятница месяца". При использовании опции L важно не указывать списки или диапазоны значений, так как вы получите путаные/неожиданные результаты.
W (будний день) - используется для указания ближайшего к данному дню дня недели (понедельник-пятница). Например, если вы укажете 15W в качестве значения для поля "День месяца", это будет означать: "ближайший будний день к 15 числу месяца". Таким образом, если 15-е число приходится на субботу, задача запустится в пятницу 14-го. Если 15-е число приходится на воскресенье, задача запустится в понедельник 16-го. Если 15-е число приходится на вторник, то задача запустится во вторник 15-го. Однако если вы укажете 1W в качестве значения дня месяца, а 1-е число будет субботой, задача запустится в понедельник 3-го числа, поскольку он не будет "перескакивать" через границу дней месяца. Символ W может быть указан только в том случае, если день месяца - это один день, а не диапазон или список дней.
# - используется для указания "n-го" XXX дня месяца. Например, значение 6#3 в поле "День недели" означает "третья пятница месяца" (день 6 = пятница, а #3 = третий в месяце).

Пример 34. Использование формата quartz cron

Выражение Значение

0 0 12 * * ?

Запуск в 12 часов дня каждый день

0 15 10 ? * *

Запуск в 10:15 утра каждый день

0 15 10 * * ? 2023

Запуск в 10:15 утра каждый день в течение 2023 года

0 * 14 * * ?

Запуск каждую минуту, начиная с 14:00 и заканчивая 14:59, каждый день

0 0/5 14,18 * * ?

Запуск каждые 5 минут, с 14:00 и до 14:55, а также с 18:00 и до 18:55, каждый день

0 15 10 ? * MON-FRI

Запуск в 10:15 утра каждый понедельник, вторник, среду, четверг и пятницу

0 15 10 L * ?

Запуск в 10:15 утра в последний день каждого месяца

0 15 10 ? * 6#3

Запуск в 10:15 утра в третью пятницу каждого месяца

Управление разрешением на резервное копирование менеджера управления

Пользователю, не имеющему определённое разрешение, недоступна функциональность резервного копирования через Портал администрирования (как однократно, так и работа со сценариями резервного копирования по расписанию).

Для предоставления прав на использование функций резервного копирования через веб-интерфейс, необходимо для нужной роли задать разрешение Резервное копирование менеджера управления (Engine backup management).

Разрешение Резервное копирование менеджера управления (Engine backup management) доступно только для типа учётной записи Администратор (Admin).

Для роли SuperUser разрешение Резервное копирование менеджера управления (Engine backup management) включено по умолчанию.

Дополнительную информацию по настройке ролей см. в разделах Роли и Системные разрешения в руководстве администратора.

3.2.2. Перенос базы данных и службы Data Warehouse на отдельную машину

В этом разделе описано, как перенести базу данных и службу Data Warehouse с машины с Менеджером управления на отдельную машину. Размещение службы Data Warehouse (ovirt-engine-dwhd) на отдельной машине снижает нагрузку на каждую отдельную машину и позволяет избежать потенциальных конфликтов, связанным с тем, что ресурсы ЦП и памяти приходится делить с другими процессами.

zVirt поддерживает установку базы данных и службы Data Warehouse и Grafana на одной машине, хотя можно установить каждый из этих компонентов на отдельных машинах.

Доступны следующие варианты миграции:

Можно перенести службу Data Warehouse (ovirt-engine-dwhd) с машины с Менеджером управления и подключить ее к существующей базе данных Data Warehouse (ovirt_engine_history).
Можно перенести базу данных Data Warehouse (ovirt_engine_history) с машины с Менеджером управления, а затем перенести службу Data Warehouse (ovirt-engine-dwhd).

Данный раздел предполагает, что новая машина развёрнута на основе дистрибутива zVirt Node

3.2.2.1. Перенос базы данных Data Warehouse на отдельную машину

Перенесите базу данных Data Warehouse (ovirt_engine_history) до переноса службы Data Warehouse. Используйте engine-backup для создания резервной копии базы данных и ее восстановления на новой машине с базой данных. Дополнительные сведения о engine-backup см. с помощью команды engine-backup --help.

Порядок действий:

Создайте резервную копию базы данных и файлов конфигурации Data Warehouse в Менеджере управления:
```
# engine-backup --mode=backup --scope=dwhdb --scope=files --file=_file_name_ --log=_log_file_name_
```
Скопируйте файл резервной копии из Менеджера управления на новую машину.
```
# scp _/tmp/file_name_ _root@new.dwh.server.com:/tmp_
```
Восстановите базу данных Data Warehouse на новой машине. file_name – это файл резервной копии, скопированный из Менеджера управления.
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --provision-dwh-db --restore-permissions
```

Теперь база данных Data Warehouse и Менеджер управления размещаются на разных машинах. После успешного восстановления базы данных Data Warehouse система предложит выполнить команду engine-setup. Перед выполнением этой команды перенесите службу Data Warehouse.

3.2.2.2. Перенос службы Data Warehouse на отдельную машину

Службу Data Warehouse (ovirt-engine-dwhd), установленную и настроенную в Менеджере управления, можно перенести на отдельную машину. Размещение службы Data Warehouse на отдельной машине помогает снизить нагрузку на машину с Менеджером управления.

Обратите внимание, что эта процедура переносит только службу Data Warehouse. Информацию о том, как перенести базу данных Data Warehouse (ovirt_engine_history) перед переносом службы Data Warehouse, см. в разделе Перенос базы данных Data Warehouse на отдельную машину.

Предварительные условия:

На одной машине должны быть установлены и настроены Менеджер управления и Хранилище Data Warehouse.
Чтобы настроить новую машину с Хранилищем Data Warehouse, нужно иметь:
- Пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup-database.conf Менеджера управления.
- Разрешенный доступ с машины с Хранилищем Data Warehouse к TCP-порту 5432 машины с базой данных Менеджера управления.
- Имя пользователя и пароль для базы данных Data Warehouse из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf Менеджера управления.

Если перенос базы данных ovirt_engine_history выполнялся с использованием процедур, описанных в разделе Перенос базы данных Data Warehouse на отдельную машину, то резервная копия включает в себя эти учетные данные, заданные во время настройки базы данных на этой машине.

Для установки этого сценария выполните следующие шаги:

Остановка службы Data Warehouse на машине с Менеджером управления
Настройка новой машины со службой Data Warehouse
Отключение пакета Хранилища Data Warehouse на машине с Менеджером управления.

Остановка службы Data Warehouse на машине с Менеджером управления

Порядок действий:

Остановите службу Data Warehouse:
```
# systemctl stop ovirt-engine-dwhd.service
```
Если база данных размещена на удаленной машине, предоставьте доступ вручную, изменив файл postgres.conf. Измените файл /var/lib/pgsql/data/postgresql.conf и скорректируйте строку listen_addresses, чтобы она выглядела так:
listen_addresses = '*'
Если этой строки нет или она закомментирована, то добавьте ее вручную.

Если база данных размещена на машине с Менеджером управления и была настроена во время чистой установки Менеджера управления, то доступ предоставляется по умолчанию.
Перезапустите службу postgresql:
```
# systemctl restart postgresql
```

Настройка новой машины со службой Data Warehouse

Порядок опций или настроек, описанных в этом разделе, может отличаться в зависимости от вашей среды.

В случае переноса базы данных ovirt_engine_history и службы Data Warehouse на одну и ту же машину выполните перечисленные ниже действия, в противном случае перейдите к следующему шагу.
# sed -i '/^ENGINE_DB_/d' \ /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf # sed -i \ -e 's;^$OVESETUP_ENGINE_CORE/enable=bool$:True;\1:False;' \ -e '/^OVESETUP_CONFIG\/fqdn/d' \ /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf # sed -i 's/localhost/<mgr-fqdn>/' \ /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
где, <mgr-fqdn> - FQDN машины с менеджером управления
Выполните команду engine-setup, чтобы начать настройку Хранилища Data Warehouse на машине:
```
# engine-setup
```
Нажмите Enter, чтобы принять автоматически обнаруженное имя хоста, либо введите альтернативное имя хоста и нажмите Enter:
```
Host fully qualified DNS name of this server [_autodetected host name_]:
```
Нажмите Enter, чтобы автоматически настроить межсетевой экран, либо напечатайте No и нажмите Enter, чтобы сохранить текущие настройки:
Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]:
Если будет выбрана автоматическая настройка межсетевого экрана и ни один менеджер межсетевого экрана не активен, то система предложит выбрать предпочтительный менеджер межсетевого экрана из списка поддерживаемых вариантов. Напечатайте имя менеджера межсетевого экрана и нажмите Enter. Это применимо, даже если список содержит всего один элемент.

Введите FQDN и пароль для Менеджера управления. Нажмите Enter, чтобы принять значения по умолчанию в каждом из остальных полей:

Host fully qualified DNS name of the engine server []: _engine-fqdn_
Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
Please choose one of the following:
1 - Access remote engine server using ssh as root
2 - Perform each action manually, use files to copy content around
(1, 2) [1]:
ssh port on remote engine server [22]:
root password on remote engine server _engine-fqdn_: _password_

Введите FQDN и пароль для машины с базой данных Менеджера управления. Нажмите Enter, чтобы принять значения по умолчанию в каждом из остальных полей:
```
Engine database host []: _manager-db-fqdn_
Engine database port [5432]:
Engine database secured connection (Yes, No) [No]:
Engine database name [engine]:
Engine database user [engine]:
Engine database password: _password_
```
Подтвердите настройки, с которыми будет выполняться установка:
```
Please confirm installation settings (OK, Cancel) [OK]:
```

Теперь служба Data Warehouse настроена на удаленной машине. Далее отключите службу Data Warehouse на машине с Менеджером управления.

Отключение службы Хранилища Data Warehouse на машине с Менеджером управления

Порядок действий:

Перезапустите Менеджер управления на машине с Менеджером управления:
```
# service ovirt-engine restart
```

Выполните следующую команду, чтобы изменить файл /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf и установить параметры в значение False:

# sed -i \
    -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
    -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
    /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

# sed -i \
    -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
    /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Отключите службу Data Warehouse:
```
# systemctl disable ovirt-engine-dwhd.service
```

Удалите файлы Хранилища Data Warehouse:

# rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf /var/lib/ovirt-engine-dwh/backups/*

Теперь служба Хранилища (DWH) и Менеджер управления размещаются на разных машинах.

3.2.3. Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения (Backup Storage Domain)

3.2.3.1. Описание Резервного домена хранения

Резервный домен хранения – это домен, который можно использовать специально для хранения и миграции виртуальных машин и шаблонов виртуальных машин с целью резервного копирования и восстановления в случае аварии, миграции и т.д. Резервный домен отличается от нерезервного тем, что все виртуальные машины в нем находятся в выключенном состоянии. Виртуальная машина не может работать в резервном домене.

Любой домен хранения данных можно задать в качестве резервного домена. Чтобы включить/выключите эту настройку, установите/снимите флажок "Резервная копия (Backup)" в диалоговом окне "Управление доменом (Manage Domain)". Эту настройку можно включить только после остановки всех виртуальных машин в этом домене хранения.

Невозможно запустить виртуальную машину, хранящуюся в резервном домене. Менеджер управления блокирует эту и любую другую операцию, которая может сделать резервную копию недействительной. Однако можно запустить виртуальную машину на основе шаблона, хранящегося в резервном домене, если диски этой виртуальной машины не являются частью резервного домена. Как и в случае с другими типами доменов хранения, резервные домены можно подключать к центру данных и отключать от него. Таким образом, помимо хранения резервных копий, резервные домены можно использовать для переноса виртуальных машин между центрами данных.

Преимущества

Вот несколько причин использовать резервный домен, а не домен экспорта:

В центре данных может быть несколько резервных доменов хранения, но лишь один домен экспорта.
Можно выделить резервный домен хранения для резервного копирования и аварийного восстановления.
Можно перенести резервную копию виртуальной машины, шаблона или моментального снимка в резервный домен хранения.
С резервными доменами миграция большого количества виртуальных машин, шаблонов или файлов OVF выполняется значительно быстрее, чем с доменами экспорта.
Резервный домен использует дисковое пространство эффективнее, чем домен экспорта.
Резервные домены поддерживают как файловое хранилище (NFS, Gluster), так и блочное (Fiber Channel и iSCSI) – в отличие от доменов экспорта, поддерживающих только файловое.
Настройку "Резервная копия (Backup)" для домена хранения можно динамически включать и выключать с учетом ограничений.

Ограничения

У любой виртуальной машины или шаблона в резервном домене (backup) все диски должны быть в этом же домене.
Все виртуальные машины в домене хранения должны быть выключены, прежде чем его можно будет сделать резервным доменом.
Невозможно запустить виртуальную машину, хранящуюся в резервном домене, потому что это может привести к изменению данных на диске.
Резервный домен не может быть целевым доменом томов памяти (memory volumes), поскольку тома памяти поддерживаются только для активных виртуальных машин.
Предварительный просмотр виртуальной машины в резервном домене невозможен.
Перенос виртуальной машины "на лету" в резервный домен невозможен.
Невозможно задать резервный домен в качестве мастер-домена.
Невозможно задать домен hosted engine в качестве резервного домена.
Не используйте домен хранения по умолчанию в качестве резервного домена.

3.2.3.2. Установка домена хранения данных в качестве резервного домена.

Предварительные условия:

Все диски, принадлежащие виртуальной машине или шаблону в домене хранения, должны находиться в одном и том же домене.
Все виртуальные машины в домене должны быть выключены.

Порядок действий:

На Портале администрирования нажмите Хранилище (Storage) Домены (Domains).
Создайте новый домен хранения или выберите существующий домен хранения и нажмите Управление доменом (Manage Domain). Откроется диалоговое окно "Управление доменом (Manage Domains).
В блоке Дополнительные параметры (Advanced Parameters) установите флажок "Резервная копия (Backup)".

Теперь домен стал резервным доменом.

3.2.3.3. Резервное копирование или восстановление виртуальной машины или моментального снимка с использованием резервного домена

Можно выполнить резервное копирование выключенной виртуальной машины или моментального снимка. Затем можно сохранить резервную копию в том же центре данных и восстановиться с нее при необходимости либо перенести ее в другой центр данных.

Резервное копирование виртуальной машины

Порядок действий:

Создайте резервный домен. См. раздел Установка домена хранения данных в качестве резервного домена.
Создайте новую виртуальную машину на базе виртуальной машины, резервную копию которой вы хотите сделать:
- Чтобы сделать резервную копию снимка, сначала создайте из него виртуальную машину. См. раздел Создание виртуальной машины из моментального снимка Руководства по управлению виртуальными машинами.
- Чтобы сделать резервную копию виртуальной машины, сначала клонируйте ее. См. раздел Клонирование виртуальной машины Руководства по управлению виртуальными машинами. Прежде чем продолжить, убедитесь, что клон выключен.
Экспортируйте новую виртуальную машину в резервный домен. См. раздел Экспортирование виртуальной машины в домен данных Руководства по управлению виртуальными машинами.

Восстановление виртуальной машины

Порядок действий:

Убедитесь, что резервный домен хранения, в котором хранится резервная копия виртуальной машины, подключен к центру данных.
Импортируйте виртуальную машину из резервного домена. См. раздел Импортирование виртуальной машины из домена данных Руководства по управлению виртуальными машинами.
Дополнительные ресурсы
Импортирование доменов хранения

Перенос доменов хранения между центрами данных в одной среде

Перенос доменов хранения между центрами данных в разных средах

3.2.4. Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления

3.2.4.1. API резервного копирования и восстановления

API резервного копирования и восстановления – это набор функций, которые позволяют выполнять полное или пофайловое резервное копирование и восстановление виртуальных машин. API сочетает в себе ряд компонентов zVirt (таких как создаваемые на лету снимки и REST API) для создания и использования временных томов, которые можно подключить к виртуальной машине, содержащей ПО резервного копирования, предоставленное независимым поставщиком ПО.

Информацию о поддерживаемых сторонних вендорах ПО резервного копирования см. на официальном сайте в разделе Совместимое ПО и оборудование.

3.2.4.2. Резервное копирование виртуальной машины

Используйте API резервного копирования и восстановления для создания резервной копии виртуальной машины. Эта процедура предполагает, что у вас есть две виртуальные машины:

виртуальная машина, резервную копию которой нужно сделать
резервирующая виртуальная машина - виртуальная машина, на которой установлено ПО для управления резервным копированием

Порядок действий:

Используя REST API, создайте снимок виртуальной машины, резервную копию которой нужно сделать:

POST /api/vms/`_{vm:id}_`/snapshots/ HTTP/1.1 (1)
Accept: application/xml
Content-type: application/xml

<snapshot>
    <description>BACKUP</description>
</snapshot>

1 Замените {vm:id} идентификатором виртуальной машины, снимок которой вы делаете. Этот идентификатор можно посмотреть на вкладке Общие (General) окон Создать виртуальную машину (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine) на Портале администрирования и Пользовательским портале.

При создании снимка виртуальной машины данные ее текущей конфигурации помещаются в атрибут data атрибута configuration блока initialization, расположенного под снимком.

Невозможно делать снимки дисков, помеченных как общие или основанных на дисках Direct LUN.

Получите данные конфигурации виртуальной машины из атрибута data соответствующего снимка:

GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2)
All-Content: true
Accept: application/xml
Content-type: application/xml

1	Замените `{vm:id}` идентификатором виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{snapshot:id}` идентификатором снимка.

Добавьте заголовок All-Content: true, чтобы получить дополнительные данные OVF в ответе. Данные OVF в XML-ответе находятся в элементе конфигурации виртуальной машины <initialization><configuration>. Позже вы будете использовать эти данные для восстановления виртуальной машины.

Получите идентификатор снимка:

GET /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

Определите соответствующий снимку идентификатор диска:

GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_`/disks HTTP/1.1
Accept: application/xml
Content-type: application/xml

Подключите к резервирующей виртуальной машине снимок как активный диск, используя корректный тип интерфейса (например, virtio_scsi):

POST /api/vms/`_{vm:id}_`/diskattachments/ HTTP/1.1 (1)
Accept: application/xml
Content-type: application/xml
<disk_attachment>
<active>true</active>
<interface>_virtio_scsi_</interface>
<disk id="_{disk:id}_"> (2)
<snapshot id="_{snapshot:id}_"/> (3)
</disk>
</disk_attachment>

1	Замените `{vm:id}` идентификатором резервирующей виртуальной машины, а не той виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{disk:id}` идентификатором диска.
3	Замените `{snapshot:id}` идентификатором снимка.

Используйте ПО резервного копирования на резервирующей виртуальной машине для резервного копирования данных со снимка, подключенного как диск.

Отключите снимок, подключенный как диск, от резервирующей виртуальной машины:

DELETE /api/vms/`_{vm:id}_`/diskattachments/`_{snapshot:id}_` HTTP/1.1 (1) (2)
Accept: application/xml
Content-type: application/xml

1	Замените `{vm:id}` идентификатором резервирующей виртуальной машины, а не той виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{snapshot:id}` идентификатором снимка.

При желании удалите снимок:

DELETE /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2)
Accept: application/xml
Content-type: application/xml

1	Замените `{vm:id}` идентификатором виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{snapshot:id}` идентификатором снимка.

Вы создали резервную копию состояния виртуальной машины в фиксированный момент времени с помощью ПО резервного копирования, установленного на отдельной виртуальной машине.

3.2.4.3. Восстановление виртуальной машины

Чтобы восстановить виртуальную машину, для которой была создана резервная копия, используйте API резервного копирования и восстановления. Эта процедура предполагает, что у вас есть резервирующая виртуальная машина, на которой установлено ПО, управлявшее предыдущей резервной копией.

Порядок действий:

На Портале администрирования создайте плавающий диск, на который нужно восстановить ВМ из резервной копии. Подробную информацию о порядке создания плавающего диска см. в разделе Создание виртуального диска.

Подключите диск к резервирующей виртуальной машине:

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1 (1)
Accept: application/xml
Content-type: application/xml

<disk id="_{disk:id}_"> (2)
</disk>

1	Замените `{vm:id}` на идентификатор (ID) резервирующей виртуальной машины, а не виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{disk:id}` на идентификатор диска, который вы получили во время резервного копирования виртуальной машины.

Чтобы восстановить виртуальную машину из резервной копии на диск, используйте программу резервного копирования.

Отключите диск от резервирующей виртуальной машины

DELETE /api/vms/`_{vm:id}_`/disks/_{disk:id}_ HTTP/1.1 (1) (2)
Accept: application/xml
Content-type: application/xml

<action>
    <detach>true</detach>
</action>

1	Замените `{vm:id}` на идентификатор (ID) резервирующей виртуальной машины, а не виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{disk:id}` на идентификатор диска.

Создайте новую виртуальную машину, используя данные конфигурации восстанавливаемой виртуальной машины:

POST /api/vms/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<vm>
    <cluster>
        <name>cluster_name</name>
    </cluster>
    <name>_NAME_</name>
        <initialization>
        <configuration>
<data>
<!-- omitting long ovf data -->
</data>
        <type>ovf</type>
        </configuration>
        </initialization>
    ...
</vm>

Чтобы при создании виртуальной машины переопределить любое из значений в ovf, переопределите элемент до или после элемента initialization. Не внутри элемента инициализации.

Подключите диск к новой виртуальной машине:

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1 (1)
Accept: application/xml
Content-type: application/xml
<disk id="_{disk:id}_"> (2)
</disk>

1	Замените `{vm:id}` на идентификатор новой виртуальной машины[.underline], а не виртуальной машины, снимок которой вы сделали ранее.
2	Замените `{disk:id}` на идентификатор диска.

Вы восстановили виртуальную машину из резервной копии, созданной с помощью API резервного копирования и восстановления.

3.2.5. Резервное копирование и восстановление виртуальных машин с помощью API инкрементного резервного копирования и восстановления

zVirt предоставляет API инкрементного резервного копирования, который можно использовать для создания полных резервных копий виртуальных дисков форматов QCOW2 или RAW или инкрементных резервных копий виртуальных дисков формата QCOW2 без создания каких-либо временных снимков. Резервные копии данных создаются в формате RAW независимо от того, в каком формате созданы резервные копии виртуального диска - QCOW2 или RAW. Можно восстанавливать гостевые данные формата RAW и диски формата RAW или QCOW2. API инкрементного резервного копирования входит в состав zVirt REST API. Можно создавать резервные копии как работающих, так и неработающих виртуальных машин.

Как разработчик, вы можете использовать API для разработки приложения резервного копирования.

Особенности

Резервное копирование выполняется проще, быстрее и надежнее, чем при использовании API резервного копирования и восстановления. API инкрементного резервного копирования обеспечивает улучшенную интеграцию с приложениями резервного копирования; в него добавлена поддержка резервного копирования и восстановления гостевых данных формата RAW независимо от формата базового диска.

Если некорректная карта битов вызывает сбой резервного копирования, то можно удалить конкретную контрольную точку в цепочке резервного копирования. Запускать полное резервное копирование не нужно.

Ограничения

Инкрементное резервное копирование можно выполнять только для дисков формата QCOW2, а не RAW. В процессе резервного копирования резервные копии данных сохраняются в формате RAW.
Данные можно восстановить только из резервных копий формата RAW.
Инкрементное восстановление не поддерживает восстановление снимков, существовавших на момент резервного копирования. При инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в снимках, существовавших на момент резервного копирования. Это ограничение обычно присутствует в решениях резервного копирования для других систем.
Обычно в решениях резервного копирования при инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в снимках, существовавших на момент резервного копирования.
Некорректное завершение работы виртуальной машины по любой причине может испортить карты битов на диске, что повредит всю цепочку резервного копирования. Восстановление из инкрементной резервной копии с помощью некорректной карты битов приведет к повреждению данных виртуальной машины.

Некорректную карту битов можно обнаружить только при запуске резервного копирования. Если на диске есть какие-либо поврежденные карты битов, то операция завершится ошибкой.

В следующей таблице описаны конфигурации дисков, поддерживающие инкрементное резервное копирование.

При создании диска с помощью Портала администрирования вы задаете тип хранилища, тип предоставления дискового пространства, а также указываете, включено или отключено инкрементное резервное копирование. На основе этих настроек Менеджер управления определяет формат виртуального диска.

Поддерживаемые конфигурации дисков для инкрементного резервного копирования

|Тип хранилища | Политика выделения дискового пространства | Статус инкрементного резервного копирования | Формат виртуального диска

3.2.5.1. Процесс инкрементного резервного копирования

Для резервного копирования дисков виртуальных машин, для которых уже включено инкрементное резервное копирование, приложение резервного копирования, использующее API инкрементного резервного копирования, должно соблюдать следующую последовательность:

Приложение резервного копирования использует REST API для поиска дисков виртуальной машины, которые нужно добавить в резервную копию. Добавляются только диски формата QCOW2.
Приложение резервного копирования запускает полное резервное копирование или инкрементное резервное копирование. Вызов API указывает идентификатор виртуальной машины, необязательный идентификатор предыдущей контрольной точки и список дисков для резервного копирования. Если в вызове API не указан идентификатор предыдущей контрольной точки, то начинается полное резервное копирование, охватывающее все данные на указанных дисках, исходя из текущего состояния каждого диска.
Менеджер управления подготавливает виртуальную машину к резервному копированию. Во время резервного копирования виртуальная машина может продолжать работать.
Приложение резервного копирования запрашивает у Менеджера управления статус резервного копирования до тех пор, пока он не сообщит о готовности начать резервное копирование.
При готовности начать резервное копирование приложение резервного копирования создаст объект imagetransfer для каждого диска, включенного в резервную копию.
Приложение резервного копирования получает список измененных блоков от ovirt-imageio для каждой передачи образов. Если список изменений недоступен, то приложение резервного копирования выдаст ошибку.
Приложение резервного копирования загружает измененные блоки в формате RAW из ovirt-imageio и сохраняет их на резервном носителе. Если список измененных блоков недоступен, то приложение резервного копирования может откатиться к копированию всего диска.
Приложение резервного копирования завершает все передачи образов.
Приложение резервного копирования завершает резервное копирование с помощью REST API.

3.2.5.2. Процесс инкрементного восстановления

Приложение резервного копирования, использующее API инкрементного резервного копирования, должно соблюдать следующую последовательность действий для восстановления дисков виртуальных машин, для которых были созданы резервные копии:

С помощью приложения резервного копирования пользователь выбирает точку восстановления, исходя из доступных резервных копий.
Приложение резервного копирования создает новый диск или снимок существующего диска для хранения восстановленных данных.
Приложение резервного копирования запускает передачу выгружаемого образа для каждого диска, задав для параметра format значение raw. Это позволяет конвертировать формат при выгрузке данных формата RAW на диск формата QCOW2.
Приложение резервного копирования передает данные, включенные в эту точку восстановления, в imageio с помощью API.
Приложение резервного копирования завершает передачи образов.

3.2.5.3. Задачи, связанные с API инкрементного резервного копирования и восстановления

API инкрементного резервного копирования и восстановления описан в руководстве по REST API

Процесс резервного копирования и восстановления предусматривает выполнение следующих действий:

Включение инкрементного резервного копирования либо на новом, либо на существующем виртуальном диске:
- На новом диске с помощью Портала администрирования
- На существующем диске с помощью Портала администрирования
- На новом или существующем диске с помощью вызова API
Поиск дисков, для которых включено инкрементное резервное копирование
Запуск полного резервного копирования
Запуск инкрементного резервного копирования
Завершение резервного копирования
Получение информации о резервной копии
Получение информации о дисках в резервной копии
Составление списка всех контрольных точек для виртуальной машины
Выдача информации по конкретной контрольной точке для виртуальной машины
Удаление контрольной точки конкретной виртуальной машины
Загрузка объекта imagetransfer для архивирования резервной копии
Выгрузка объекта imagetransfer для восстановления из резервной копии
Составление списка измененных блоков
Загрузка и выгрузка измененных блоков

Включение инкрементного резервного копирования на новом виртуальном диске

Включите инкрементное резервное копирование для виртуального диска, чтобы пометить, что он входит в состав инкрементного резервного копирования. При добавлении диска можно включить инкрементное резервное копирование для каждого диска либо с помощью REST API, либо на Портале администрирования. Создавать резервные копии существующих дисков, для которых не включено инкрементное резервное копирование, можно с помощью полного резервного копирования или так, как описано в разделах Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения и Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления.

Менеджер управления может добавить диск в инкрементное резервное копирование, даже если оно не включено на диске, но его можно включить, чтобы отслеживать, на каких дисков оно включено.

Поскольку для инкрементного резервного копирования требуются диски в формате QCOW2, используйте QCOW2 вместо RAW.

Порядок действий:

Добавьте новый виртуальный диск. Дополнительную информацию см. в разделе Создание виртуального диска.
При настройке параметров диска установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).
Дополнительные ресурсы
Включение инкрементного резервного копирования с помощью API

Включение инкрементного резервного копирования на существующем виртуальном диске формата RAW

Поскольку инкрементное резервное копирование не поддерживается для дисков в формате RAW, для его использования на всех дисках формата RAW поверх должен существовать слой формата QCOW2. При создании снимка создается слой QCOW2, делающий возможным инкрементное резервное копирование на все диски, включенные в снимок, с точки, в которой создается снимок.

Если на базовом слое диска используется формат RAW, то удаление последнего снимка и объединение верхнего слоя QCOW2 с базовым слоем преобразует диск в формат RAW, тем самым отключая инкрементное резервное копирование, если оно было установлено. Чтобы снова включить инкрементное резервное копирование, можно создать новый снимок, включающий в себя этот диск.

Порядок действий:

На Портале администрирования нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Выберите виртуальную машину и откройте вкладку Диски (Disks).
Нажмите Изменить (Edit). Откроется диалоговое окно Изменить виртуальный диск (Edit Virtual Disk).
Установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).
Дополнительные ресурсы
Включение инкрементного резервного копирования с помощью API

Включение инкрементного резервного копирования с помощью API

Вы можете использовать запрос по REST API, чтобы включить инкрементное резервное копирование для диска виртуальной машины.

Порядок действий:

Включите инкрементное резервное копирование для нового диска. Например, для нового диска на виртуальной машине с идентификатором 123 отправьте запрос:
POST /ovirt-engine/api/vms/123/diskattachments
Тело этого запроса должно включать в себя параметр backup, установленный в значение incremental, в составе объекта disk, как показано ниже:
<disk_attachment> ... <disk> ... <backup>incremental</backup> ... </disk> </disk_attachment>
Ответ:
<disk_attachment> ... <disk href="/ovirt-engine/api/disks/456" id="456"/> ... </disk_attachment>
Дополнительные ресурсы
Раздел DiskBackup enum в руководстве REST API

Поиск дисков, на которых включено инкрементное резервное копирование

Для указанной виртуальной машины можно вывести список дисков, на которых включено инкрементное резервное копирование, отфильтрованных по свойству резервного копирования.

Порядок действий:

Выведите список дисков, подключенных к виртуальной машине. Например, для виртуальной машины с идентификатором 123 отправьте запрос:
GET /ovirt-engine/api/vms/123/diskattachments
Ответ включает в себя все объекты disk_attachment, каждый из которых включает в себя один или несколько объектов disk. Например:
<disk_attachments> <disk_attachment> ... <disk href="/ovirt-engine/api/disks/456" id="456"/> ... </disk_attachment> ... </disk_attachments>
Используйте службу disk, чтобы просмотреть свойства диска из предыдущего шага. Например, для диска с идентификатором 456 отправьте запрос:
GET /ovirt-engine/api/disks/456
Ответ включает в себя все свойства для диска. Параметр backup установлен в значение none или incremental. Например:
<disk href="/ovirt-engine/api/disks/456" id="456"> ... <backup>incremental</backup> ... </disk>
Дополнительные ресурсы
Атрибут backup раздела Disk struct в руководстве REST API

Раздел DiskBackup enum в руководстве REST API

Запуск полного резервного копирования с помощью API

После полного резервного копирования можно использовать полученный идентификатор контрольной точки в качестве начальной точки для следующего инкрементного резервного копирования.

При резервном копировании работающей виртуальной машины процесс создает временный диск в том же домене хранения, в котором находится копируемый диск. Процесс резервного копирования создает этот диск, чтобы сделать возможной запись новых данных на работающую виртуальную машину во время резервного копирования. Этот временный диск можно увидеть на Портале администрирования во время резервного копирования. По завершении резервного копирования он автоматически удаляется.

Запуск полного резервного копирования требует вызова запроса с телом и включает в себя ответ.

Порядок действий:

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
```
POST /ovirt-engine/api/vms/123/backups
```
В теле запроса укажите диск, с которого нужно снять резервную копию. Например, чтобы запустить полное резервное копирование диска с идентификатором 456, отправьте запрос со следующим телом:
<backup> <disks> <disk id="456" /> ... </disks> </backup>
Тело ответа должно выглядеть примерно так:
<backup id="789"> <disks> <disk id="456" /> ... ... </disks> <status>initializing</status> <creation_date> </backup>
Ответ включает в себя:
- Идентификатор резервной копии
- Статус резервной копии, указывающий, что она инициализируется.
Опрос резервной копии до появления статуса ready (готова). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.
Дополнительные ресурсы
Метод add службы VmBackups в руководстве REST API

Запуск инкрементного резервного копирования с помощью API

После завершения полного резервного копирования данного виртуального диска последующие инкрементные резервные копии этого диска будут содержать только изменения, внесенные с момента последнего резервного копирования. Используйте значение идентификатора конечной контрольной точки (to_checkpoint_id) из последней резервной копии в качестве значения для идентификатора начальной контрольной точки (from_checkpoint_id) в теле запроса.

Запуск инкрементного или смешанного резервного копирования требует вызова запроса с телом и включает в себя ответ.

Порядок действий:

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
```
POST /ovirt-engine/api/vms/123/backups
```

В теле запроса укажите диск, с которого нужно снять резервную копию. Например, чтобы запустить инкрементное резервное копирование диска с идентификатором 456, отправьте запрос со следующим телом:

<backup>
    <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
    <disks>
    <disk id="456" />
    ...
    </disks>
</backup>

Если в тело запроса включить диск, не включенный в предыдущую контрольную точку, то запрос также запустит полное резервное копирование этого диска. Пусть, например, с диска с идентификатором 789 резервная копия еще не снималась. Чтобы добавить полное резервное копирование диска 789 к вышеприведенному телу запроса, отправьте тело запроса следующего вида:

<backup>
    <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
    <disks>
    <disk id="456" />
    <disk id="789" />
    ...
    </disks>
</backup>

Тело ответа должно выглядеть примерно так:

<backup id="101112">
<from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id>
<to_checkpoint_id>__new-checkpoint-uuid__</to_checkpoint_id>
    <disks>
    <disk id="456" />
    <disk id="789" />
    ...
    ...
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>

Ответ включает в себя:

Идентификатор резервной копии.
Идентификатор любого диска, который был включен в резервную копию.
Статус, указывающий, что резервная копия инициализируется.

Опрос резервной копии до появления статуса ready (готова). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.
Дополнительные ресурсы
Метод add службы VmBackups в руководстве REST API

Получение информации о резервной копии с помощью API

Можно получить информацию о резервной копии, которую можно использовать для запуска нового инкрементного резервного копирования.

Метод list службы VmBackups возвращает следующую информацию о резервной копии:

идентификатор каждого диска, с которого была снята резервная копия
идентификаторы начальной и конечной контрольных точек резервного копирования
идентификатор образа диска в резервной копии, для каждого диска, включенного в процесс резервного копирования
статус резервной копии
дату создания резервной копии

Когда параметр <status> имеет значение ready (готова), ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id), который следует использовать в качестве идентификатора начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании, и можно начать загрузку дисков, чтобы выполнить резервное копирование хранилища виртуальной машины.

Порядок действий:

Чтобы получить информацию о резервной копии с идентификатором 456 виртуальной машины с идентификатором 123, отправьте запрос следующего вида:
GET /ovirt-engine/api/vms/456/backups/123
Ответ включает в себя резервную копию с идентификатором 456 с идентификатором начальной контрольной точки (from_checkpoint_id) 999 и идентификатором конечной контрольной точки (to_checkpoint_id) 666. Диски, включенные в резервную копию, указаны в элементе <link>.
<backup id="456"> <from_checkpoint_id>999</from_checkpoint_id> <to_checkpoint_id>666</to_checkpoint_id> <link href="/ovirt-engine/api/vms/456/backups/123/disks" rel="disks"/> <status>ready</status> <creation_date> </backup>
Дополнительные ресурсы
Метод list службы VmBackups в руководстве REST API

Получение информации о дисках в резервной копии

Можно получить информацию о дисках, которые входят в состав резервной копии, включая режим резервного копирования, который использовался для каждого диска в резервной копии, что помогает определить режим, используемый для загрузки резервной копии.

Метод list службы VmBackupDisks возвращает следующую информацию о резервной копии:

Идентификатор и имя каждого диска, с которого была снята резервная копия.
Идентификатор образа диска в резервной копии, для каждого диска, включенного в процесс резервного копирования
Формат диска.
Режим резервного копирования, поддерживаемый диском.
Тип резервного копирования, использованный для диска (полное/инкрементное).

Порядок действий:

Чтобы получить информацию о резервной копии с идентификатором 456 виртуальной машины с идентификатором 123, отправьте запрос следующего вида:

GET /ovirt-engine/api/vms/456/backups/123/disks

Ответ включает в себя диск с идентификатором 789, а идентификатор образа диска – 555.

<disks>
    <disk id="789">
        <name>vm1_Disk1</name>
        <actual_size>671744</actual_size>
        <backup>incremental</backup>
        <backup_mode>full</backup_mode>
        <format>cow</format>
        <image_id>555</image_id>
        <qcow_version>qcow2_v3</qcow_version>
        <status>locked</status>
        <storage_type>image</storage_type>
        <total_size>0</total_size>
    </disk>
</disks>

Дополнительные ресурсы

Метод list службы VmBackupDisks в руководстве REST API

Завершение резервного копирования

При завершении резервного копирования оканчивается процесс резервного копирования, разблокируются ресурсы и производится очистка. Используйте служебный метод резервного копирования finalize

Порядок действий:

Чтобы завершить резервное копирование диска с идентификатором 456 на виртуальной машине с идентификатором 123, отправьте запрос следующего вида:
```
POST /vms/123/backups/456/finalize
```
Дополнительные ресурсы
finalize POST в руководстве REST API.

Создание объекта imagetransfer для инкрементного резервного копирования

Когда резервная копия готова к загрузке, приложение резервного копирования должно создать объект imagetransfer, который инициирует перенос инкрементной резервной копии.

Создание объекта imagetransfer требует вызова запроса с телом.

Порядок действий:

Отправьте запрос следующего вида:
```
POST /ovirt-engine/api/imagetransfers
```
В теле запроса укажите следующие параметры:
- идентификатор диска (disk id)
- идентификатор резервной копии (backup id)
- направление передачи для диска должно быть установлено в значение download
- формат для диска установлен в значение raw
Например, чтобы перенести резервную копию диска с идентификатором диска 123 и идентификатором резервной копии 456, отправьте следующее тело запроса:
<image_transfer> <disk id="123"/> <backup id="456"/> <direction>download</direction> <format>raw</format> </image_transfer>
Дополнительные ресурсы
Метод add для создания объекта imagetransfer в руководстве REST API.

Создание объекта imagetransfer для инкрементного восстановления

Чтобы включить восстановление неформатированных (raw) данных из резервной копии с помощью API инкрементного резервного копирования на диск формата QCOW2, приложение резервного копирования должно создать объект imagetransfer.

Если формат переноса – raw, а формат базового диска – QCOW2, то выгружаемые данные на лету преобразуются в формат QCOW2 во время записи в хранилище. Выгрузка данных с диска QCOW2 на диск RAW не поддерживается.

Создание объекта imagetransfer требует вызова запроса с телом.

Порядок действий:

Отправьте запрос следующего вида:
```
POST /ovirt-engine/api/imagetransfers
```
В теле запроса укажите следующие параметры:
- идентификатор диска или идентификатор снимка
- направление передачи для диска должно быть установлено в значение upload
- формат для диска установлен в значение raw
Например, чтобы перенести резервную копию диска с идентификатором диска 123, отправьте следующее тело запроса:
<image_transfer> <disk id="123"/> <direction>upload</direction> <format>raw</format> </image_transfer>
Дополнительные ресурсы
Метод add для создания объекта imagetransfer в руководстве REST API.

Составление списка контрольных точек для виртуальной машины

Отправив запрос, можно получить список всех контрольных точек для виртуальной машины вместе с информацией о каждой контрольной точке.

Порядок действий:

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 123 следующим образом:
GET /vms/123/checkpoints/
Ответ включает в себя все контрольные точки виртуальной машины. Каждая контрольная точка содержит следующую информацию:
- Диски контрольной точки
- Идентификатор родительской контрольной точки
- Дата создания контрольной точки
- Виртуальная машина, к которой она относится
Например:
<parent_id>, <creation_date> and the virtual machine it belongs to <vm>: <checkpoints> <checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint> </checkpoints>
Дополнительные ресурсы
метод list для перечисления контрольных точек виртуальной машины в руководстве REST API.

Выдача информации о конкретной контрольной точке виртуальной машины

Можно получить информацию о конкретной контрольной точке виртуальной машины, отправив запрос.

Порядок действий:

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 123 и идентификатором контрольной точки 456 как показано ниже:
GET /vms/123/checkpoints/456
В ответе будет дана следующая информация о контрольной точке:
- Диски контрольной точки
- Идентификатор родительской контрольной точки
- Дата создания контрольной точки
- Виртуальная машина, к которой она относится
Например:
<checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint>
Дополнительные ресурсы
метод list для перечисления контрольных точек виртуальной машины в руководстве REST API.

Удаление контрольной точки

Можно удалить контрольную точку виртуальной машины, отправив запрос DELETE. Можно удалить контрольную точку виртуальной машины, независимо от того, работает ли ВМ или нет.

Порядок действий:

Отправьте запрос с указанием виртуальной машины и контрольной точки. Например, укажите виртуальную машину с идентификатором 123 и контрольную точку с идентификатором 456 как показано ниже:
```
DELETE /vms/123/checkpoints/456/
```
Дополнительные ресурсы
метод remove службы VmCheckpoint в руководстве REST API.

Использование API imageio для передачи данных резервного копирования

API imagetransfer запускает и останавливает передачу образов. В результате появится URL-адрес передачи.

Используйте API imageio для фактической передачи данных из URL-адреса передачи.

Таблица 73. Методы API imageio Image, используемые при инкрементном резервном копировании и восстановлении
Запрос API (API request)	Описание
`OPTIONS /images/{ticket-id} HTTP/1.1`	Выводит параметры сервера, чтобы можно было узнать, какие функции поддерживает сервер.
`GET /images/{ticket-id}/extents`	Выводит информацию о содержимом и выделении образа диска или о блоках, которые изменились во время инкрементного резервного копирования. Эта информация называется экстент (extent).
`GET /images/{ticket-id}/extent?context=dirty`	Программа, выполняющая передачу образа, должна загрузить изменения из резервной копии. Эти изменения называются ожидающие записи экстенты (dirty extents).
`PUT /images/{ticket-id}`	Приложение резервного копирования создает новый диск или снимок существующего диска для хранения восстановленных данных.

3.3. Автоматизация задач конфигурирования с помощью 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.4. Пользователи и роли

3.4.1. Общая информация о пользователях

В zVirt есть два типа пользовательских доменов: локальный и внешний. При установке Менеджера управления создаются локальный домен по умолчанию, называемый внутренним (internal) доменом, и пользователь по умолчанию – admin.

Во внутреннем (internal) домене можно создавать дополнительных пользователей с помощью программы ovirt-aaa-jdbc-tool. Учетные записи пользователей, созданные в локальных доменах, называются локальными пользователями. Кроме того, к среде zVirt можно подключить внешние серверы каталогов, такие как Red Hat Directory Server, Active Directory, OpenLDAP и другие поддерживаемые варианты, и использовать их в качестве внешних доменов. Учетные записи пользователей, созданные во внешних доменах, называются пользователями из каталогов.

И локальным пользователям, и пользователям из каталогов нужно назначить соответствующие роли и разрешения через Портал администрирования, прежде чем они смогут работать в среде. Есть два основных типа ролей пользователей: пользователь и администратор. Роль пользователя использует виртуальные ресурсы с Пользовательского портала и управляет ими. Роль администратора поддерживает инфраструктуру системы с помощью Портала администрирования. Роли могут назначаться пользователям применительно к отдельным ресурсам, таким как виртуальные машины и хосты, или применительно к иерархическим структурам объектов, таким как кластеры и центры данных.

3.4.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

Невозможно установить Менеджер управления и IdM (ipa-server) на одну систему. IdM несовместим с пакетом mod_ssl, который необходим Менеджеру управления.

Если в качестве сервера каталогов используется Active Directory и для создания шаблонов и виртуальных машин нужно использовать sysprep, то управление доменом необходимо делегировать пользователю c правами администратора zVirt, чтобы тот мог:

Подключить компьютер к домену
Изменить членство группы

3.4.3. Настройка внешнего провайдера LDAP

3.4.3.1. Настройка внешнего провайдера LDAP (интерактивная установка)

Расширение ovirt-engine-extension-aaa-ldap позволяет пользователям легко настраивать внешний каталог. Расширение ovirt-engine-extension-aaa-ldap поддерживает множество различных типов серверов LDAP, а для помощи в настройке большинства типов LDAP предоставляется интерактивный скрипт установки.

Если тип сервера LDAP не указан в интерактивном скрипте установки или нужна дополнительная настройка, можно вручную отредактировать файлы конфигурации. Дополнительную информацию см. в разделе Настройка внешнего провайдера LDAP (ручной метод).

Пример для Active Directory см. в инструкции Использование Active Directory в качестве внешней службы каталогов.

Предварительные условия:

Нужно знать доменное имя DNS- или LDAP-сервера.
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM.
Подготовьте хотя бы одну учетную запись (имя и пароль) для выполнения запросов на поиск и вход на LDAP-сервер.

Порядок действий:

В Менеджере управления установите пакет расширения LDAP:
```
# dnf install ovirt-engine-extension-aaa-ldap-setup
```
Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:
```
# ovirt-engine-extension-aaa-ldap-setup
```
Выберите тип LDAP, введя соответствующий номер. Если вы не знаете точно, какая схема у вашего LDAP-сервера, выберите стандартную схему для вашего типа LDAP-сервера. Для Active Directory выполните процедуру, описанную в инструкции Использование Active Directory в качестве внешней службы каталогов.
```
Available LDAP implementations:
1 - 389ds
2 - 389ds RFC-2307 Schema
3 - Active Directory
4 - IBM Security Directory Server
5 - IBM Security Directory Server RFC-2307 Schema
6 - IPA
7 - Novell eDirectory RFC-2307 Schema
8 - OpenLDAP RFC-2307 Schema
9 - OpenLDAP Standard Schema
10 - Oracle Unified Directory RFC-2307 Schema
11 - RFC-2307 Schema (Generic)
12 - RHDS
13 - RHDS RFC-2307 Schema
14 - iPlanet
Please select:
```
Нажмите Enter, чтобы принять значение по умолчанию и настроить разрешение доменного имени для имени LDAP-сервера:
```
It is highly recommended to use DNS resolution for LDAP server.
If for some reason you intend to use hosts or plain address disable DNS usage.
Use DNS (Yes, No) [Yes]:
```
Выберите метод политики DNS:
- Вариант 1: DNS-серверы, перечисленные в /etc/resolv.conf, используются для разрешения IP-адреса. Убедитесь, что файл /etc/resolv.conf актуализирован и содержит корректные DNS-серверы.
- Вариант 2: введите FQDN или IP-адрес LDAP-сервера. Чтобы узнать доменное имя, можно использовать команду dig с записью SRV. Запись SRV имеет следующий формат:
__service._protocol_._domain_name_
Пример: dig _ldap._tcp.example.com SRV
- Вариант 3: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика предусматривает балансировку нагрузки между LDAP-серверами. Запросы распределяются между всеми LDAP-серверами по циклическому алгоритму (round-robin).
- Вариант 4: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика определяет первый LDAP-сервер как LDAP-сервер, по умолчанию отвечающий на запросы. Если первый сервер недоступен, запрос будет направлен на следующий LDAP-сервер в списке.
1 - Single server 2 - DNS domain LDAP SRV record 3 - Round-robin between multiple hosts 4 - Failover between multiple hosts Please select:

Выберите метод безопасного подключения, поддерживаемый LDAP-сервером, и укажите метод получения сертификата Центра сертификации в кодировке PEM:

File позволяет указать полный путь к сертификату.
URL позволяет указать URL-адрес для сертификата.
Inline позволяет вставить содержимое сертификата в терминал.
System позволяет указать местоположение по умолчанию для всех файлов Центра сертификации.
Insecure пропускает проверку сертификата, но соединение по-прежнему шифруется с помощью TLS.

NOTE:
It is highly recommended to use secure protocol to access the LDAP server.
Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol.
Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: _startTLS_
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure):
Please enter the password:

LDAPS расшифровывается как облегченный протокол доступа к каталогам по SSL. Для SSL-подключений выберите вариант ldaps.

Введите отличительное имя (DN) пользователя, формирующего поисковые запросы. Пользователь должен иметь разрешения для просмотра всех пользователей и групп на сервере каталогов. Пользователь, формирующий поисковый запрос, должен быть указан в аннотации LDAP. Если разрешен анонимный поиск, нажмите Enter, не вводя ничего.
```
Enter search user DN (for example uid=username,dc=example,dc=com or leave empty for anonymous): `uid=user1,ou=Users,ou=department-1,dc=example,dc=com`
Enter search user password:
```

Введите базовое отличительное имя (DN):

Please enter base DN (dc=example,dc=com) [dc=example,dc=com]: _ou=department-1,dc=example,dc=com_

Выберите Yes, если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена. Продолжайте следовать инструкциям в разделе Настройка единого входа (Single Sign-On) для виртуальных машин в руководстве по управлению виртуальными машинами.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```

Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано example.com.

Чтобы переименовать профиль после того, как домен был настроен, измените атрибут ovirt.engine.aaa.authn.profile.name в файле /etc/ovirt-engine/extensions.d/example.com-authn.properties. Перезапустите службу ovirt-engine, чтобы изменение вступило в силу.

Please specify profile name that will be visible to users: _example.com_

Рисунок 14. Страница входа на Портал администрирования

Пользователи должны выбрать профиль из выпадающего списка при первом входе в систему. Информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.

Проверьте работоспособность входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к среде zVirt. Для запроса на вход введите свои имя пользователя и пароль:

NOTE:
It is highly recommended to test drive the configuration before applying it into engine.
Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Please provide credentials to test login flow:
Enter user name:
Enter user password:
[ INFO  ] Executing login sequence...
...
[ INFO  ] Login sequence executed successfully

Убедитесь, что сведения о пользователе верны. Если они неверны, выберите Abort:

Please make sure that user details are correct and group membership meets expectations (search for PrincipalRecord and GroupRecord titles).
Abort if output is incorrect.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]:

Рекомендуется вручную проверить функцию поиска. Для поискового запроса выберите Principal для учетных записей пользователей или Группа (Group) для учетных записей групп. Наберите Yes, чтобы Разрешить группы (Resolve Groups), если нужно возвращать информацию об учетной записи группы для учетной записи пользователя. После этого будут созданы и отобразятся на экране три файла конфигурации.
```
Select test sequence to execute (Done, Abort, Login, Search) [Search]: _Search_
Select entity to search (Principal, Group) [Principal]:
Term to search, trailing '*' is allowed: _testuser1_
Resolve Groups (Yes, No) [No]:
```

Выберите Done, чтобы завершить настройку:

Select test sequence to execute (Done, Abort, Login, Search) [Abort]: _Done_
[ INFO  ] Stage: Transaction setup
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Package installation
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Transaction commit
[ INFO  ] Stage: Closing up
CONFIGURATION SUMMARY
Profile name is: example.com
The following files were created:
    /etc/ovirt-engine/aaa/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com-authn.properties
[ INFO  ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20171004101225-mmneib.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

Перезапустите службу ovirt-engine. Созданный профиль теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы назначить учетным записям пользователей на LDAP-сервере соответствующие роли и разрешения, например, для входа на Пользовательский портал, см. раздел Администрирование пользовательских задач с Портала администрирования.
```
# systemctl restart ovirt-engine.service
```

Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь: /usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

3.4.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.4.3.3. Настройка внешнего провайдера LDAP (ручной метод)

Полностью настраиваемое расширение ovirt-engine-extension-aaa-ldap использует протокол LDAP для доступа к серверам каталогов. Аутентификация Kerberos не требуется, если только вы не хотите включить единый вход на Пользовательский портал или Портал администрирования.

Если интерактивный метод настройки, описанный в предыдущем разделе, не подходит для вашего варианта использования, можно вручную изменить файлы конфигурации, чтобы подключить свой LDAP-сервер. В следующей процедуре используются типовые данные. Конкретные значения зависят от специфики настройки.

Порядок действий:

В Менеджере управления установите пакет расширения LDAP:
```
# dnf install ovirt-engine-extension-aaa-ldap
```
Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для активных каталогов (ad) и других типов каталогов (simple). В этом примере используется простой шаблон конфигурации.
```
# cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. /etc/ovirt-engine
```
Переименуйте файлы конфигурации, чтобы они соотносились с именем профиля, который нужно сделать видимым для пользователей на страницах входа на Портал администрирования и Пользовательский портал:
```
# mv /etc/ovirt-engine/aaa/profile1.properties /etc/ovirt-engine/aaa/_example_.properties
# mv /etc/ovirt-engine/extensions.d/profile1-authn.properties /etc/ovirt-engine/extensions.d/_example_-authn.properties
# mv /etc/ovirt-engine/extensions.d/profile1-authz.properties /etc/ovirt-engine/extensions.d/_example_-authz.properties
```

Измените файл конфигурации свойств LDAP, раскомментировав тип LDAP-сервера и обновив поля домена и паролей:

#  vi /etc/ovirt-engine/aaa/_example_.properties

Пример 35. Пример профиля: раздел 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-сервером.

Пример 36. Пример профиля: раздел хранилища ключей

# Create keystore, import certificate chain and uncomment
# if using tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = _/full/path/to/myrootca.jks_
pool.default.ssl.truststore.password = _password_

Просмотрите конфигурационный файл аутентификации. Имя профиля, видимое для пользователей на страницах входа на Портал администрирования и Пользовательский портал, определяется посредством ovirt.engine.aaa.authn.profile.name. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.
# vi /etc/ovirt-engine/extensions.d/_example_-authn.properties
Пример 37. Пример конфигурационного файла аутентификации
ovirt.engine.extension.name = _example_-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = _example_ ovirt.engine.aaa.authn.authz.plugin = _example_-authz config.profile.file.1 = ../aaa/_example_.properties

Просмотрите конфигурационный файл авторизации. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.

# vi /etc/ovirt-engine/extensions.d/_example_-authz.properties

Пример 38. Пример конфигурационного файла авторизации

ovirt.engine.extension.name = _example_-authz
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = ../aaa/_example_.properties

Убедитесь, что для профиля конфигурации заданы соответствующие владелец и разрешения:
```
# chown ovirt:ovirt /etc/ovirt-engine/aaa/_example_.properties
# chmod 600 /etc/ovirt-engine/aaa/_example_.properties
```
Перезапустите службу engine:
```
# systemctl restart ovirt-engine.service
```
Созданный профиль example теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы предоставить учетным записям пользователей на LDAP-сервере соответствующие разрешения, например, для входа на Пользовательский портал, см. раздел Администрирование пользовательских задач с Портала администрирования.

3.4.3.4. Удаление внешнего провайдера LDAP

В этой процедуре показано, как удалить настроенного внешнего провайдера LDAP и его пользователей.

Порядок действий:

Удалите файлы конфигурации провайдера LDAP, заменив имя по умолчанию profile1:

# rm /etc/ovirt-engine/extensions.d/_profile1_-authn.properties
# rm /etc/ovirt-engine/extensions.d/_profile1_-authz.properties
# rm /etc/ovirt-engine/aaa/_profile1_.properties

Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine
```
На Портале администрирования перейдите в Управление (Administration) Пользователи (Users) выберите пользователей этого провайдера (тех, чьим Провайдером авторизации (Authorization provider) является profile1-authz) и нажмите Удалить (Remove).

3.4.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.4.5. Авторизация пользователя

3.4.5.1. Модель авторизации пользователей

zVirt использует средства управления авторизацией, основанные на сочетании трех компонентов:

Пользователь, выполняющий действие;
Тип выполняемого действия;
Объект, над которым выполняется действие.

3.4.5.2. Действия пользователей

Для успешного выполнения действия пользователь должен иметь соответствующее разрешение в отношении объекта, над которым он собирается произвести действие. Каждый тип действия имеет соответствующее разрешение.

Некоторые действия выполняются над несколькими объектами. К примеру, копирование шаблона в другой домен хранения затронет как шаблон, так и домен хранения, являющийся приемником. Пользователь, выполняющий действие, должен иметь соответствующие разрешения в отношении всех объектов, которые затрагивает действие.

3.4.6. Администрирование пользовательских задач с Портала администрирования

3.4.6.1. Создание пользователей

Прежде чем добавить пользователей и назначить им роли и разрешения, таких пользователей нужно создать. Для подключения пользователей из внешнего провайдера, воспользуйтесь процедурой, описанной в разделе Настройка внешнего провайдера LDAP. Для создания локального пользователя воспользуйтесь процедурой, описанной в разделе Создание нового пользователя или выполните следующие действия на портале администрирования:

Порядок действий:

В боковой панели нажмите Управление (Administration) Пользователи (Users).
Нажмите Создать (Create new)

В окне Создание локального пользователя (Create Internal User) введите следующие данные:

Имя пользователя (User Name)
В выпадающем меню Роли пользователя (User Roles) выберите роль/роли пользователя
Имя (First Name)
Фамилию (Last Name)
E-mail

Пароль (Password)

По умолчанию политика паролей для учетных записей пользователей на внутреннем домене имеет следующие ограничения:

Минимум 6 знаков.
При изменении пароля нельзя снова использовать три предыдущих пароля.
Пароль не должен содержать следующие специальные символы ! ? " ' , + < > [ ] { } | \ / ~ : ; `

Для получения дополнительной информации о политике паролей и других настройках по умолчанию выполните ovirt-aaa-jdbc-tool settings show.

Нажмите Сохранить (Save)

3.4.6.2. Назначение разрешений Пользовательского портала

Роли и разрешения, назначенные во время этой процедуры, позволяют пользователю авторизоваться на Пользовательском портале и начать создавать виртуальные машины. Процедура применяется к учетным записям групп.

Порядок действий:

В боковой панели нажмите Управление (Administration) Настройка (Configure). Откроется окно Настройка (Configure).
Нажмите Системные разрешения (System Permissions).
Нажмите Добавить (Add). Откроется окно Добавить системное разрешение (Add System Permission to User).
Выберите профиль в разделе Поиск (Search). Профиль – это домен, в котором вы хотите искать. Введите имя или часть имени в текстовое поле и нажмите Поиск (GO). Либо нажмите Поиск (GO), чтобы просмотреть список всех пользователей и групп.
Установите нужные флажки, чтобы выбрать необходимых пользователей и группы.
Выберите соответствующую роль для назначения в разделе Роль для связи (Role to Assign). Роль UserRole предоставляет учетной записи пользователя разрешение авторизоваться на Пользовательском портале.
Нажмите OK.

Авторизуйтесь на Пользовательском портале, чтобы убедиться, что у учетной записи пользователя есть разрешения на авторизацию.

3.4.6.3. Просмотр информации о пользователях

Порядок действий:

В боковой панели нажмите Управление (Administration) Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Нажмите имя пользователя. Откроется подробное представление, при этом на вкладке Общее (General) обычно отображается общая информация, такая как имя домена, адрес электронной почты и статус пользователя.
Другие вкладки позволяют просматривать информацию о группах, разрешениях, квотах и событиях для соответствующего пользователя.

Например, для просмотра групп, которым принадлежит пользователь, откройте вкладку Группы каталогов (Directory Groups).

3.4.6.4. Просмотр пользовательских разрешений в отношении ресурсов

Пользователям можно назначать разрешения на определенные ресурсы или иерархически структурированные группы ресурсов. По каждому ресурсу можно просматривать списки назначенных пользователей и их разрешения.

Порядок действий:

Найдите и нажмите на имя ресурса. Откроется подробное представление.
Откройте вкладку Разрешения (Permissions), чтобы вывести список назначенных пользователей с информацией о роли каждого из них и унаследованных разрешениях для выбранного ресурса.

3.4.6.5. Удаление пользователей

Если учетная запись пользователя больше не нужна, удалите ее из zVirt.

Порядок действий:

В боковой панели нажмите Управление (Administration) Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Выберите пользователя для удаления. Убедитесь в том, что у него не запущена какая-либо виртуальная машина.
Нажмите Удалить (Remove), затем нажмите OK.

Пользователь удаляется из zVirt, но не из внешнего каталога.

3.4.6.6. Управление сессиями

Просмотр авторизованных пользователей

Можно просматривать пользователей, которые находятся в системе в настоящий момент, а также время сеанса и другую информацию. Нажмите Управление (Administration) Активные сессии пользователя (Active User Sessions), чтобы просмотреть Код сессии БД (Session DB ID), Имя пользователя (User Name), Провайдера авторизации (Authorization provider), Идентификатор пользователя (User id), IP-адрес (Source IP), Время начала сессии (Session Start Time) и Время последней активности сессии (Session Last Active Time) для каждого авторизованного пользователя.

Завершение активной сессии пользователя

Можно завершить сеанс пользователя, который в данный момент находится в системе.

Порядок действий:

Нажмите Управление (Administration) Активные сессии пользователя (Active User Sessions).
Выберите сеанс пользователя, который нужно завершить.
Нажмите Завершить сессию (Terminate Session).
Нажмите OK.

Настройка ограничений сессии

В zVirt доступна настройка максимального количества и длительности сессий пользователя.

Порядок действий:

Нажмите Управление (Administration) Пользователи (Users).
Выберите нужного пользователя.
Нажмите Управление сессиями (Manage Sessions).
В окне Управление ограничениями пользователя (User configuration) укажите необходимые параметры:
- Количество сессий (Session number limit): указывает максимальное количество одновременно активных сессий. По умолчанию для admin - не ограничено (0), для остальных пользователей - 1.
- Время сессий (Session lifetime): указывает максимальную продолжительность сессии пользователя в минутах. По умолчанию для admin - не ограничено (0), для остальных пользователей - 60 минут.
Нажмите Сохранить (Save).

3.4.7. Администрирование пользовательских задач через командную строку

Для управления учетными записями пользователей на внутреннем домене можно использовать инструмент ovirt-aaa-jdbc-tool. Изменения, вносимые с помощью этого инструмента, сразу вступают в силу без необходимости перезагрузки службы ovirt-engine. Для просмотра полного списка параметров для пользователей выполните ovirt-aaa-jdbc-tool user --help.

Типичные примеры представлены в настоящем разделе.

Требуется авторизация на машине с Менеджером управления.

3.4.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.4.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-provider-ovn. В противном случае пользователь с правами администратора будет заблокирован, так как Менеджер управления продолжит использовать старый пароль для синхронизации сетей из ovirt-provider-ovn. Чтобы распространить новый пароль на ovirt-provider-ovn, сделайте следующее:

На Портале администрирования нажмите Управление (Administration) Провайдеры (Providers).
Выберите ovirt-provider-ovn.
Нажмите Изменить (Edit) и введите новый пароль в поле Пароль (Password).
Нажмите Тестировать (Test), чтобы проверить, проходит ли успешно аутентификация с предоставленными учетными данными.
После успешной проверки аутентификации нажмите ОК.

3.4.7.3. Настройка допустимого периода неактивности пользователя

Можно настроить допустимый период неактивности пользователя:

# engine-config --set UserSessionTimeOutInterval=_integer_

3.4.7.4. Предварительное шифрование пароля пользователя

Можно создать предварительно зашифрованный пароль пользователя, используя скрипт ovirt-engine-crypto-tool. Эта опция полезна при добавлении пользователей и паролей в базу данных с помощью скрипта.

Пароли хранятся в базе данных Менеджера управления в зашифрованном виде. Скрипт ovirt-engine-crypto-tool используется, так как все пароли должны быть зашифрованы одним и тем же алгоритмом.

Если пароль предварительно зашифрован, то невозможно выполнить проверку действительности пароля. Пароль будет принят, даже если он не соответствует требованиям политики проверки паролей.

Выполните следующую команду:
# /usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode
Скрипт запросит ввод пароля.

Либо с помощью параметра --password=file:file можно зашифровать один пароль, который отображается как первая строка файла. Такой параметр полезен при автоматизации. В следующем примере file - это текстовый файл, содержащий один пароль для шифрования:
# /usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode --password=file:__file__
Установите новый пароль с помощью скрипта ovirt-aaa-jdbc-tool, используя параметр --encrypted:
```
# ovirt-aaa-jdbc-tool user password-reset __test1__ --password-valid-to="2025-08-01 12:00:00-0800" --encrypted
```
Введите и подтвердите зашифрованный пароль:
```
Password:
Reenter password:
updating user test1...
user updated successfully
```

3.4.7.5. Просмотр информации о пользователях

Можно посмотреть подробные сведения об учетной записи пользователя:

# ovirt-aaa-jdbc-tool user show test1

В результате выполнения этой команды отображается больше сведений, чем на экране Управление (Administration) Пользователи (Users) на Портале администрирования.

3.4.7.6. Изменение информации о пользователе

Информацию о пользователе (например, адрес электронной почты) можно обновить:

# ovirt-aaa-jdbc-tool user edit test1 --attribute=email=jdoe@example.com

3.4.7.7. Удаление пользователя

Учетную запись пользователя можно удалить:

# ovirt-aaa-jdbc-tool user delete test1

Удалите пользователя с Портала администрирования. Для получения дополнительной информации см. раздел Удаление пользователей.

3.4.7.8. Отключение внутреннего пользователя с правами администратора

Можно отключить пользователей на локальных доменах, в том числе пользователя admin@internal, созданного в процессе выполнения engine-setup. Убедитесь, что в среде есть хотя бы один пользователь со всеми административными разрешениями, прежде чем отключать пользователя admin по умолчанию.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Убедитесь, что в среду добавлен другой пользователь с ролью SuperUser. Более подробные сведения см. в разделaх Создание пользователей и Назначение разрешений Пользовательского портала.
Отключите пользователя admin по умолчанию:
# ovirt-aaa-jdbc-tool user edit `admin` --flag=+disabled
Чтобы подключить отключенного пользователя, выполните команду:

ovirt-aaa-jdbc-tool user edit username --flag=-disabled
==== Управление группами

С помощью инструмента ovirt-aaa-jdbc-tool можно управлять учетными записями групп во внутреннем домене. Управление учетными записями групп и пользователей происходит похожим образом. Для просмотра полного списка параметров для групп выполните ovirt-aaa-jdbc-tool group --help. Типичные примеры представлены в настоящем разделе.

Создание группы

Далее показано, как создавать учетную запись группы, добавлять пользователей в группу и просматривать подробные сведения о группе.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте новую группу:
```
# ovirt-aaa-jdbc-tool group add _group1_
```
Добавьте пользователей в группу. Пользователи должны быть уже созданы.
# ovirt-aaa-jdbc-tool group-manage useradd _group1_ --user=_test1_
Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help.
Посмотреть подробные сведения об учетной записи группы:
```
# ovirt-aaa-jdbc-tool group show _group1_
```
Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.

Создание вложенных групп

Далее показано, как создавать группы внутри групп.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте первую группу:
```
# ovirt-aaa-jdbc-tool group add _group1_
```
Создайте вторую группу:
```
# ovirt-aaa-jdbc-tool group add _group1-1_
```
Добавьте вторую группу в первую группу:
```
# ovirt-aaa-jdbc-tool group-manage groupadd _group1_ --group=_group1-1_
```
Добавьте первую группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.

3.4.7.9. Опрашивание пользователей и групп

Модуль query позволяет запрашивать информацию о пользователях и группах. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool query --help.

Вывод списка с информацией по всем учетным записям пользователей или групп

Далее показано, как вывести список с информацией по всем учетным записям.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Выведите список с информацией обо всех учетных записях.
- Данные по всем учетным записям пользователей:
  # ovirt-aaa-jdbc-tool query --what=user
- Данные по всем учетным записям групп:
  # ovirt-aaa-jdbc-tool query --what=group

Вывод списка по отфильтрованным данных учетных записей

Далее показано, как использовать фильтры при выводе списка информации по учетным записям.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Отфильтруйте данные учетной записи с помощью параметра --pattern.
- Выведите список данных учетных записей пользователей с именами, начинающимися со знака j.
  # ovirt-aaa-jdbc-tool query --what=user --pattern="name=_j*_"
- Выведите список групп, у которых указан атрибут департамента marketing:
  # ovirt-aaa-jdbc-tool query --what=group --pattern="department=_marketing_"

3.4.7.10. Управление настройками учетной записи

Чтобы изменить настройки учетной записи по умолчанию, используйте модуль ovirt-aaa-jdbc-tool settings.

Обновление настроек учетной записи

Далее показано, как обновить настройки учетной записи по умолчанию.

Порядок действий:

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Чтобы увидеть все доступные настройки, выполните команду:
```
# ovirt-aaa-jdbc-tool settings show
```

Измените необходимые настройки:

В этом примере заданная по умолчанию длительность сеанса после авторизации изменена на 60 минут для всех учетных записей пользователей. Значение по умолчанию – 10 080 минут.
```
# ovirt-aaa-jdbc-tool settings set --name=MAX_LOGIN_MINUTES --value=_60_
```
В этом примере изменено количество неудачных попыток входа в систему, которые может предпринять пользователь, прежде чем его учетная запись будет заблокирована. Значение по умолчанию - 5.
```
# ovirt-aaa-jdbc-tool settings set --name=MAX_FAILURES_SINCE_SUCCESS --value=_3_
```

Чтобы разблокировать заблокированную учетную запись пользователя, выполните команду ovirt-aaa-jdbc-tool user unlock test1.

3.4.8. Конфигурирование дополнительных локальных доменов

Помимо внутреннего (internal) домена по умолчанию, также можно создавать дополнительные локальные домены. Это можно сделать с помощью расширения ovirt-engine-extension-aaa-jdbc, чтобы создавать несколько доменов без подключения внешних серверов каталогов, хотя такой вариант использования редко встречается в корпоративных средах.

Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений zVirt и должны быть обновлены вручную при каждом новом релизе. Подробные сведения о создании дополнительных локальных доменов и о том, как обновлять домены, см. в файле README, расположенном здесь: /usr/share/doc/ovirt-engine-extension-aaa-jdbc-version/README.admin.

3.5. Квоты и политика SLA

3.5.1. Введение в квоты

Квота – это инструмент ограничения ресурсов, предоставляемый с zVirt. Квоту можно рассматривать как слой ограничений поверх слоя ограничений, установленных разрешениями пользователя.

Квота – это объект центра данных.

Квота позволяет администраторам сред zVirt ограничивать доступ пользователей к памяти, ЦП и хранилищу. Квота определяет ресурсы памяти и хранилища, которые администратор может назначить пользователям. В результате пользователи могут использовать только назначенные им ресурсы. Когда ресурсы по квоте исчерпаны, zVirt не разрешает дальнейшие действия пользователей.

Существует два вида квот:

Таблица 74. Виды квот
Тип квоты	Определение
Квота на ресурсы среды выполнения (Run-time Quota)	Эта квота ограничивает потребление ресурсов среды выполнения (например, ЦП и память).
Квота хранения (Storage Quota)	Эта квота ограничивает объем доступного хранилища.

У квоты может быть три режима:

Таблица 75. Режимы квот
Режим квотирования	Описание
Принудительный (Enforced)	В этом режиме действует квота, которая ограничивает ресурсы для группы или пользователя, на которых распространяется квота.
Аудит (Audit)	В этом режиме регистрируются нарушения квот без блокировки пользователей, и он может использоваться для проверки квот. В режиме Аудита можно увеличить или уменьшить объем квоты на ресурсы среды выполнения и объем квоты хранения, доступный пользователям, на которых распространяется квота.
Выключенный (Disabled)	Этот режим отключает ограничения на ресурсы среды выполнения и ресурсы хранения, заданные квотой.

Когда пользователь пытается запустить виртуальную машину, характеристики виртуальной машины сравниваются с допустимыми значениями выделенных ресурсов хранения и выделенных ресурсов среды выполнения, установленными в соответствующей квоте.

Если запуск виртуальной машины приводит к тому, что совокупные ресурсы всех запущенных виртуальных машин, на которые распространяется квота, превышают допустимое значение, определенное квотой, то Менеджер управления отклонит запуск виртуальной машины.

Когда пользователь создает новый диск, запрашиваемый размер диска добавляется к суммарному используемому дисковому пространству всех остальных дисков, на которые распространяется квота. Если с новым диском общее суммарно используемое дисковое пространство превысит квоту, то создать диск не получится.

Квота позволяет совместно использовать ресурсы одного оборудования. Можно использовать жесткие и мягкие пороговые значения. Администраторы могут использовать квоту для установки пороговых значений по ресурсам. Для пользователя эти пороговые значения выглядят как 100% использование определенного ресурса. Для предотвращения сбоев в случае, когда заказчик внезапно превышает пороговое значение, в интерфейсе предусмотрен объем, на который можно "без последствий" кратковременно превысить пороговое значение. При превышении пороговых значений заказчику отправляется предупреждение.

Квота накладывает ограничения на работу виртуальных машин. Если ограничения игнорировать, то есть риск, что в какой-то момент вы не сможете использовать свои виртуальные машины и виртуальные диски.

Когда действует принудительный режим квотирования, виртуальные машины и диски, которым не назначены квоты, использовать нельзя.

Чтобы можно было включить виртуальную машину, ей должна быть назначена квота.

Чтобы можно было создать снимок виртуальной машины, диску, ассоциированному с виртуальной машиной, должна быть назначена квота.

При создании шаблона из виртуальной машины будет предложено выбрать квоту, которую будет потреблять шаблон. Это позволяет установить для шаблона (и всех будущих машин, созданных на основе шаблона) квоту, отличную от квоты виртуальной машины и диска, на основе которых создан шаблон.

3.5.2. Общая квота и индивидуально установленная квота

Пользователи с разрешениями SuperUser могут создавать квоты для отдельных пользователей или квоты для групп.

Групповые квоты могут быть установлены для пользователей Active Directory. Если группе из десяти пользователей предоставлена квота в 1 ТБ хранилища, а один из десяти пользователей заполнит весь терабайт, то вся группа превысит квоту, и ни один из десяти пользователей не сможет использовать хранилище, ассоциированное с их группой.

Квота отдельного пользователя устанавливается только для него одного. Как только отдельный пользователь израсходует всю свою квоту на ресурсы среды выполнения или на ресурсы хранения, то он превысит квоту и больше не сможет использовать хранилище, ассоциированное с его квотой.

3.5.3. Учет квот

Когда потребителю или ресурсу назначена квота, каждое действие этого потребителя или ресурса, связанное с хранилищем, виртуальным ЦП или памятью, приводит к потреблению или высвобождению ресурсов, заложенных в квоту.

Поскольку квота действует как верхняя граница, ограничивающая доступ пользователя к ресурсам, расчеты квоты могут отличаться от фактического текущего использования пользователем. Квота рассчитывается для максимально возможного роста, а не для текущего использования.

Пример 39. Пример учета

Пользователь запускает виртуальную машину с 1 виртуальным ЦП и 1024 МБ памяти. Это действие потребляет 1 виртуальный ЦП и 1024 МБ из квоты, назначенной этому пользователю. После остановки виртуальной машины 1 виртуальный ЦП и 1024 МБ оперативной памяти высвобождаются и возвращаются обратно в квоту, назначенную этому пользователю. Потребление квоты на ресурсы среды выполнения учитывается только во время фактического времени работы программ потребителя.

Пользователь создает виртуальный диск объемом 10 ГБ с динамическим выделением пространства. Фактическое использование диска может показать, что на самом деле используется только 3 ГБ этого диска. Однако квота потребления составит 10 ГБ, т.е. максимальный объем этого диска с учетом возможного роста.

3.5.4. Включение и изменение режима квотирования в центре данных

Эта процедура позволяет включить или изменить режим квотирования в центре данных. Необходимо сначала выбрать режим квотирования, а потом уже задавать квоты. Чтобы выполнить эту процедуру, необходимо авторизоваться на Портале администрирования.

Используйте режим Аудит (Audit) для проверки квоты, чтобы убедиться, что она работает в соответствии с вашими ожиданиями. Чтобы создать или изменить квоту, не обязательно использовать режим Аудит (Audit).

Порядок действий:

Нажмите Ресурсы (Compute) Центры данных (Data Centers) и выберите центр данных.
Нажмите Изменить (Edit).
В выпадающем списке Режим квотирования (Quota Mode) измените режим квотирования на Принудительный (Enforced).
Нажмите OK.

Если во время проверки задать режим квотирования Аудит (Audit), то необходимо будет изменить его на Принудительный (Enforced), чтобы настройки квот вступили в силу.

3.5.5. Создание новой политики квотирования

Вы включили режим квотирования Аудит (Audit) или Принудительный (Enforcing). Теперь необходимо задать политику квотирования для управления использованием ресурсов в центре данных.

Порядок действий:

Нажмите Управление (Administration) Квота (Quota).
Нажмите Новая (Add).
Заполните поля Имя (Name) и Описание (Description).
Выберите Центр данных (Data Center).
В разделе Память и ЦП (Memory & CPU) используйте зеленый бегунок, чтобы задать Пороговое значение для кластера (Cluster Threshold).
В разделе Память и ЦП (Memory & CPU) используйте синий бегунок, чтобы задать Допустимое превышение для кластера (Cluster Grace).
Кнопкой-переключателем выберите Все кластеры (All Clusters) или Указанные кластера (Specific Clusters). Если вы выбрали Указанные кластера (Specific Clusters), то отметьте флажками кластеры, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
1. В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо Ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали Ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле MiB.
2. В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).
3. Нажмите OK в окне Изменить квоту (Edit Quota).
В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).
В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).
Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Указанные домены хранения (Specific Storage Domains). Если вы выбрали Указанные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
1. В поле Квота хранилища (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле GiB.
2. Нажмите OK в окне Изменить квоту (Edit Quota).
Нажмите OK в окне Новая квота (New Quota).

3.5.6. Описание настроек пороговых значений квоты

Таблица 76. Пороговые значения квот и допустимые превышения
Параметр	Определение
Пороговое значение для кластера	Объем ресурсов кластера, доступных каждому центру данных.
Допустимое превышение для кластера	Объем ресурсов кластера, доступный центру данных после достижения порогового значения в кластере, установленного для этого центра данных.
Пороговое значение для хранилища	Объем ресурсов хранилища, доступных каждому центру данных.
Допустимое превышение для хранилища	Объем ресурсов хранилища, доступный центру данных после достижения порогового значения хранилища, установленного для этого центра данных.

Если квота установлена на 100 ГБ с допустимым превышением в 20%, то потребителям заблокируют доступ к ресурсам хранилища после того, как они заполнят 120 ГБ хранилища. Если для той же квоты установлено Пороговое значение 70%, то потребители получат предупреждение, когда заполнят больше 70 ГБ хранилища (но при этом они смогут использовать хранилище до тех пор, пока не заполнят 120 ГБ хранилища). "Пороговое значение" и "Допустимое превышение" задаются в привязке к квоте. "Пороговое значение" можно рассматривать как "мягкое ограничение", в результате превышения которого будет выдано предупреждение. "Допустимое превышение" можно рассматривать как "жесткое ограничение", превышение которого делает невозможным дальнейшее потребление ресурсов хранилища.

3.5.7. Назначение квоты объекту

Назначение квоты виртуальной машине

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines) и выберите виртуальную машину.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую виртуальная машина будет потреблять.
Нажмите OK.

Назначение квоты диску

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Нажмите на имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks) и выберите диск, который собираетесь ассоциировать с квотой.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую диск будет потреблять.
Нажмите OK.

Чтобы виртуальная машина работала, квоту необходимо выбрать для всех объектов, ассоциированных с виртуальной машиной. Если квота для объектов, ассоциированных с виртуальной машиной, не выбрана, то виртуальная машина не будет работать. В этой ситуации Менеджер управления выдает универсальное сообщение об ошибке, поэтому будет проблематично определить, вызвана ли ошибка тем, что вы не ассоциировали квоту со всеми объектами, ассоциированными с виртуальной машиной. Невозможно сделать снимки виртуальных машин, которым не назначена квота. Невозможно создать шаблоны виртуальных машин, виртуальным дискам которых не назначены квоты.

3.5.8. Использование квоты для ограничения ресурсов, доступных пользователю

Далее показано, как использовать квоты для ограничения ресурсов, к которым пользователь имеет доступ.

Порядок действий:

Нажмите Управление (Administration) Квота (Quota).
Нажмите на имя целевой квоты. Откроется подробное представление.
Откройте вкладку Потребители (Consumers).
Нажмите Добавить (Add).
В поле Поиск (Search) введите имя пользователя, которого хотите ассоциировать с квотой.
Нажмите Поиск (GO).
Поставьте флажок рядом с именем пользователя.
Нажмите OK.

После этого пользователь появится на вкладке Потребители (Consumers) в подробном представлении.

3.5.9. Изменение квот

Далее показано, как изменять существующие квоты.

Порядок действий:

Нажмите Управление (Administration) Квота (Quota) и выберите квоту.
Нажмите Изменить (Edit).
Измените поля согласно потребностям.
Нажмите OK.

3.5.10. Удаление квот

Далее показано, как удалять квоты.

Порядок действий:

Нажмите Управление (Administration) Квота (Quota) и выберите квоту.
Нажмите Удалить (Remove).
Нажмите OK.

3.5.11. Принудительное применение политики SLA

Далее показано, как задать SLA для функций ЦП

Порядок действий:

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines).
Нажмите Создать (New) или выберите виртуальную машину и нажмите Изменить (Edit).
Откройте вкладку Выделение ресурсов (Resource Allocation).
Укажите Общие ЦП (CPU Shares). Возможные варианты: Низкий (Low), Средний (Medium), Высокий (High), Настраиваемый (Custom) и Выключено (Disabled). Виртуальные машины c настройкой Высокая (High) получают в два раза больше долей, чем с настройкой Средний (Medium), а виртуальные машины с настройкой Средний (Medium) получают в два раза больше долей, чем виртуальные машины с настройкой Низкий (Low). Настройка Выключено (Disabled) даёт VDSM указание использовать старый алгоритм для распределения долей; как правило, при таких условиях количество распределяемых долей равно 1020.

Вы настроили политику, которая теперь будет регулировать потребление ЦП пользователями.

3.6. Уведомления о событиях

3.6.1. Настройка уведомлений о событиях на Портале администрирования

Менеджер управления может отправлять уведомления определенным пользователям по электронной почте при наступлении определенных событий в среде, которой управляет Менеджер управления. Чтобы использовать эту функцию, необходимо настроить агент передачи почты для доставки сообщений. Через Портал администрирования можно настроить только уведомления по электронной почте. Ловушки SNMP должны быть настроены на машине с Менеджером управления.

Порядок действий:

Убедитесь, что у вас есть доступ к почтовому серверу, который может принимать автоматические сообщения от Менеджера управления и доставлять их по списку рассылки.
Нажмите Управление (Administration) Пользователи (Users) и выберите пользователя.
Нажмите на Имя пользователя (User Name), чтобы открыть подробное представление.
На вкладке Уведомления о событиях (Event Notifier) нажмите Управление событиями (Manage Events).
Нажмите на кнопку Развернуть все (Expand All) или специальные кнопки расширения , чтобы просмотреть события.
Поставьте необходимые флажки.

Укажите адрес электронной почты в поле Получатель почты (Mail Recipient).

Адрес электронной почты может быть указан как адрес электронной почты для текстовых сообщений (например, 1234567890@carrierdomainname.com) или как групповой адрес электронной почты.

Нажмите OK.
На машине с Менеджером управления скопируйте ovirt-engine-notifier.conf в новый файл с именем 90-email-notify.conf:
```
# cp /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf /etc/ovirt-engine/notifier/notifier.conf.d/90-email-notify.conf
```
Измените 90-email-notify.conf и удалите всё, кроме раздела EMAIL Notifications.

Введите корректные переменные электронной почты, как в примере ниже. Этот файл переопределяет значения в оригинальном файле ovirt-engine-notifier.conf.

#---------------------#
# EMAIL Notifications #
#---------------------#
# The SMTP mail server address. Required.
MAIL_SERVER=myemailserver.example.com
# The SMTP port (usually 25 for plain SMTP, 465 for SMTP with SSL, 587 for SMTP with TLS)
MAIL_PORT=25
# Required if SSL or TLS enabled to authenticate the user. Used also to specify 'from' user address if mail server
# supports, when MAIL_FROM is not set. Address is in RFC822 format
MAIL_USER=
# Required to authenticate the user if mail server requires authentication or if SSL or TLS is enabled
SENSITIVE_KEYS="${SENSITIVE_KEYS},MAIL_PASSWORD"
MAIL_PASSWORD=
# Indicates type of encryption (none, ssl or tls) should be used to communicate with mail server.
MAIL_SMTP_ENCRYPTION=none
# If set to true, sends a message in HTML format.
HTML_MESSAGE_FORMAT=false
# Specifies 'from' address on sent mail in RFC822 format, if supported by mail server.
MAIL_FROM=rhevm2017@example.com
# Specifies 'reply-to' address on sent mail in RFC822 format.
MAIL_REPLY_TO=
# Interval to send smtp messages per # of IDLE_INTERVAL
MAIL_SEND_INTERVAL=1
# Amount of times to attempt sending an email before failing.
MAIL_RETRIES=4

Дополнительные параметры см. в файле /etc/ovirt-engine/notifier/notifier.conf.d/README.

Включите и перезапустите сервис ovirt-engine-notifier, чтобы внесенные изменения вступили в силу:
```
# systemctl daemon-reload
# systemctl enable ovirt-engine-notifier.service
# systemctl restart ovirt-engine-notifier.service
```

Теперь указанный пользователь будет получать сообщения по электронной почте о событиях в среде zVirt. Выбранные события отображаются для этого пользователя на вкладке Уведомления о событиях (Event Notifier).

3.6.2. Отмена уведомлений о событиях на Портале администрирования

Если пользователь настроил ряд ненужных уведомлений по электронной почте и хочет их отменить, выполните описанную ниже процедуру.

Порядок действий:

Нажмите Управление (Administration) Пользователи (Users).
Нажмите на Имя пользователя (User Name). Откроется подробное представление.
Откройте вкладку Уведомления о событиях (Event Notifier), чтобы увидеть список событий, о которых пользователь получает уведомления по электронной почте.
Нажмите Управление событиями (Manage Events).
Нажмите кнопку Развернуть все (Expand All) или специальные кнопки расширения , чтобы просмотреть события.
Снимите необходимые флажки, чтобы удалить уведомления для этого события.
Нажмите OK.

3.6.3. Параметры уведомлений о событиях в ovirt-engine-notifier.conf

Файл конфигурации службы уведомлений о событиях находится в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf.

Имя переменной Default (По умолчанию) Примечания

SENSITIVE_KEYS

Нет

Разделенный запятыми список ключей, которые не будут регистрироваться.

JBOSS_HOME

/opt/rh/eap7/root/usr/share/wildfly

Местонахождение сервера приложений JBoss, используемого Менеджером управления.

ENGINE_ETC

/etc/ovirt-engine

Местонахождение каталога etc, используемого Менеджером управления.

ENGINE_LOG

/var/log/ovirt-engine

Местонахождение каталога logs, используемого Менеджером управления.

ENGINE_USR

/usr/share/ovirt-engine

Местонахождение каталога usr, используемого Менеджером управления.

ENGINE_JAVA_MODULEPATH

${ENGINE_USR}/modules

Полный путь для подсоединения модулей JBoss.

NOTIFIER_DEBUG_ADDRESS

Нет

Адрес машины, которую можно использовать для удаленной отладки виртуальной машины Java, используемой службой уведомлений.

NOTIFIER_STOP_TIME

Время (в секундах), после которого истечет время ожидания службы.

NOTIFIER_STOP_INTERVAL

Время (в секундах), на которое увеличивается значение счетчика времени ожидания.

INTERVAL_IN_SECONDS

120

Интервал (в секундах) между ситуациями отправки сообщений подписчикам.

IDLE_INTERVAL

Интервал (в секундах), в который будут выполняться задачи с низким приоритетом.

DAYS_TO_KEEP_HISTORY

Эта переменная задает количество дней, в течение которых отправленные события будут сохраняться в таблице истории. Если эта переменная не задана, события остаются в таблице истории в течение неограниченно долгого времени.

FAILED_QUERIES_NOTIFICATION_THRESHOLD

Количество неудачных запросов, после которого отправляется уведомление по электронной почте. Уведомление по электронной почте отправляется после первой неудачной попытки доставки уведомлений, а затем каждый раз, когда достигается количество неудачных попыток, указанное этой переменной. Если указать значение 0 или 1, сообщение по электронной почте будет отсылаться при каждой неудачной попытке.

FAILED_QUERIES_NOTIFICATION_RECIPIENTS

Нет

Адреса электронной почты получателей, которым будут отправляться уведомления. Адреса электронной почты должны быть разделены запятыми. Этот параметр стал устаревшим после введения переменной FILTER.

DAYS_TO_SEND_ON_STARTUP

Давность (в днях) старых событий, которые будут обработаны и отправлены при запуске службы уведомлений.

FILTER

exclude:*

Алгоритм, используемый для определения триггеров и получателей уведомлений по электронной почте. Значение этой переменной представляет собой комбинацию операторов включить (include) или исключить (exclude), события и получателя. Например, include:VDC_START(smtp:mail@example.com) ${FILTER}

MAIL_SERVER

Нет

Адрес почтового сервера SMTP. Обязательный параметр.

MAIL_PORT

Порт, используемый для связи. Возможные значения: 25 для простого SMTP, 465 для SMTP с SSL и 587 для SMTP с TLS.

MAIL_USER

Нет

Если для аутентификации пользователя включен SSL, то эту переменную нужно задать. Эта переменная также используется для указания адреса пользователя-отправителя, когда переменная MAIL_FROM не задана. Некоторые почтовые серверы не поддерживают эту функцию. Адрес имеет формат RFC822.

SENSITIVE_KEYS

${SENSITIVE_KEYS},MAIL_PASSWORD

Требуется для аутентификации пользователя, если почтовый сервер требует аутентификации или если SSL или TLS включены.

MAIL_PASSWORD

Нет

MAIL_SMTP_ENCRYPTION

Нет

Тип шифрования, который должен использоваться для связи. Возможные значения: none, ssl и tls.

HTML_MESSAGE_FORMAT

false

Почтовый сервер отправляет сообщения в формате HTML, если эта переменная установлена в значение true.

MAIL_FROM

Нет

Эта переменная указывает адрес отправителя в формате RFC822, если он поддерживается почтовым сервером.

MAIL_REPLY_TO

Нет

Эта переменная указывает адреса получателя в формате RFC822 для отправляемых писем, если это поддерживается почтовым сервером.

MAIL_SEND_INTERVAL

Число SMTP-сообщений, которые должны отправляться в каждый IDLE_INTERVAL

MAIL_RETRIES

Количество попыток отправить электронное сообщение, пока не будет признан факт неудачи.

SNMP_MANAGERS

Нет

IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, manager1.example.com manager2.example.com:164

SNMP_COMMUNITY

public

(только SNMP версии 2) SNMP Community.

SNMP_OID

1.3.6.1.4.1.2312.13.1.1

Идентификаторы объектов-ловушек по умолчанию для оповещений. Когда этот OID определен, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления.

SNMP_VERSION

Определяет, какую версию SNMP следует использовать. Поддерживаются ловушки SNMP версий 2 и 3. Возможные значения: 2 или 3.

SNMP_ENGINE_ID

Нет

(SNMPv3) Идентификатор Менеджера управления, используемый для ловушек SNMPv3. Это уникальный идентификатор устройства, подключенного через SNMP.

SNMP_USERNAME

Нет

(SNMPv3) Имя пользователя, используемое для ловушек SNMPv3.

SNMP_AUTH_PROTOCOL

Нет

(SNMPv3) Протокол авторизации SNMPv3. Возможные значения: MD5, SHA

SNMP_AUTH_PASSPHRASE

Нет

(SNMPv3) Парольная фраза, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH_NOPRIV и AUTH_PRIV.

SNMP_PRIVACY_PROTOCOL

Нет

(SNMPv3) Протокол обеспечения конфиденциальности SNMPv3. Возможные значения: AES128, AES192, AES256

Протоколы AES192 и AES256 не определены в RFC3826, поэтому перед их включением убедитесь, что ваш SNMP-сервер поддерживает их.

SNMP_PRIVACY_PASSPHRASE

Нет

Парольная фраза обеспечения конфиденциальности SNMPv3, используемая, когда для SNMP_SECURITY_LEVEL задано значение AUTH_PRIV.

SNMP_SECURITY_LEVEL

(SNMPv3) Уровень безопасности SNMPv3. Возможные значения:

1 - NOAUTH_NOPRIV
2 - AUTH_NOPRIV
3 - AUTH_PRIV

ENGINE_INTERVAL_IN_SECONDS

300

Интервал (в секундах) между операциями мониторинга машины, на которой установлен Менеджер управления. Этот интервал измеряется с момента завершения мониторинга.

ENGINE_MONITOR_RETRIES

Количество предпринимаемых службой уведомлений попыток проверить статус машины, на которой установлен Менеджер управления, в заданном интервале после неудачи.

ENGINE_TIMEOUT_IN_SECONDS

Время (в секундах), которое необходимо выждать, прежде чем служба уведомлений предпримет попытку проверить статус машины, на которой установлен Менеджер управления, в заданном интервале после неудачи.

IS_HTTPS_PROTOCOL

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в безопасном режиме.

SSL_PROTOCOL

TLS

Протокол, используемый коннектором конфигурации JBoss, когда включен SSL.

SSL_IGNORE_CERTIFICATE_ERRORS

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в защищенном режиме и ошибки SSL должны игнорироваться.

SSL_IGNORE_HOST_VERIFICATION

false

Этот параметр должен быть установлен в значение true, если JBoss запускается в защищенном режиме и верификация имени хоста должна игнорироваться.

REPEAT_NON_RESPONSIVE_NOTIFICATION

false

Эта переменная указывает, будут ли подписчикам отправляться повторные сообщения о неудачных попытках, если машина, на которой установлен Менеджер управления, не отвечает.

ENGINE_PID

/var/lib/ovirt-engine/ovirt-engine.pid

Путь и имя PID-файла Менеджера управления.

3.6.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\> – это число, указывающее приоритет, с которым должен выполняться этот файл.

Порядок действий:

В Менеджере управления создайте файл конфигурации SNMP с именем \<integer\>-snmp.conf, где \<integer\> – это целое число, указывающее порядок обработки файлов. Например:

# vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

Укажите менеджера(ов) SNMP, SNMP Community (только для SNMP версии 2) и OID в формате, приведенном в этом примере:
```
SNMP_MANAGERS="_manager1.example.com_ _manager2.example.com:162_"
SNMP_COMMUNITY=public
SNMP_OID=1.3.6.1.4.1.2312.13.1.1
```
Укажите, какую версию SNMP следует использовать: 2 (по умолчанию) или 3:
```
SNMP_VERSION=3
```
Укажите значение для SNMP_ENGINE_ID. Например:
```
SNMP_ENGINE_ID="80:00:00:00:01:02:05:05"
```
В случае SNMP версии 3 укажите уровень безопасности для ловушек SNMP:
- Уровень безопасности 1, ловушки NoAuthNoPriv:
  SNMP_USERNAME=NoAuthNoPriv SNMP_SECURITY_LEVEL=1
- Уровень безопасности 2, ловушки AuthNoPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass.
  SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5 SNMP_AUTH_PASSPHRASE=authpass SNMP_SECURITY_LEVEL=2
- Уровень безопасности 3, ловушки AuthPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass и парольная фраза для обеспечения конфиденциальности по SNMP privpass. Например:
  SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5 SNMP_AUTH_PASSPHRASE=authpass SNMP_PRIVACY_PROTOCOL=AES128 SNMP_PRIVACY_PASSPHRASE=privpass SNMP_SECURITY_LEVEL=3
Определите, какие события следует отправлять менеджеру SNMP:
Примеры
Пример 40. Отправлять все события на SNMP-профиль, заданный по умолчанию
FILTER="include:*(snmp:) ${FILTER}"
Пример 41. Отправлять все события со степенью серьезности ОШИБКА (ERROR) или ОПОВЕЩЕНИЕ (ALERT) на SNMP-профиль, заданный по умолчанию
FILTER="include:*:ERROR(snmp:) ${FILTER}" FILTER="include:*:ALERT(snmp:) ${FILTER}"
Пример 42. Отправлять события для VDC_START на указанный адрес электронной почты
FILTER="include:__VDC_START__(snmp:__mail@example.com__) ${FILTER}"
Пример 43. Отправлять события для всего, кроме VDC_START, на SNMP-профиль, заданный по умолчанию
FILTER="exclude:__VDC_START__ include:*(snmp:) ${FILTER}"

Это фильтр по умолчанию, определенный в ovirt-engine-notifier.conf; если не выключить этот фильтр или не применить переопределяющие его фильтры, то никакие уведомления не будут отсылаться:

FILTER="exclude:*"
VDC_START – это пример сообщений журнала аудита. Полный список сообщений журнала аудита содержится в /usr/share/doc/ovirt-engine/AuditLogMessages.properties. Либо отфильтруйте результаты в менеджере SNMP.
Сохраните файл.
Запустите службу ovirt-engine-notifier и убедитесь, что она запускается при загрузке:
```
# systemctl start ovirt-engine-notifier.service
# systemctl enable ovirt-engine-notifier.service
```

Проверьте менеджер SNMP, чтобы убедиться в получении ловушек.

Для работы службы уведомлений нужно, чтобы SNMP_MANAGERS, MAIL_SERVER или оба параметра были должным образом определены в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf либо в переопределяющем файле.

Пример 44. Пример файла конфигурации 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.

3.7. Утилиты

3.7.1. Инструмент переименования oVirt Engine Rename

3.7.1.1. Инструмент переименования oVirt Engine Rename

Когда команда engine-setup выполняется в чистой среде, она генерирует ряд сертификатов и ключей, которые используют FQDN Менеджера управления, сообщенное во время установки. Если FQDN Менеджера управления впоследствии потребуется изменить (например, из-за переноса машины с Менеджером управления в другой домен), то записи об FQDN должны быть обновлены, чтобы отразить новое имя. Команда ovirt-engine-rename автоматизирует эту задачу.

Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления в следующих местах:

/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
/etc/ovirt-engine/isouploader.conf.d/10-engine-setup.conf
/etc/ovirt-engine/logcollector.conf.d/10-engine-setup.conf
/etc/pki/ovirt-engine/cert.conf
/etc/pki/ovirt-engine/cert.template
/etc/pki/ovirt-engine/certs/apache.cer
/etc/pki/ovirt-engine/keys/apache.key.nopass
/etc/pki/ovirt-engine/keys/apache.p12

В процессе обновления прежний FQDN должен разрешаться с помощью DNS.

Если в процессе работы ovirt-engine-rename завершается с ошибкой:

[ ERROR ] Hostname is not valid: <OLD FQDN> did not resolve into an IP address

необходимо добавить прежний FQDN в файл /etc/hosts.

Команда ovirt-engine-rename не обновляет SSL-сертификаты для таких сервисов, как imageio-proxy или websocket-proxy. Сертификаты необходимо обновить вручную после выполнения ovirt-engine-rename.

После выполнения процедуры смены FQDN менеджера управления не удаляйте старое имя хоста из файла /etc/hosts, так как оно необходимо для корректной работы внутренних служб менеджера управления.

3.7.1.2. Синтаксис команды переименования oVirt Engine Rename

Базовый синтаксис команды ovirt-engine-rename:

# /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

Команда также может принимать некоторые параметры.

Таблица 78. Параметры команды `ovirt-engine-rename`**
Параметр	Описание
`--newname=[new name]`	Позволяет указать новое FQDN для Менеджера управления без взаимодействия с пользователем.
`--log=[file]`	Позволяет указать путь и имя файла, в который должны быть записаны журналы операции переименования.
`--config=[file]`	Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования.
`--config-append=[file]`	Позволяет указать путь и имя файла конфигурации для подключения к операции переименования. Этот параметр можно использовать для указания пути и имени существующего файла ответов для автоматизации операции переименования.
`--generate-answer=[file]`	Позволяет указать путь и имя файла, в который записываются ответы и значения, измененные командой `ovirt-engine-rename`.

3.7.1.3. Переименование Менеджера управления с помощью инструмента oVirt Engine Rename

Можно использовать команду ovirt-engine-rename для обновления записей об FQDN Менеджера управления.

Инструмент проверяет, предоставляет ли Менеджер управления локальный домен ISO или домен хранения данных. Если да, то прежде чем продолжить операцию, инструмент предлагает пользователю извлечь, выключить или перевести в режим обслуживания любую виртуальную машину или домен хранения, подключенный к хранилищу. Это гарантирует, что виртуальные машины не потеряют связь со своими виртуальными дисками, а домены хранения ISO не потеряют связь во время процесса переименования.

Порядок действий:

Подготовьте все DNS и другие соответствующие записи для нового FQDN.
Если используется DHCP, обновите конфигурацию DHCP-сервера.
Обновите имя хоста в Менеджере управления.

Выполните следующую команду:

# /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

При появлении запроса нажмите Ввод (Enter), чтобы остановить службу engine:
```
During execution engine service will be stopped (OK, Cancel) [OK]:
```
При появлении запроса введите новое FQDN для Менеджера управления:
```
New fully qualified server name:__new_engine_fqdn__
```

Команда ovirt-engine-rename обновит записи FQDN Менеджера управления.

Для hosted engine выполните следующие дополнительные шаги:

Выполните следующую команду на каждом существующем узле с ролью hosted engine :
# hosted-engine --set-shared-config fqdn __new_engine_fqdn__ --type=he_local
Эта команда изменяет FQDN в локальной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf, имеющейся на каждом узле с ролью hosted engine .
Выполните следующую команду на одном из узлов с ролью hosted engine :
# hosted-engine --set-shared-config fqdn __new_engine_fqdn__ --type=he_shared
Эта команда изменяет FQDN в мастер-копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf в общем домене хранения.

Теперь все новые и существующие узлы с ролью hosted engine используют новое FQDN.

3.7.2. Инструмент Engine-config

3.7.2.1. Инструмент Engine-config

Инструмент Engine-config – это утилита командной строки для настройки глобальных параметров среды zVirt. Инструмент взаимодействует со списком сопоставлений "ключ-значение", которые хранятся в базе данных engine, и позволяет извлекать и задавать значения отдельных ключей, а также извлекать список всех доступных ключей и значений конфигурации. Кроме того, для каждого уровня конфигурации в среде zVirt могут храниться разные значения.

Чтобы извлечь или задать значение ключа конфигурации, не нужно запускать ни Менеджер управления, ни WildFly. Поскольку сопоставления "ключ-значение" конфигурации хранятся в базе данных engine, их можно обновлять при работающей службе postgresql. Затем изменения применяются при перезапуске службы ovirt-engine.

3.7.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
```

3.7.3. Инструмент Engine Vacuum

3.7.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 в режиме полной очистки.

3.7.3.2. Режимы работы Engine Vacuum

Инструмент Engine Vacuum имеет два режима работы:

Стандартная очистка

Рекомендуется регулярно проводить стандартную очистку.

Стандартная очистка удаляет неиспользуемые версии строк в таблицах и индексах и помечает пространство как доступное для повторного использования в будущем. Для часто обновляемых таблиц очистку следует проводить регулярно. Однако функция стандартной очистки не возвращает пространство операционной системе.

Стандартная очистка без указания параметров обрабатывает каждую таблицу в текущей базе данных.
Полная очистка

Полную очистку рекомендуется проводить не регулярно, а тогда, когда нужно вернуть операционной системе значительную часть пространства из объема, занимаемого таблицей. Полная очистка сжимает таблицы путем записи новой копии файла таблицы без неиспользуемого места, тем самым позволяя операционной системе вернуть пространство. Полная очистка может занять много времени.

Полная очистка требует дополнительного места на диске для новой копии таблицы, пока операция не завершится и старая копия не будет удалена. Поскольку полная очистка требует полной блокировки таблицы, ее нельзя запускать одновременно с другими операциями, касающимися использования таблицы.

3.7.3.3. Синтаксис команды engine-vacuum

Базовый синтаксис команды engine-vacuum:

# engine-vacuum
# engine-vacuum _option_

Запуск команды engine-vacuum без параметров выполняет стандартную очистку.

Команду engine-vacuum можно уточнить с помощью ряда параметров.

Таблица 79. Общие параметры
Параметр	Описание
`-h`, `--help`	Выводит информацию о том, как использовать команду engine-vacuum.
`-a`	Запускает стандартную очистку, анализирует базу данных и обновляет статистику оптимизатора.
`-A`	Анализирует базу данных и обновляет статистику оптимизатора, не выполняя очистку.
`-f`	Запускает полную очистку.
`-v`	Задает режим детализации консольного вывода.
`-t table_name`	Выполняет очистку конкретной таблицы или таблиц. Например: `# engine-vacuum -f -v -t vm_dynamic -t vds_dynamic`

3.7.4. Инструмент сопоставления VDSM с именем сети

Если имя логической сети длиннее 15 знаков или содержит знаки, отличные от ASCII, то система автоматически сгенерирует имя имя-идентификатор для использования на хосте (vdsm_name), состоящее из букв on и первых 13 знаков уникального идентификатора сети, например, ona1b2c3d4e5f6g. Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имен логических сетей и их автоматически сгенерированных имен сетей, используйте инструмент сопоставления VDSM с именами сетей, расположенный в /usr/share/ovirt-engine/bin/.

Порядок действий:

При первом запуске инструмента определите переменную среды PASSWORD, которая представляет собой пароль пользователя базы данных с доступом на чтение к базе данных Менеджера управления. Например, запустите:
```
# export PASSWORD=_DatabaseUserPassword_
```
Запустите инструмент сопоставления VDSM с именем сети:
# /usr/share/ovirt-engine/bin/vdsm_to_network_name_map --user USER
где USER – пользователь базы данных с доступом на чтение к базе данных Менеджера управления, чей пароль назначен для переменной среды PASSWORD.

Инструмент отображает список имен логических сетей, сопоставленных с их эквивалентными идентификаторами, используемыми на хостах.

Дополнительные параметры

Можно запустить инструмент со следующими параметрами:

--host – имя хоста/IP-адрес сервера баз данных. Значение по умолчанию – localhost.
--port – номер порта сервера баз данных. Значение по умолчанию – 5432.
--database – имя базы данных. Значение по умолчанию – engine, представляющий собой базу данных Менеджера управления.
--secure – разрешает безопасное подключение к базе данных. По умолчанию инструмент запускается без безопасного подключения.

3.7.5. Инструмент Log Collector

3.7.5.1. Инструмент Log Collector

Перед началом работы с Log Collector необходимо на машину с Менеджером управления установить пакет ovirt-log-collector

Инструмент сбора журналов позволяет легко собирать соответствующие журналы из среды zVirt при обращении в службу поддержки.

Команда сбора журналов: ovirt-log-collector. Необходимо авторизоваться в системе Менеджера управления как root-пользователь и ввести учетные данные администратора для среды zVirt. Команда ovirt-log-collector -h отображает информацию об использовании, включая список всех действительных опций для команды ovirt-log-collector.

3.7.5.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 можно уточнить с помощью ряда параметров.

Таблица 80. Общие параметры
Параметр	Описание
`--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 в качестве открытого идентификационного файла (закрытого ключа) для сервера баз данных. Это значение не устанавливается по умолчанию; оно требуется только в том случае, если база данных не существует на локальном хосте.

3.7.5.3. Основные сведения об использовании сборщика журналов (Log Collector)

Когда команда ovirt-log-collector выполняется без указания дополнительных параметров, по умолчанию она собирает все журналы из Менеджера управления и подключенных к нему хостов. Она также собирает журналы баз данных, если только не добавлен параметр --no-postgresql. В следующем примере сборщик журналов запускается для сбора всех журналов из Менеджера управления и трех подключенных хостов.

Пример 45. Использование сборщика журналов

# 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

4. Сбор сведений о среде

4.1. Мониторинг и наблюдение

4.1.1. Использование хранилища Data Warehouse и Grafana для мониторинга zVirt

4.1.1.1. Общие сведения о Grafana

Grafana – это веб-инструмент пользовательского интерфейса для отображения отчетов на основе данных, собранных из базы данных Data Warehouse с именем ovirt_engine_history. См. панели мониторинга Grafana.

Данные от Менеджера управления собираются каждую минуту и агрегируются каждый час и каждые сутки. Данные сохраняются в соответствии с настройкой охвата (scale), заданной в конфигурации хранилища Data Warehouse во время выполнения команды engine-setup (Basic или Full):

Basic (базовый) (по умолчанию) – включает в выборку данные за 24 часа, почасовые данные за 1 месяц, а посуточные данные не сохраняет.
Full (полный) (рекомендуется) – включает в выборку данные за 24 часа, почасовые данные за 2 месяца и посуточные данные за 5 лет.

Полный охват может потребовать переноса Data Warehouse на отдельную виртуальную машину.

Инструкции по переносу хранилища Data Warehouse на отдельную машину см. в разделе Перенос базы данных и службы Data Warehouse на отдельную машину руководства администратора.

4.1.1.2. Установка

Интеграция с Grafana включена и устанавливается по умолчанию при выполнении команды engine-setup Менеджера управления как в варианте установки Stand Alone, так и в варианте Hosted Engine.

Настройка Grafana для единого входа

Команда engine-setup Менеджера управления автоматически настраивает Grafana так, чтобы существующие пользователи Менеджера управления смогли входить в систему с Портала администрирования, используя единый вход (SSO), но не создает пользователей автоматически.

Нужно создать новых пользователей ( Invite в пользовательском интерфейсе Grafana) и подтвердить их, после чего они смогут авторизоваться в системе.

Порядок действий:

Задайте адрес электронной почты для пользователя в Менеджере управления, если он еще не задан.
Авторизуйтесь в Grafana под именем существующего пользователя-администратора (изначально настроенного администратора).
Нажмите Configuration Users и выберите Invite.
Введите адрес электронной почты и имя, после чего выберите роль (Role).
Отправьте приглашение одним из следующих способов:
- Выберите Send invite mail и нажмите Submit. Для этого способа нужен работающий локальный почтовый сервер, настроенный на машине с Grafana.
- Выберите Pending Invites
  - Найдите нужную запись
  - Выберите Copy invite
  - Скопируйте и используйте эту ссылку для создания учетной записи, вставив ее прямо в адресную строку браузера или отправив другому пользователю.

Если вы используете параметр Pending Invites, то электронное письмо не отправляется и адрес электронной почты не обязательно должен существовать – подойдет любой адрес, выглядящий как действительный, если он настроен как адрес электронной почты пользователя Менеджера управления.

Чтобы авторизоваться под этой учетной записью:

Войдите на веб-страницу приветствия администратора zVirt, используя учетную запись с этим адресом электронной почты.
Выберите Портал мониторинга (Monitoring Portal), чтобы открыть панель мониторинга Grafana.
Выберите Sign in with oVirt Engine Auth.

4.1.1.3. Встроенные панели мониторинга Grafana

В первоначальной конфигурации Grafana доступны следующие панели мониторинга для создания отчетов по центрам данных, кластерам, хостам и виртуальным машинам:

Таблица 81. Встроенные панели мониторинга Grafana**
Тип панели мониторинга	Состав
oVirt Executive Dashboards	Панель мониторинга System – использование ресурсов и время безотказной работы хостов и доменов хранения в системе в соответствии с последними изменениями конфигураций. Панель мониторинга Data Center – использование ресурсов, пики и время безотказной работы кластеров, хостов и доменов хранения в выбранном центре данных в соответствии с последними изменениями конфигураций. Панель мониторинга Cluster – использование ресурсов, пики, избыточное выделение и время безотказной работы хостов и виртуальных машин в выбранном кластере в соответствии с последними изменениями конфигураций. Панель мониторинга Host – сведения о новейшей и прошлых конфигурациях и метрики использования ресурсов для выбранного хоста за выбранный период. Панель мониторинга Virtual Machine – сведения о новейшей и прошлых конфигурациях и метрики использования ресурсов для выбранной виртуальной машины за выбранный период. Панель мониторинга Executive – использование ресурсов пользователями и количество операционных систем для хостов и виртуальных машин в выбранных кластерах за выбранный период.
oVirt Inventory Dashboards	Панель мониторинга Inventory – количество хостов, виртуальных машин и запущенных виртуальных машин, использование ресурсов и уровни избыточного выделения для выбранных центров данных в соответствии с последними изменениями конфигураций. Панель мониторинга Hosts Inventory – FQDN, версия VDSM, ОС, модель ЦП, ядра ЦП, объем памяти, дата создания, дата удаления и сведения об оборудовании для выбранных хостов в соответствии с последними изменениями конфигураций. Панель мониторинга Storage Domains Inventory – тип домена, тип хранилища, доступное пространство на диске, использованное пространство на диске, общий размер диска, дата создания и дата удаления для выбранных доменов хранения за выбранный период. Панель мониторинга Virtual Machines Inventory – имя шаблона, ОС, ядра ЦП, объем памяти, дата создания и дата удаления для выбранных виртуальных машин в соответствии с последними изменениями конфигураций.
oVirt Service Level Dashboards	Панель мониторинга Uptime – плановое время простоя, внеплановое время простоя и общее время для хостов, виртуальных машин с признаком высокой доступности и всех виртуальных машин в выбранных кластерах за выбранный период. Панель мониторинга Hosts Uptime – время безотказной работы, плановое время простоя и внеплановое время простоя для выбранных хостов за выбранный период. Панель мониторинга Virtual Machines Uptime Dashboard – время безотказной работы, плановое время простоя и внеплановое время простоя для выбранных виртуальных машин за выбранный период. Cluster Quality of Service Панель мониторинга Hosts – время, в течение которого выбранные хосты работали с загрузкой ЦП и ОЗУ выше и ниже соответствующих пороговых значений за выбранный период. Панель мониторинга Virtual Machines – время, в течение которого выбранные виртуальные машины работали с загрузкой ЦП и ОЗУ выше и ниже соответствующих пороговых значений за выбранный период.
oVirt Trend Dashboards	Панель мониторинга Trend – показатели использования 5 наиболее и наименее загруженных (по ОЗУ и ЦП) виртуальных машин и хостов в выбранных кластерах за выбранный период. Панель мониторинга Hosts Trend – использование ресурсов (количество виртуальных машин, ЦП, ОЗУ и сетевые приемники/передатчики) для выбранных хостов за выбранный период. Панель мониторинга Virtual Machines Trend – использование ресурсов (ЦП, ОЗУ, сетевые приемники/передатчики, дисковый ввод/вывод) для выбранных виртуальных машин за выбранный период. Панель мониторинга Hosts Resource Usage – посуточное и почасовое использование ресурсов (количество виртуальных машин, ЦП, ОЗУ и сетевые приемники/передатчики) для выбранных хостов за выбранный период. Панель мониторинга Virtual Machines Resource Usage – посуточное и почасовое использование ресурсов (ЦП, ОЗУ, сетевые приемники/передатчики, дисковый ввод/вывод) для выбранных виртуальных машин за выбранный период.

Можно создавать настраиваемые панели мониторинга либо копировать и изменять существующие панели, исходя из того, какая информация нужна в отчете.

Более подробную информацию о панелях мониторинга см. в Описание панелей портала мониторинга

Встроенные панели мониторинга настраивать нельзя.

4.1.2. Настройка системы мониторинга доменов хранения

Содержимое данного раздела актуально для версии zVirt 3.1 и выше.

Система виртуализации zVirt предоставляет администратору информацию о нагрузке на домены хранения в реальном времени для помощи в принятии решений о размещении дисков виртуальных машин при их создании, изменении и перемещении.

Правильная работы подсистемы обеспечивается установленными в виртуальных машинах гостевыми дополнениями.

Функциональность поддерживается для следующих гостевых ОС:

ОС Windows XP/7/2003/2008 и новее
Linux

4.1.2.1. Отображение информации о нагрузке на домены хранения

Информация предоставляется в виде метрик (MB/s) в столбцах Cкорость чтения, Скорость записи, Задержка записи и Задержка чтения в следующих элементах интерфейса:

Хранилище (Storage) Домены (Domains)
Хранилище (Storage) Диски (Disks)
Ресурсы (Compute) Виртуальные машины (Virtual Machines) → Имя ВМ (Name VM) → Диски (Disks)

4.1.2.2. Настройка оповещений о превышении нагрузки на домены хранения

Дополнительно можно настроить пороговые значения параметров мониторинга для доменов хранения, после превышения которых администратор будет оповещен о событии в Блок уведомлений (раздел Предупреждения) и в События (Events):

Порядок действий:

Нажмите Хранилище (Storage) Домены (Domains).
При изменении настроек существующего:
- Нажмите на имя домена который хотите настроить (откроется его расширенное описание) или просто выделите нужный домен левой кнопкой мыши.
- Нажмите Управление доменом (Manage Domain).
- В появившемся окне Управление доменом (Manage Domain) разверните параметр Конфигурация контроля мониторинга и оповещений (Monitoring and alerting configuration control), нажав на раскрывающую стрелку .
При создании нового:
- Нажмите Новый домен (New Domain).
- В появившемся окне Новый домен (New Domain) разверните параметр Конфигурация контроля мониторинга и оповещений (Monitoring and alerting configuration control), нажав на раскрывающую стрелку .
Включите оповещения выбрав Включить мониторинг использования хранилища и оповещения (Enabled storage usage monitoring and alerting) и введите пороговые значения параметров. Если значение параметра установить равным 0, то оповещение производиться не будет.

Если установить переключатель конфигурации контроля мониторинга и оповещений в Отключить мониторинг использования хранилища и оповещения (Disabled storage usage monitoring and alerting), то оповещения производится не будут, но информация по скорости записи и чтения, задержки записи и чтения будет отображена в соответствующих элементах интерфейса.

4.1.2.3. Алгоритм работы оповещений

Есть три основных параметра, которые определяют алгоритм работы:

StorageDomainMonitoring_MetricsScrapePeriodSeconds: Устанавливает период проверки значений метрик с заданными лимитами.

Например: установлено значение 20, значит каждые 20 сек измеряются показания метрик на превышение)

Значение по умолчанию: 20
StorageDomainMonitoring_InvalidMeasurementsCountTolerationThreshold: Определяет кол-во измеренных подряд превышений заданного лимита после старта системы. При превышении которого будет выдано сообщение.

Например: установлено значение 6, временной интервал проверки задан 20, значит - если после старта в течение 2 минут (6*20 = 120 = 2 минуты) нагрузка будет превышать заданный лимит, то будет выдано уведомление

Значение по умолчанию: 3
StorageDomainMonitoring_InvalidMeasurementsCountForRepetitiveNotification: Определяет кол-во измеренных подряд превышений заданного лимита после отправки самого первого уведомления о превышении лимитов, при превышении которого будет выдано повторное сообщение.

Например: установлено значение 60, временной интервал проверки StorageDomainMonitoring_MetricsScrapePeriodSeconds задан 20, значит - после выдачи первого сообщения при сохранении нагрузки через 20 минут (60*20 = 1200c = 20 минут) будет выдано повторное сообщение. Если нагрузка будет сохраняться и дальше, то через 20 мин будет выдано ещё сообщение и т.д. Т.е. нагрузка должна сохраняться в течение заданного времени (в данном примере не менее 20 мин), иначе уведомление придет позже

Значение по умолчанию: 1080

Все вышеописанное применяется к каждой метрике отдельно.

Все настройки задаются через команду engine-config -s <параметр>=<значение> и далее systemctl restart ovirt-engine, после чего новые настройки незамедлительно вступают в силу.

Пример 46. Настройка оповещений

engine-config -s  StorageDomainMonitoring_MetricsScrapePeriodSeconds=10
engine-config -s  StorageDomainMonitoring_InvalidMeasurementsCountTolerationThreshold=2
engine-config -s  StorageDomainMonitoring_InvalidMeasurementsCountForRepetitiveNotification=10

Система запущена, установлена и подана нагрузка на ВМ.

Результаты:

Первое уведомление о превышении заданных лимитов пришло через 20 секунд (нагрузка сохраняется);
Повторное уведомление о превышении лимитов пришло через 100 секунд (нагрузка сохраняется);
Следующее уведомление ожидаем придёт через 100 секунд при сохранении нагрузки;
В случае если нагрузка прервалась и через некоторое время возобновилась и продолжалась не менее 100 секунд придет повторное уведомление.

4.1.3. Создание отчетов о состоянии инфраструктуры

Данная функция доступна только в zVirt версии 3.2 или выше

4.1.3.1. Сервис создания предварительно настроенных отчетов о состоянии виртуальной инфраструктуры

zVirt предоставляет возможность формировать отчеты о состоянии виртуальной инфраструктуры. На основании полученных из отчетов данных можно находить узкие места в виртуальной инфраструктуре, принимать решения для их устранения, принимать решения по планированию виртуальной инфраструктуры, использовать отчеты при обращении в СТП.

Для получения доступа к шаблонам отчётов на портале администрирования перейдите в Мониторинг (Monitoring) Отчёты (Reports)

Рисунок 15. Панель "Шаблоны отчётов"

Для удобства можно настроить отображение шаблонов как "Список" list или как "Карточки" grid .

4.1.3.2. Создание отчёта из шаблона

Процедура создания идентична для всех имеющихся типов шаблонов отчётов и предполагает выполнение следующих действий.

Порядок действий:

На портале администратора перейдите в Мониторинг (Monitoring) Отчёты (Reports)
Дополнительно: если отчет формируется на основе шаблонов Ошибки виртуальной инфраструктуры (Virtual Infrastructure Errors) или Утилизация виртуальной инфраструктуры (Virtual Infrastructure Utilization), в списке Период отчетности выберите период, данные из которого должны войти в отчёт.
Нажмите Сформировать для нужного шаблона

Как только отчёт будет готов - изменится значение в поле Последние создание, а также появится уведомление в разделе События (Events) в панели оповещений EventsIcon .

Рисунок 16. Пример уведомления об успешном формировании отчёта

После готовности отчёта, его можно скачать в форматах pdf и html. Для этого используйте соответствующую ссылку рядом с каждым шаблоном отчёта down link

4.1.3.3. Отчёт "Емкость доменов хранения"

Отчет "Емкость доменов хранения" позволяет следить за состоянием доменов хранения и виртуальных дисков, что может помочь в в планировании и управлении виртуальной инфраструктурой в части доменов хранения.

Отчет содержит следующие графики и таблицы:

Диаграмма Общая информация по ресурсам хранения (Топ-10): Гистограмма с накоплением, содержащая информацию о доступном и занятом пространстве "Топ-10" доменов хранения (по объему).

Диаграмма Общая информация по дискам виртуальных машин: Нормированная гистограмма с накоплением, содержащая информацию по Топ-10 виртуальных дисков (по занятому пространству в процентном соотношении).

На гистограмме отображаются только диски с динамическим выделением пространства, поскольку виртуальные диски с предварительным выделением распознаются как заполненные на 100%.

Таблица Детальная информация по доменам хранения: таблица имеет следующую структуру:

Имя

Центр данных

Тип

Тип хранилища

Объем

Доступно

Доступно %

Имя домена хранения в системе

Центр данных, к которому прикреплен домен хранения

Тип домена хранения

Тип хранилища (iSCSI/NFS/Local/др.)

Объем домена хранения.

Объем доступного пространства домена хранения (в Гб/Тб).

Объем доступного пространства домена хранения (в процентах).

Общий объем

Общий объем всех доменов хранения.

Общий объем доступного пространства по всем доменам хранения (в Гб/Тб).

Общий объем доступного пространства по всем доменам хранения (в процентах).

Если данных по объемам домена хранения нет, то в таблице отображается прочерк -.

Таблица Детальная информация по виртуальным дискам: таблица имеет следующую структуру:

Имя

Домен хранения

Объем

Занято

Доступно %

Политика распределения

Виртуальная машина

Имя диска

Имя домена хранения

Объем диска.

Объем занятого пространства.

Объем доступного пространства на диске (в процентах).

Preallocated/Thin

Список ВМ, к которым прикреплен диск. Может быть несколько для shared дисков.

Если данных по объемам диска нет, то в таблице отображается прочерк -.

4.1.3.4. Отчёт "Обзор состояния виртуальной инфраструктуры"

Отчет позволяет получить основные сведения о виртуальной инфраструктуре по состоянию на дату создания отчета.

Отчёт содержит следующие таблицы:

Таблица Кластеры

Имя

Центр данных

Кол-во хостов

ЦПУ (ГГц)

Объем ОЗУ

Кол-во ВМ

Кол-во активных ВМ

Имя кластера в системе

Имя центра данных, в котором находится кластер

Кол-во хостов в кластере

Объем ЦПУ в ГГц всех хостов

Объем оперативной памяти всех хостов.

Обще кол-во ВМ в кластере

Кол-во работающих ВМ в кластере на момент формирования отчета

Таблица Хосты

Имя

Кластер

Кол-во ЦПУ

Кол-во ядер ЦПУ

Тип процессора (модель)

Объем ОЗУ

Производитель

Модель

Серийный номер

Имя хоста в системе

Имя кластера, в котором находится хост

Кол-во сокетов

Количество ядер по всем советам

Модель процессора

Объем оперативной памяти

Производитель сервера

Таблица Домены хранения

Имя

Центр данных

Тип

Тип хранилища

Общий объем

Доступно

Занято

Имя домена хранения в системе

Имя центра данных, в котором находится кластер

Тип домена хранения

iscsi/nfs/др.

Общий объем домена хранения.

Доступное пространство в домене хранения.

Занятое пространство в домене хранения.

Таблица Виртуальные машины

Имя

Кластер

Кол-во виртуальных ЦПУ

Объем ОЗУ

Диск(и)

Объем дисков

ОС

Имя ВМ в системе

Кластер, в котором работает ВМ

Число виртуальных ЦПУ

Объем ОЗУ

Список дисков (алиасы)

Виртуальный размер диска.

Операционная система

Таблица Виртуальные сети

Имя Описание Центр данных Сеть ВМ

Имя сети

Описание

Центр данных, в котором заведена сеть

Да/Нет

4.1.3.5. Отчет "Ошибки виртуальной инфраструктуры"

Этот отчет может быть использован для оценки состояния инфраструктуры, а также для предоставления руководителям информации о возникших ошибках за определенный период времени.

Отчет состоит из двух разделов:

Общие сведения. Включает следующую информацию:
- Общее количество предупреждений
- Количество ошибок
- Количество предупреждений, требующих вмешательства
- Количество объектов, на которых были обнаружены ошибки и предупреждения
- Круговая диаграмма, отображающая количество ошибок и предупреждений

Детализация. Таблица, включающая следующие сведения:

Идентификатор

Объект

Тип

Время

Текст

Уникальный идентификатор, по которому можно найти уведомление в таблице audit_log

Объект, с которым связано оповещение

Уровень критичности события (Ошибка/Предупреждение/Предупреждение, требующее вмешательства)

Время возникновения события

Текст сообщения события

4.1.3.6. Отчет "Утилизация виртуальной инфраструктуры"

Этот отчет содержит информацию по утилизации ресурсов виртуальной инфраструктуры, таких как ЦПУ, ОЗУ, а также дисковое пространство, что позволяет оценить динамику использования перечисленных ресурсов за выбранный промежуток времени, выявить неполадки производительности и определить меры для правильного распределения ресурсов.

В разделе Детали данного отчёта содержится следующая информация:

Подраздел Кластеры. Для каждого кластера формируются следующие таблицы и графики:
- Таблица Хосты кластера
  
  Имя хоста Объем ОЗУ Число сокетов Число ядер ЦПУ Объем ЦПУ (ГГц)
- Таблица Использование ЦПУ хостами (%)
  
  Имя хоста Среднее Минимум Максимум
- Линейный график с отображением ТОП-10 хостов по утилизации ЦПУ (среднее).
- Линейный график с отображением ТОП-10 хостов по утилизации ЦПУ (максимум).
- Диаграмма с отображением 2 хостов с наименьшим и наибольшим средним потреблением ЦПУ.
- Таблица Использование ОЗУ хостами (%)
  
  Имя хоста Среднее Минимум Максимум
- Линейный график с отображением ТОП-10 хостов по утилизации ОЗУ (среднее).
- Линейный график с отображением ТОП-10 хостов по утилизации ОЗУ (максимум).
- Диаграмма с отображением 2 хостов с наименьшим и наибольшим средним потреблением ОЗУ.

Подраздел Домены хранения. Содержит следующие таблицы и графики:

Таблица с информацией по доменам хранения

Имя

Центр данных

Тип

Тип хранилища

Объем

Доступно

Доступно %

Имя домена хранения в системе

Центр данных, к которому прикреплен домен хранения

Тип домена хранения

Тип хранилища (iSCSI/NFS/Local/др.)

Объем домена хранения.

Объем доступного пространства домена хранения (в Гб/Тб).

Объем доступного пространства домена хранения (в процентах).

Линейные графики по утилизации для каждого домена хранения c с разбивкой по Центрам данных.

Подраздел Виртуальные машины
- Линейный график с отображением ТОП-10 ВМ по утилизации ЦПУ.
- Диаграмма с отображением 2 ВМ с наименьшим и наибольшим средним потреблением ЦПУ.
- Линейный график с отображением ТОП-10 ВМ по утилизации ОЗУ.
- Диаграмма с отображением 2 ВМ с наименьшим и наибольшим средним потреблением ОЗУ.

4.1.3.7. Разграничение прав доступа к функциональности создания отчетов о состоянии виртуальной инфраструктуры

Доступ к функционалу, связанному с отчетами, требует авторизации пользователя с ролью, которой назначена привилегия Создание отчетов о состоянии виртуальной инфраструктуры (Virtual infrastructure reports)

Разрешение Создание отчетов о состоянии виртуальной инфраструктуры (Virtual infrastructure reports) доступно только для типа учётной записи Администратор (Admin).

Для роли SuperUser разрешение Создание отчетов о состоянии виртуальной инфраструктуры (Virtual infrastructure reports) включено по умолчанию.

4.1.4. Визуализация виртуальной инфраструктуры

Процедуры, описанные в этой инструкции актуальны для версии zVirt 3.2 и выше

4.1.4.1. Общая информация о модуле

zVirt предоставляет возможность просмотра объектов виртуальной инфраструктуры и связей между ними в виде древовидной диаграммы. Такое представление позволяет наиболее простым способом просматривать объекты виртуальной инфраструктуры и их текущее состояние.

Визуализация обеспечивается backend-сервисом, который опрашивает менеджер управления, получает информацию об объектах виртуальной инфраструктуры и их связях, а затем формирует файл диаграммы.

Сервис получает от менеджера управления информацию о следующих объектах инфраструктуры и их связях:

Центры данных
Домены хранения
Кластеры
Хосты

Для просмотра диаграммы виртуальной инфраструктуры на Портале администрирования перейдите в Мониторинг (Monitoring) → Обзор (Overview).

Рисунок 17. Пример диаграммы виртуальной инфраструктуры

4.1.4.2. Отображение объектов виртуальной инфраструктуры

В следующих таблицах представлены значения пиктограмм, используемых в диаграмме виртуальной инфраструктуры.

Таблица 82. Сущности диаграммы виртуальной инфраструктуры
Пиктограмма	Значение
	Центр данных
	Кластер
	Домен хранения
	Хост без специальных ролей
	Хост с ролью менеджера управления, развернутый в режиме Standalone
	Сервер, выполняющий роль менеджера управления и не являющийся хостом для размещения виртуальных машин

Таблица 83. Статус сущностей
Пиктограмма	Значение
Пиктограмма статуса отсутствует	В зависимости от сущности, к которой применяется, может указывать на следующие статусы: Хост Включен (UP) Центр данных Включен (UP) Домен хранения Активен (Active)
	В зависимости от сущности, к которой применяется, может указывать на следующие статусы: Хост Подключение (Connecting) Инициализация (Initializing) Установка провалена (InstallFailed) Установка (Installing) Установка ОС (InstallingOS) Обслуживание (Maintenance) В ожидании подтверждения (Pending Approval) Подготовка к обслуживанию (PreparingForMaintenance) Перезагрузка (Reboot) Не присоединён (Unassigned) Центр данных Конкурирует (Contend) Обслуживание (Maintenance) Не инициализирован (Uninitialized) Домен хранения Активация (Activating) Открепление (Detaching) Обслуживание (Maintenance) Подготовка к обслуживанию (PreparingForMaintenance) Не инициализирован (Uninitialized)
	В зависимости от сущности, к которой применяется, может указывать на следующие статусы: Хост Ошибка (Error) Неработоспособен (NonOperational) Не отвечает (NonResponsive) Центр данных Не отвечает (NonResponsive) Неработоспособен (NonOperational) Домен хранения Неактивен (Inactive) Заблокирован (Locked) Неизвестно (Unknown)

4.1.4.3. Операции с диаграммой виртуальной инфраструктуры

Диаграмма виртуальной инфраструктуры является интерактивной. С помощью различных инструментов можно управлять отображением диаграммы, а также получать более подробную информацию о сущностях.

Панель управления внизу диаграммы позволяет изменить масштаб диаграммы, а также сбросить её отображение.

Рисунок 18. Панель управления диаграммой

Хосты в кластере могут быть свёрнуты для уменьшения диаграммы.

Рисунок 19. Отображение диаграммы со свёрнутыми кластерами

Для сворачивания хостов нажмите рядом с именем группы хостов, а для разворачивания - .

При наведении указателя на сущность появляется подсказка, содержащая следующие сведения:

Статус сущности
Ссылка для перехода на страницу администрирования сущности
Тип домена хранения (только для доменов хранения)

Рисунок 20. Примеры подсказки для хоста

Рисунок 21. Примеры подсказки для домена хранения

С помощью меню "Параметры отображения" можно изменять детализацию диаграммы.

Рисунок 22. Меню "Параметры отображения"

Меню "Расположение" позволяет изменить способ отображения сущностей.

Рисунок 23. Меню "Расположение"

4.1.4.4. Ограничение прав доступа к диаграмме виртуальной инфраструктуры

Просмотр диаграммы доступен только пользователю с ролью, содержащей административное разрешение Система → Настроить систему → Общая настройка

4.2. Файлы журналов

4.2.1. Файлы журналов установки Менеджера управления

Таблица 84. Установка
Файл журнала	Описание
/var/log/ovirt-engine/engine-cleanup-yyyy_mm_dd_hh_mm_ss.log	Журнал команды `engine-cleanup`. Эта команда используется для сброса установленного Менеджера управления. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.
/var/log/ovirt-engine/engine-db-install-yyyy_mm_dd_hh_mm_ss.log	Журнал команды `engine-setup`, в котором подробно описывается создание и конфигурирование базы данных engine.
/var/log/ovirt-engine/ovirt-engine-dwh-setup-yyyy_mm_dd_hh_mm_ss.log	Журнал команды `ovirt-engine-dwh-setup`. Эта команда используется для создания базы данных ovirt_engine_history для отчетности. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.
/var/log/ovirt-engine/setup/ovirt-engine-setup-yyyymmddhhmmss.log	Журнал команды `engine-setup`. Журнал создается каждый раз при выполнении команды. В имени файла указываются дата и время запуска, что позволяет создавать множество журналов.

4.2.2. Файлы журнала Менеджера управления

Таблица 85. Обслуживание
Файл журнала	Описание
/var/log/ovirt-engine/engine.log	Отражает все сбои графического пользовательского интерфейса Менеджера управления, события поиска в Active Directory, проблемы с базой данных и другие события.
/var/log/ovirt-engine/host-deploy	Файлы журналов с хостов, развернутых из Менеджера управления.
/var/lib/ovirt-engine/setup-history.txt	Отслеживает установку и обновление пакетов, ассоциированных с Менеджером управления.
/var/log/httpd/ovirt-requests-log	Регистрирует в журнале файлы из запросов, сделанных через HTTPS к Менеджеру управления (включая время, которое заняло выполнение каждого запроса). Заголовок Correlation-Id включается для того, чтобы дать возможность сравнивать запросы при сравнении файла журнала с /var/log/ovirt-engine/engine.log.
/var/log/ovn-provider/ovirt-provider-ovn.log	Регистрирует в журнале действия провайдера OVN. Информацию о журналах Open vSwitch см. в документации на Open vSwitch.

4.2.3. Файлы журналов SPICE

Файлы журналов SPICE могут помочь при устранении проблем с подключениями SPICE. Для запуска отладки SPICE измените уровень журнала на отладку (debugging). Затем определите местонахождение журнала.

И клиенты, используемые для доступа к гостевым машинам, и сами гостевые машины имеют файлы журналов SPICE. Если клиент SPICE был запущен с использованием собственного клиента, для которого загружен файл console.vv, то для клиентских журналов используйте команду remote-viewer, чтобы включить отладку и сгенерировать вывод журнала.

4.2.3.1. Журналы SPICE для серверов SPICE гипервизора

Таблица 86. Журналы SPICE для серверов SPICE гипервизора
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала:
Сервер SPICE хоста/гипервизора	/var/log/libvirt/qemu/(guest_name).log	Выполните команду `export SPICE_DEBUG_LEVEL=5` на хосте/гипервизоре до запуска гостевой машины. Парсинг этой переменной выполняет QEMU, и в случае запуска для всей системы будет напечатана отладочная информация обо всех виртуальных машинах в системе. Эту команду нужно запускать на каждом хосте в кластере. Эта команда работает только на уровне хоста/гипервизора, а не кластера.

4.2.3.2. Журналы SPICE для гостевых машин

Таблица 87. Журналы spice-vdagent для гостевых машин
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала:
Гостевая машина Windows	C:\Windows\Temp\vdagent.log C:\Windows\Temp\vdservice.log	Не применимо
Гостевая машина Linux	Используйте `journalctl` от имени root-пользователя.	Чтобы запустить службу spice-vdagentd в режиме отладки, от имени root-пользователя создайте файл /etc/sysconfig/spice-vdagentd, содержащий следующую запись: `SPICE_VDAGENTD_EXTRA_ARGS="-d -d"` Чтобы запустить spice-vdagent в режиме отладки, в командной строке выполните: `$ killall -u $USER spice-vdagent $ spice-vdagent -x -d [-d] [\| & tee spice-vdagent.log]`

4.2.3.3. Журналы SPICE для клиентов SPICE, запущенных с использованием файлов console.vv

Для клиентских машин Linux

Включите отладку SPICE, выполнив команду remote-viewer с параметром --spice-debug. После появления запроса введите URL-адрес для подключения, например, spice://virtual_machine_IP:port.
```
#  remote-viewer --spice-debug
```
Чтобы запустить клиент SPICE с параметром отладки и передать ему файл .vv, загрузите файл console.vv и выполните команду remote-viewer с параметром --spice-debug и укажите полный путь к файлу console.vv.
```
# remote-viewer --spice-debug __/path/to/__console.vv
```

Для клиентских машин Windows

В virt-viewer версии 2.0-11.el7ev и более поздних установщик virt-viewer.msi устанавливает virt-viewer и debug-viewer.exe.
Выполните команду remote-viewer с аргументом --spice-debug, указав ей путь к консоли:
```
remote-viewer --spice-debug _path\to\console.vv_
```
Чтобы просмотреть журналы, подключитесь к виртуальной машине, и вы увидите командную строку с запущенным GDB, которая печатает стандартный вывод и стандартную ошибку remote-viewer.

4.2.4. Файлы журналов хоста

Файл журнала Описание

/var/log/messages

Файл журнала, который используется libvirt. Для просмотра журнала используйте journalctl. Чтобы просматривать журнал, нужно быть членом групп adm, systemd-journal или wheel.

/var/log/vdsm/spm-lock.log

Файл журнала с информацией о способности хоста получать права на аренду в роли Менеджера пула хранения (SPM). Этот журнал содержит информацию о предоставлении, лишении, обновлении прав на аренду или об отказе в этих правах.

/var/log/vdsm/vdsm.log

Файл журнала для VDSM, агента Менеджера управления на хосте (хостах).

/tmp/ovirt-host-deploy-Date.log

Журнал развертывания хоста, который копируется в Менеджер управления как /var/log/ovirt-engine/host-deploy/ovirt-Date-Host-Correlation_ID.log после успешного развертывания хоста.

/var/log/vdsm/import/import-UUID-Date.log

Файл журнала с подробным описанием импорта виртуальных машин с хоста KVM или провайдера VMware, включая информацию об ошибках импорта. UUID – это UUID импортированной виртуальной машины, а Date – дата и время начала импортирования.

/var/log/vdsm/supervdsm.log

Регистрирует в журнале задачи VDSM, которые выполнялись с разрешениями суперпользователя.

/var/log/vdsm/upgrade.log

VDSM использует этот файл журнала во время обновлений хостов для регистрации изменений конфигурации.

/var/log/vdsm/mom.log

Регистрирует действия менеджера избыточного выделения памяти VDSM.

4.2.5. Настройка журналирования на уровень отладки для служб zVirt

Журналы следующих служб zVirt можно настроить на уровень отладки, изменив файл sysconfig каждой службы.

Таблица 88. Службы zVirt и пути к файлам sysconfig
Служба	Путь к файлу
ovirt-engine.service	/etc/sysconfig/ovirt-engine
ovirt-engine-dwhd.service	/etc/sysconfig/ovirt-engine-dwhd
ovirt-fence-kdump-listener.service	/etc/sysconfig/ovirt-fence-kdump-listener
ovirt-websocket-proxy.service	/etc/sysconfig/ovirt-websocket-proxy

Эта модификация влияет на процесс журналирования, выполняемый оболочкой Python, а не основным процессом службы.

Настройка журналирования на уровень отладки полезна для отладки проблем, связанных с запуском, например, если основной процесс не запускается из-за отсутствующей или некорректной среды выполнения Java или библиотеки.

Предварительные условия:

Убедитесь, что файл sysconfig, который нужно изменить, существует. Если необходимо, создайте его.

Порядок действий:

Добавьте в файл sysconfig службы следующую строку:
```
OVIRT_SERVICE_DEBUG=1
```
Перезапустите службу:
```
# systemctl restart <service>
```

Теперь для файла журнала sysconfig службы задан уровень отладки.

Эта настройка предписывает выполнять журналирование в системный журнал, поэтому генерируемые ею журналы можно найти либо в /var/log/messages, а не в файле журнала конкретной службы, либо использовав команду journalctl.

4.2.6. Основные файлы конфигурации для служб zVirt

В дополнение к файлу sysconfig, у каждой из этих служб zVirt есть еще один файл конфигурации, который используется чаще.

Таблица 89. Службы zVirt и файлы конфигурации
Служба	Путь к файлу sysconfig	Основной файл конфигурации
ovirt-engine.service	/etc/sysconfig/ovirt-engine	/etc/ovirt-engine/engine.conf.d/*.conf
ovirt-engine-dwhd.service	/etc/sysconfig/ovirt-engine-dwhd	/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf
ovirt-fence-kdump-listener.service	/etc/sysconfig/ovirt-fence-kdump-listener	/etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/*.conf
ovirt-websocket-proxy.service	/etc/sysconfig/ovirt-websocket-proxy	/etc/ovirt-engine/ovirt-websocket-proxy.conf.d/*.conf

4.2.7. Настройка централизованного журналирования

4.2.7.1. Настройка zVirt для передачи сообщений о событиях системы в сторонний сервер журналирования.

Систему управления виртуализацией zVirt можно настроить на передачу сообщений о событиях в системе в централизованный сервер журналирования по стандартному протоколу syslog. zVirt позволяет настроить отправку сообщений как отдельных хостов, так и всех хостов отдельного кластера.

Настройки журналирования отдельного хоста имеют наибольший приоритет над настройками журналирования кластера, но при вводе хоста в новый кластер, его настройки будут заменены на настройки кластера.

Настройка передачи сообщений о событиях системы в сторонний сервер журналирования для одного кластера виртуализации

Для настройки передачи сообщений о событиях системы в сторонний сервер журналирования для одного кластера нужно выполнить следующие действия:

Нажмите Ресурсы (Compute) Кластеры (Clusters).
При изменении настроек существующего:
- Нажмите Имя (Name) кластера, который хотите настроить (откроется его расширенное описание) или просто выделите нужный кластер левой кнопкой мыши.
- Нажмите Изменить (Edit).
- В появившемся окне Изменить кластер (Edit Cluster) выберите закладку Журналирование (Logging).
При создании нового:
- Нажмите Новый (New).
- В появившемся окне Новый кластер (New Cluster) выберите закладку Журналирование (Logging).
Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервер журналирования, если порт отличается от стандартного.
При необходимости отметьте флажком Использовать TCP-соединение (Use TCP connection).

Настройка передачи сообщений о событиях системы в сторонний сервер журналирования для одного хоста виртуализации

Для настройки передачи сообщений о событиях системы в сторонний сервер журналирования для одного хоста нужно выполнить следующие действия:

Нажмите Ресурсы (Compute) Хосты (Hosts).
При изменении настроек существующего:
- Нажмите Имя (Name) хоста, который хотите настроить (откроется расширенное описание хоста) или просто выделите нужный хост левой кнопкой мыши.
- Нажмите Изменить (Edit).
- В появившемся окне Изменить хост (Edit Host) выберите закладку Журналирование (Logging).
При создании нового:
- Нажмите Новый (New).
- В появившемся окне Новый хост (New Host) выберите закладку Журналирование (Logging). image::host-logging.png[role-center]
Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервера журналирования, если порт отличается от стандартного.
При необходимости отметьте флажком Использовать TCP-соединение (Use TCP connection).

4.2.7.2. Пример настройки

Приведён для справки, все настройки производятся из интерфейса zVirt.

Настройки хоста виртуализации

Файл /etc/rsyslog.d/10-cluster.conf:

# Модуль чтения из файла
module(load="imfile" mode="inotify")
# Шаблон отправляемой по сети строки
template (name="Longtag" type="string"
string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%$.suffix%%msg:::sp-if-no-1st-sp%%msg%")

# Правило отправки сообщений о событиях на сервер
ruleset(name="sendLog") {
action(type="omfwd" Target="192.168.1.155" Port="514" protocol="tcp" Template="Longtag")
}

# Правило для извлечения части пути из имени файла
ruleset(name="appLogs") {
    set $.suffix=re_extract($!metadata!filename, "(.*)/([^/]*)", 0, 2, "app.log");
    call sendLog
}

# Задаем тестовый файл для отслеживания
input(type="imfile"
    file="/var/log/test/test.log"
    tag="test__"
    ruleset="appLogs"
    addMetadata="on")

# Задаем каталог для отслеживания
input(type="imfile"
    file="/var/log/tst/*.log"
    tag="tst__"
    ruleset="appLogs"
    addMetadata="on"
)

Настройка сервера журналирования (для ОС семейства RedHat Enterprise Linux).

Настройка с портами по умолчанию

В конец файла /etc/rsyslog.conf внесите следующие изменения:

# Provides TCP syslog reception
# for parameters see http://www.rsyslog.com/doc/imtcp.html
#module(load="imtcp") # needs to be done just once
#input(type="imtcp" port="514")

# Загружаем модуль udp
module(load="imudp")
input(type="imudp" port="514" ruleset="RemoteLogProcess")

# Загружаем модуль tcp
module(load="imtcp")
input(type="imtcp" port="514" ruleset="RemoteLogProcess")

# Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
template(name="RemoteLogSavePath" type="list") {
    constant(value="/var/log/")
    property(name="fromhost-ip")
    constant(value="/")
    property(name="timegenerated" dateformat="year")
    constant(value="-")
    property(name="timegenerated" dateformat="month")
    constant(value="-")
    property(name="timegenerated" dateformat="day")
    constant(value="/")
    property(name="$.logpath")
}

# Шаблон для вывода только сообщения
template(name="OnlyMsg" type="string" string="%msg:::drop-last-lf%\n")

# Загружаем модуль записи в файл
module(load="builtin:omfile"
    FileOwner="root"
    FileGroup="adm"
    dirOwner="root"
    dirgroup="adm"
    FileCreateMode="0640" DirCreateMode="0755")

# Интерпретировать \n как перевод строки
$EscapeControlCharactersOnReceive off

# Правило для разбора приходящих логов
ruleset(name="RemoteLogProcess") {
    if ( $syslogfacility >= 16 ) then
    {
        # Заменяем __ на /
        set $.logpath = replace($programname, "__", "/");
            # Сохранение в файл:
            # dynaFileCacheSize - максимальное количество открытых сгенерированных лог-файлов
        # dynaFile - правило для генерации имени лог-файла
        # template - шаблон записываемых сообщений
            # flushOnTXEnd - сброс буфера после приема сообщения
            # asyncWriting - асинхронная запись
        # flushInterval - время сброса буфера в секундах
            # ioBufferSize - размер буфера
            action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="OnlyMsg"
        flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
    } else {
            if (($syslogfacility == 0)) then {
                set $.logpath = "kern";
        }
            else if (($syslogfacility == 4) or ($syslogfacility == 10)) then {
                set $.logpath = "auth";
        }
            else if (($syslogfacility == 9) or ($syslogfacility == 15)) then {
                set $.logpath = "cron";
        } else {
                set $.logpath = "syslog";
        }
            action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="RSYSLOG_FileFormat"
            flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
    }
}

#### GLOBAL DIRECTIVES ####

# Where to place auxiliary files
global(workDirectory="/var/lib/rsyslog")

# Use default timestamp format
#module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")

# Include all config files in /etc/rsyslog.d/
#include(file="/etc/rsyslog.d/*.conf" mode="optional")

Добавьте разрешающие правила в firewalld (если установлен):

firewall-cmd --add-port=514/tcp --permanent
firewall-cmd --add-port=514/udp --permanent
firewall-cmd --reload

Если порт службы изменён на другой (описывается ниже), то его также следует добавить в разрешающие правила.

Перезапустить службу rsyslog.service и проверить статус:
```
systemctl restart rsyslog
systemctl status rsyslog
```

Сообщения будут сохранятся сервером согласно настроек шаблона:

# Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
template(name="RemoteLogSavePath" type="list") {
    constant(value="/var/log/")
    property(name="fromhost-ip")
    constant(value="/")
    property(name="timegenerated" dateformat="year")
    constant(value="-")
    property(name="timegenerated" dateformat="month")
    constant(value="-")
    property(name="timegenerated" dateformat="day")
    constant(value="/")
    property(name="$.logpath")
}

В /var/log/ будут созданы каталоги с именем равным IP удалённого хоста, с которого собираются сообщения о событиях.

Смена порта, используемого службой сервера журналирования по умолчанию на другой:

Порядок действий:

Убедитесь, что порт больше 1023 (порты от 0 до 1023 являются привилегированными и зарезервированными для своих служб).
Проверьте список всех открытых портов:
```
ss -lntu
```
Если нужный порт не открыт, то добавьте его в разрешающие правила firewalld:
```
firewall-cmd --add-port=<port>/tcp --permanent
firewall-cmd --add-port=<port>/udp --permanent
firewall-cmd --reload
```
Поменяйте в конфигурационном файле /etc/rsyslog.conf порты на нужные в следующих строках:
```
input(type="imudp" port="<port>" ruleset="RemoteLogProcess")
...
input(type="imtcp" port="<port>" ruleset="RemoteLogProcess")
```

Перезапустите rsyslog.service и проверьте статус.

systemctl restart rsyslog
systemctl status rsyslog

При необходимости поменять порт, используемый по умолчанию на привилегированный (0-1023) необходимо:

Не рекомендуется менять порт на привилегированный (0-1023), так как эти порты являются зарезервированными для соответствующих служб.

Если нужный порт не открыт, то добавьте его в разрешающие правила firewalld:
```
firewall-cmd --add-port=<port>/tcp --permanent
firewall-cmd --add-port=<port>/udp --permanent
firewall-cmd --reload
```

Настройте SElinux:

setsebool -P nis_enabled 1
setcap 'cap_net_bind_service=+ep' /usr/sbin/rsyslogd (только для Centos 8 Stream)
semanage port -a -t syslogd_port_t -p tcp <port>
semanage port -a -t syslogd_port_t -p udp <port>

Перезапустите rsyslog.service и проверьте статус.
```
systemctl restart rsyslog
systemctl status rsyslog
```

4.2.7.3. Отправка логов Engine

Данная функция доступна только в zVirt версии 3.2 или выше

Для локализации проблем в работе системы zVirt предоставляет возможность отправки журналов Engine для режима установки Hosted engine.

Для включения отправки журналов Engine на syslog-сервер выполните следующие действия.

Порядок действий:

Нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines)
Выделите машину, на которой запущена ВМ HostedEngine и нажмите Изменить (Edit)
В окне Изменить виртуальную машину (Edit virtual machine) Перейдите в раздел Журналирование (Logging)
Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервер журналирования, если порт отличается от стандартного.
Дополнительно: вместо протокола UDP для передачи журналов можно использовать протокол TCP. Для этого отметьте флажком Использовать TCP-соединение (Use TCP connection)
Дополнительно: для обеспечения более безопасного взаимодействия с syslog-сервером можно включить шифрование. Для этого отметьте флажком Включить шифрование (Use TLS protocol)

4.2.7.4. Настройка использования шифрования

Данная функция доступна только в zVirt версии 3.2 или выше

Благодаря поддержке протокола SSL zVirt предоставляет возможность использовать более безопасное взаимодействие с внешним syslog хранилищем.

С помощью симметричного шифрования обеспечивается сохранность конфиденциальности, а коды аутентификации сообщений гарантируют целостность сообщений.

Функцию шифрования можно активировать с помощью опции Включить шифрование (Use TLS protocol) раздела Журналирование (Logging) для кластеров (окна Новый кластер (New Cluster) и Изменить кластер (Edit Cluster)), хостов (окна Новый хост (New Host) и Изменить хост (Edit Host)), а также для ВМ HostedEngine (окно Изменить виртуальную машину (Edit virtual machine)).

Кроме включения опции, потребуется также настройка шифрования. Для этого выполните следующие действия.

В качестве примера будет настроено шифрование для передачи журналов хоста.

ip сервера журналирования - 192.168.48.56
ip хоста - 192.168.40.29
zVirt установлен на машине 192.168.40.30.

Порядок действий:

Настройте журналирование для хоста:
1. Нажмите Ресурсы (Compute) Хосты (Hosts)
2. Выделите нужный хост левой кнопкой мыши и нажмите Изменить (Edit)
3. В появившемся окне Изменить хост (Edit Host) выберите закладку Журналирование (Logging)
4. Отметьте флажком Определить адрес Syslog-сервера (Determine Syslog server address) и введите в ставшее доступным поле ввода IP-адрес сервера журналирования или его полное доменное имя. Через двоеточие - адрес порта, по которому работает сервера журналирования, если порт отличается от стандартного.
5. Отметьте флажком Использовать TCP-соединение (Use TCP connection)
6. Отметьте флажком Включить шифрование (Use TLS protocol)
7. Нажмите ОК
После нажатия кнопки ОК происходит следующее:
- Утилитой openssl на zVirt-машине (192.168.40.30) выполняется генерация и подписание сертификатов для хоста (192.168.40.29) и для сервера журналирования (192.168.48.56).
- Сертификат для хоста (rslclient-192.168.40.29-cert.pem), ключ (rslclient-192.168.40.29-key.pem) и CA-сертификат (rsyslog-ca.pem) сохраняются в каталоге хоста /etc/pki/rsyslog.
- Сертификат для сервера (rslserver-192.168.48.56-cert.pem), ключ (rslserver-192.168.48.56-key.pem) и CA-сертификат (rsyslog-ca.pem) сохраняются в архив (rslserver-192.168.48.56.tar.gz) в каталоге zVirt-машины /etc/pki/ovirt-engine/rsyslog.
Содержимое полученного архива (rslserver-192.168.48.56.tar.gz) расположите в каталоге /etc/pki/rsyslog сервера журналирования. Например, так (команды выполняются на сервере журналирования от имени пользователя root):
scp root@192.168.40.29:/etc/pki/ovirt-engine/rsyslog/rslserver-102.168.48.56.tar.gz /etc/pki/rsyslog cd /etc/pki/rsyslog tar xf rslserver-102.168.48.56.tar.gz
Посмотреть свойства сертификата можно с помощью команды openssl:
openssl x509 -text -noout -in rslserver-102.168.48.56-cert.pem

Заполните конфигурационный файл (/etc/rsyslog.conf) следующим содержимым:

# rsyslog configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# or latest version online at http://www.rsyslog.com/doc/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

module(load="imuxsock"    # provides support for local system logging (e.g. via logger command)
    SysSock.Use="off") # Turn off message reception via local log socket;
            # local messages are retrieved through imjournal now.
module(load="imjournal"         # provides access to the systemd journal
    StateFile="imjournal.state") # File to store the position in the journal
#module(load="imklog") # reads kernel messages (the same are read from journald)
#module(load"immark") # provides --MARK-- message capability

# Increase the amount of open files rsyslog is allowed, which includes open tcp sockets
# This is important if there are many clients.
# http://www.rsyslog.com/doc/rsconf1_maxopenfiles.html
$MaxOpenFiles 2048

# make gtls driver the default
$DefaultNetstreamDriver gtls

$DefaultNetstreamDriverCAFile /etc/pki/rsyslog/rsyslog-ca.pem
$DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslserver-192.168.48.56-cert.pem
$DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslserver-192.168.48.56-key.pem

# Provides UDP syslog reception
# for parameters see http://www.rsyslog.com/doc/imudp.html
module(load="imudp") # needs to be done just once
input(type="imudp" port="514" ruleset="RemoteLogProcess")

# Provides TCP syslog reception
# for parameters see http://www.rsyslog.com/doc/imtcp.html
module(load="imtcp"
    MaxSessions="2000"
    StreamDriver.mode="1"
    StreamDriver.authmode="x509/name"
    PermittedPeer="192.168.40.29" # list ip/fqdn
    ) # needs to be done just once
input(type="imtcp" port="514" ruleset="RemoteLogProcess")

# Шаблон для сохранения логов (/var/log/_ip_/_year-month-day_/_programname_with_catalog_)
template(name="RemoteLogSavePath" type="list") {
    constant(value="/var/log/")
    property(name="fromhost-ip")
    constant(value="/")
    property(name="timegenerated" dateformat="year")
    constant(value="-")
    property(name="timegenerated" dateformat="month")
    constant(value="-")
    property(name="timegenerated" dateformat="day")
    constant(value="/")
    property(name="$.logpath")
}

# Шаблон для вывода только сообщения
template(name="OnlyMsg" type="string" string="%msg:::drop-last-lf%\n")

# Загружаем модуль записи в файл
module(load="builtin:omfile"
    FileOwner="root"
    FileGroup="adm"
    dirOwner="root"
    dirgroup="adm"
    FileCreateMode="0640" DirCreateMode="0755")

# Интерпретировать \n как перевод строки
$EscapeControlCharactersOnReceive off

# Правило для разбора приходящих логов
ruleset(name="RemoteLogProcess") {
    if ( $syslogfacility >= 16 ) then
    {
        # Заменяем __ на /
        set $.logpath = replace($programname, "__", "/");
        # Сохранение в файл:
        # dynaFileCacheSize - максимальное количество открытых сгенерированных лог-файлов
        # dynaFile - правило для генерации имени лог-файла
        # template - шаблон записываемых сообщений
        # flushOnTXEnd - сброс буфера после приема сообщения
        # asyncWriting - асинхронная запись
        # flushInterval - время сброса буфера в секундах
        # ioBufferSize - размер буфера
        action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="OnlyMsg"
        flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
    } else {
        if (($syslogfacility == 0)) then {
            set $.logpath = "kern";
        }
        else if (($syslogfacility == 4) or ($syslogfacility == 10)) then {
            set $.logpath = "auth";
        }
        else if (($syslogfacility == 9) or ($syslogfacility == 15)) then {
            set $.logpath = "cron";
        } else {
            set $.logpath = "syslog";
        }
        action(type="omfile" dynaFileCacheSize="1024" dynaFile="RemoteLogSavePath" template="RSYSLOG_FileFormat"
        flushOnTXEnd="off" asyncWriting="on" flushInterval="1" ioBufferSize="64k")
    }
}

#### GLOBAL DIRECTIVES ####

# Where to place auxiliary files
global(workDirectory="/var/lib/rsyslog")

# Use default timestamp format
#module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")

# Include all config files in /etc/rsyslog.d/
include(file="/etc/rsyslog.d/*.conf" mode="optional")

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

global(debug.gnutls="10" debug.logFile="/var/log/rsyslogdebug.log")

Опция $DefaultNetstreamDriverCAFile указывает на главный сертификат (rsyslog-ca.pem).

Опция $DefaultNetstreamDriverCertFile указывает на сертификат для сервера (rslserver-102.168.48.56-cert.pem).

Опция $DefaultNetstreamDriverKeyFile указывает на ключ для сервера(rslserver-102.168.48.56-key.pem).

Опция PermittedPeer перечисляет разрешенные хосты для приема логов (192.168.40.29).

Перезапустите сервис rsyslog.
```
systemctl restart rsyslog.service
```

Новые логи будут появляться на сервере журналирования в каталоге /var/log/192.168.40.29/

Приложение A: VDSM и хуки

A.1. VDSM

Менеджер управления использует службу VDSM для управления хостами с zVirt Node и RedOS. Служба VDSM управляет и ведет мониторинг хранилища, памяти и сетевых ресурсов хоста. Кроме того, она координирует создание виртуальных машин, сбор статистики, сбор журналов и другие задачи по администрированию хостов. VDSM работает как сервис на каждом хосте под управлением Менеджера управления и отвечает на XML-RPC запросы от клиентов. Менеджер управления функционирует как клиент VDSM.

A.2. Хуки VDSM

Службу VDSM можно расширить с помощью хуков. Хуки – это скрипты, выполняемые на хосте при наступлении ключевых событий. При наступлении предусмотренного события служба VDSM запускает любые исполняемые скрипты хуков в /usr/libexec/vdsm/hooks/nn_event-name/ на хосте в порядке, определяемом их буквенно-цифровыми идентификаторами. Как правило, каждому скрипту хука присвоено двузначное число, которое стоит в начале имени файла, чтобы четко указать, в каком порядке будут выполняться скрипты. Скрипты хуков можно писать на любом языке программирования, но в этой главе даны примеры на Python.

Обратите внимание, что выполняются все скрипты, заданные на хосте для события. Если требуется, чтобы один конкретный хук выполнялся только для определенного подмножества виртуальных машин, работающих на хосте, то убедитесь, что скрипт хука отвечает этому требованию, а для этого надо использовать Пользовательские свойства (Custom Properties), ассоциированные с этой виртуальной машиной.

Хуки VDSM могут мешать работе zVirt. Ошибка в хуке VDSM способна привести к отказу виртуальной машины и потере данных. Хуки VDSM надлежит реализовывать с осторожностью и тщательно проверять. Хуки API – это нововведение, которое будет существенно переработано в будущем.

A.3. Расширение службы VDSM с помощью хуков

В этой главе описано, как расширить службу VDSM с помощью хуков на основе событий. Расширение службы VDSM с помощью хуков – это экспериментальная технология, и настоящая глава адресована опытным разработчикам. Если установить пользовательские свойства на виртуальных машинах, то скриптам хуков можно передать дополнительные параметры, свойственные конкретной виртуальной машине.

A.4. Установка хука VDSM

Хуки VDSM не установлены по умолчанию. Если требуется определенный хук, то его необходимо установить вручную.

Предварительные условия:

Репозиторий на хосте должен быть включен.
Необходимо авторизоваться на хосте в качестве root-пользователя.

Порядок действий:

Выведите список доступных хуков:
```
# dnf list vdsm\*hook\*
```
Установите пакет нужного хука VDSM на хосте:
# dnf install <vdsm-hook-name>
Например, чтобы установить пакет vdsm-hook-vhostmd на хосте, введите следующую команду:
# dnf install vdsm-hook-vhostmd

Дополнительные ресурсы

Настройка репозиториев на zVirt Node

A.5. Предусмотренные события VDSM

Таблица 90. Предусмотренные события VDSM
Имя	Описание
before_vm_start	До запуска виртуальной машины.
after_vm_start	После запуска виртуальной машины.
before_vm_cont	До возобновления работы виртуальной машины.
after_vm_cont	После возобновления работы виртуальной машины.
before_vm_pause	До приостановки виртуальной машины.
after_vm_pause	После приостановки виртуальной машины.
before_vm_hibernate	До перехода виртуальной машины в спящий режим.
after_vm_hibernate	После перехода виртуальной машины в спящий режим.
before_vm_dehibernate	До выхода виртуальной машины из спящего режима.
after_vm_dehibernate	После выхода виртуальной машины из спящего режима.
before_vm_migrate_source	До миграции виртуальной машины, работающей на хосте-источнике, с которого выполняется миграция.
after_vm_migrate_source	После миграции виртуальной машины, работающей на хосте-источнике, с которого выполняется миграция.
before_vm_migrate_destination	До миграции виртуальной машины, работающей на хосте-приемнике, на который выполняется миграция.
after_vm_migrate_destination	После миграции виртуальной машины, работающей на хосте-приемнике, на который выполняется миграция.
after_vm_destroy	После удаления виртуальной машины.
before_vdsm_start	До запуска службы VDSM на хосте. Хуки before_vdsm_start выполняются от имени root-пользователя и не наследуют среду процесса VDSM.
after_vdsm_stop	После остановки службы VDSM на хосте. Хуки after_vdsm_stop выполняются от имени root-пользователя и не наследуют среду процесса VDSM.
before_nic_hotplug	До горячего подключения сетевой карты к виртуальной машине.
after_nic_hotplug	После горячего подключения сетевой карты к виртуальной машине.
before_nic_hotunplug	До горячего отключения сетевой карты от виртуальной машины.
after_nic_hotunplug	После горячего отключения сетевой карты от виртуальной машины.
after_nic_hotplug_fail	После неудачной попытки горячего подключения сетевой карты к виртуальной машине.
after_nic_hotunplug_fail	После неудачной попытки горячего отключения сетевой карты от виртуальной машины.
before_disk_hotplug	До горячего подключения диска к виртуальной машине.
after_disk_hotplug	После горячего подключения диска к виртуальной машине.
before_disk_hotunplug	До горячего отключения диска от виртуальной машины.
after_disk_hotunplug	После горячего отключения диска от виртуальной машины.
after_disk_hotplug_fail	После неудачной попытки горячего подключения диска к виртуальной машине.
after_disk_hotunplug_fail	После неудачной попытки горячего отключения диска от виртуальной машины.
before_device_create	До создания устройства, поддерживающего пользовательские свойства.
after_device_create	После создания устройства, поддерживающего пользовательские свойства.
before_update_device	До обновления устройства, поддерживающего пользовательские свойства.
after_update_device	После обновления устройства, поддерживающего пользовательские свойства.
before_device_destroy	До удаления устройства, поддерживающего пользовательские свойства.
after_device_destroy	После удаления устройства, поддерживающего пользовательские свойства.
before_device_migrate_destination	До миграции устройства, работающего на хосте-приемнике, на который выполняется миграция.
after_device_migrate_destination	После миграции устройства, работающего на хосте-приемнике, на который выполняется миграция.
before_device_migrate_source	До миграции устройства, работающего на хосте-источнике, с которого выполняется миграция.
after_device_migrate_source	После миграции устройства, работающего на хосте-источнике, с которого выполняется миграция.
after_network_setup	После настройки сети при запуске хоста.
before_network_setup	До настройки сети при запуске хоста.

A.6. Среда хуков VDSM

Большинство скриптов хуков выполняются от имени пользователя vdsm и наследуют среду процесса VDSM. Исключение составляют те скрипты хуков, которые запускаются событиями before_vdsm_start и after_vdsm_stop. Скрипты хуков, которые запускаются этими событиями, выполняются от имени root-пользователя и не наследуют среду процесса VDSM.

A.7. XML-объект домена хука VDSM

Когда запускаются скрипты хуков, переменная _hook_domxml добавляется к среде. В этой переменной указан путь к XML-представлению домена libvirt соответствующей виртуальной машины. Несколько перечисленных ниже хуков составляют исключение из этого правила. Переменная _hook_domxml перечисленных ниже хуков содержит XML-представление сетевой карты, а не виртуальной машины.

*nic_hotplug*
*nic_hotunplug*
*_update_device
*_device_create
*device_migrate*

Сейчас хуки before_migration_destination и before_dehibernation получают XML-представление домена от хоста-источника. В XML-представлении домена на хосте-приемнике будет несколько отличий.

Формат XML-представления домена libvirt используется службой VDSM для определения виртуальных машин. Подробнее о формате XML-представления домена libvirt см. на веб-сайте. Идентификатор UUID виртуальной машины можно логически вывести из XML-представления домена, а также получить из переменной среды vmId.

A.8. Установка пользовательских свойств

Пользовательские свойства, принятые Менеджером управления, и соответственно передаваемые пользовательским хукам, можно задать с помощью команды engine-config. Выполните команду от имени root-пользователя на том хосте, на котором установлен Менеджер управления.

Ключи конфигурации UserDefinedVMProperties и CustomDeviceProperties применяются для хранения имен поддерживаемых пользовательских свойств. Регулярные выражения, задающие допустимые значения для каждого именованного пользовательского свойства, тоже содержатся в этих ключах конфигурации.

Пользовательские свойства отделяются друг от друга точкой с запятой. Обратите внимание, что при настройке ключа конфигурации все уже содержащиеся в нем значения будут перезаписаны. При комбинировании новых и уже существующих пользовательских свойств необходимо добавить все пользовательские свойства, которые в команде задавали значение ключа.

После обновления ключа конфигурации необходимо перезапустить службу ovirt-engine, чтобы новые значения вступили в силу.

Пример 47. Свойства виртуальной машины: установка пользовательского свойства смарт-карта (smartcard)

Проверьте существующие пользовательские свойства, заданные ключом конфигурации UserDefinedVMProperties, с помощью следующей команды:
# engine-config -g UserDefinedVMProperties
В выводе ниже показано, что пользовательское свойство память (memory) уже задано. Регулярное выражение ^[0-9]+$ гарантирует, что в пользовательском свойстве всегда будут содержаться только цифры.
# engine-config -g UserDefinedVMProperties UserDefinedVMProperties: version: 4.3 UserDefinedVMProperties: version: 4.4 UserDefinedVMProperties : memory=^[0-9]+$ version: 4.4
Поскольку пользовательское свойство memory уже задано в ключе конфигурации UserDefinedVMProperties, новое пользовательское свойство должно быть добавлено к нему. Дополнительное пользовательское свойство smartcard добавляется к значению ключа конфигурации. Новое пользовательское свойство может принимать значения true или false.
```
# engine-config -s UserDefinedVMProperties='memory=^[0-9]+$;smartcard=^(true|false)$' --cver=4.4
```
Убедитесь, что пользовательские свойства, заданные ключом конфигурации UserDefinedVMProperties, были обновлены корректно.
```
# engine-config -g UserDefinedVMProperties
UserDefinedVMProperties:  version: 4.3
UserDefinedVMProperties:  version: 4.4
UserDefinedVMProperties : memory=^[0-9]+$;smartcard=^(true|false)$ version: 4.4
```
В конце требуется перезапустить службу ovirt-engine, чтобы изменения конфигурации вступили в силу.
```
# systemctl restart ovirt-engine.service
```

Пример 48. Свойства устройств: установка пользовательского свойства интерфейс (interface)

Проверьте существующие пользовательские свойства, заданные ключом конфигурации CustomDeviceProperties, с помощью следующей команды:
# engine-config -g CustomDeviceProperties
В выводе ниже показано, что пользовательские свойства еще не заданы.
# engine-config -g CustomDeviceProperties CustomDeviceProperties: version: 4.3 CustomDeviceProperties: version: 4.4
Пользовательское свойство interface ещё не существует, поэтому его можно добавить "как есть". В этом примере значение подсвойства speed указано в диапазоне от 0 до 99999, а значение подсвойства duplex установлено на выбор либо full, либо half.
```
# engine-config -s CustomDeviceProperties="{type=interface;prop={speed=^([0-9]{1,5})$;duplex=^(full|half)$}}" --cver=4.4
```

Убедитесь, что пользовательские свойства, заданные ключом конфигурации CustomDeviceProperties, были обновлены корректно.

# engine-config -g CustomDeviceProperties
UserDefinedVMProperties:  version: 4.3
UserDefinedVMProperties:  version: 4.4
UserDefinedVMProperties : {type=interface;prop={speed=^([0-9]{1,5})$;duplex=^(full|half)$}} version: 4.4

В конце требуется перезапустить службу ovirt-engine, чтобы изменения конфигурации вступили в силу.
```
# systemctl restart ovirt-engine.service
```

A.9. Настройка пользовательских свойств на виртуальной машине

Когда пользовательские свойства заданы в Менеджере управления, можно приступить к их настройке на виртуальных машинах. Пользовательские свойства настраиваются на вкладке Пользовательские свойства (Custom Properties) в окнах Новая виртуальная машина (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine) на Портале администрирования.

Кроме того, пользовательские свойства можно настроить в диалоговом окне Запустить ВМ (Run Virtual Machine(s)). Пользовательские свойства, заданные в диалоговом окне Запустить ВМ (Run Virtual Machine(s)), будут применяться к виртуальным машинам только до следующего выключения.

Вкладка Пользовательские свойства (Custom Properties) предоставляет возможность выбирать из списка заданных пользовательских свойств. После выбора ключа пользовательского свойства появится дополнительное поле, в котором можно задать значение этого ключа. Нажимая plus big и minus big , добавляйте или удаляйте пары ключ/значение.

A.10. Оценка пользовательских свойств на виртуальных машинах в хуке VDSM

Каждый набор ключей в поле Пользовательские свойства (Custom Properties) для виртуальной машины добавляется как переменная среды при вызове скриптов хука. Хотя регулярные выражения, используемые для проверки поля Пользовательские свойства (Custom Properties) дают некоторую защиту, необходимо убедиться, что скрипты также проверяют вводимые данные на соответствие ожиданиям.

Пример 49. Оценка пользовательских свойств

Далее в коротком примере на языке Python проверяется наличие пользовательского свойства key1. Если пользовательское свойство задано, то выдается стандартная ошибка. Если пользовательское свойство не задано, то ничего не произойдет.

#!/usr/bin/python

import os
import sys

if os.environ.has_key('key1'):
  sys.stderr.write('key1 value was : %s\n' % os.environ['key1'])
else:
  sys.exit(0)

A.11. Использование модуля хукинга VDSM

VDSM поставляется с модулем хукинга Python, в котором предоставлены вспомогательные функции для скриптов хука VDSM. Этот модуль предоставляется в качестве примера и касается только хуков VDSM, написанных на Python.

Модуль хукинга поддерживает чтение XML-представления libvirt виртуальной машины в объект DOM. Затем скрипты хуков могут использовать встроенную в Python библиотеку xml.dom для работы с объектом.

Измененный объект можно затем сохранить обратно в XML-представление libvirt с помощью модуля хукинга. Модуль хукинга предоставляет следующие функции для поддержки разработки хуков:

Таблица 91. Функции модуля хукинга
Имя	Аргумент	Описание
`tobool`	строка	Конвертирует строку "true" или "false" в логическое значение
`read_domxml`	-	Считывает XML-представление libvirt виртуальной машины в объект DOM
`write_domxml`	объект DOM	Записывает XML-представление libvirt виртуальной машины из объекта DOM

A.12. Выполнение хуков VDSM

Скрипты before_vm_start могут изменить XML-представление домена, чтобы изменить определение настроек VDSM виртуальной машины до того, как оно достигнет libvirt. При этом необходимо проявлять осторожность. Скрипты хуков способны нарушить работу VDSM, а дефектные скрипты могут привести к сбоям среды zVirt. В частности, никогда не изменяйте идентификатор UUID домена и не пытайтесь удалить устройство из домена без достаточных знаний и опыта.

Оба скрипта хуков before_vdsm_start и after_vdsm_stop выполняются от имени root-пользователя. Остальные скрипты хуков, для которых требуется root-доступ в систему, должны быть записаны, чтобы использовать команду sudo для повышения привилегий. Для этого необходимо обновить /etc/sudoers, чтобы позволить пользователю vdsm использовать команду sudo без повторного введения пароля. Это необходимо, т.к. скрипты хуков выполняются не в интерактивном режиме.

Пример 50. Конфигурирование командыsudo для хуков VDSM

В этом примере команда sudo будет сконфигурирована так, чтобы позволить пользователю vdsm выполнить команду /bin/chown от имени root-пользователя.

Авторизуйтесь на хосте виртуализации как root-пользователь.
Откройте файл /etc/sudoers в текстовом редакторе.
Вставьте в файл следующую строку:
vdsm ALL=(ALL) NOPASSWD: /bin/chown
Тут указано, что пользователь vdsm может выполнить команду /bin/chown от имени root-пользователя. Параметр NOPASSWD указывает на то, что у пользователя не будет запрошен пароль при вызове команды sudo.

После внесения этого изменения в конфигурацию хуки VDSM смогут задействовать команду sudo для выполнения /bin/chown от имени root-пользователя. В этом коде Python используется команда sudo для выполнения /bin/chown от имени root-пользователя в файле /my_file.

retcode = subprocess.call( ["/usr/bin/sudo", "/bin/chown", "root", "/my_file"] )

Стандартный поток сообщений об ошибках скриптов хуков собирается в журнал VDSM. Эта информация используется для отладки скриптов хуков.

A.13. Коды возврата хука VDSM

Скрипты хуков должны возвращать один из кодов возврата. Код возврата определяет, будут ли дальнейшие скрипты хуков обрабатываться VDSM.

Таблица 92. Коды возврата хука
Код	Описание
0	Скрипт хука успешно выполнен
1	Скрипт хука завершился сбоем, необходимо обработать другие хуки
2	Скрипт хука завершился сбоем, другие хуки не обрабатывать
>2	Зарезервировано

A.14. Примеры хуков VDSM

Примеры скриптов хуков, представленные в этом разделе, необязательно поддерживаются zVirt. Убедитесь, что абсолютно все скрипты хуков, установленные в системе, независимо от источника, тщательно протестированы для работы в вашей среде.

Пример 51. Настройка узлов NUMA

Этот скрипт хука позволяет настраивать выделение памяти на хосте NUMA на основании пользовательского свойства numaset. Если пользовательское свойство не задано, то ничего не произойдет.

Строка конфигурирования:

numaset=^(interleave|strict|preferred):[\^]?\d+(-\d+)?(,[\^]?\d+(-\d+)?)*$

Используемое регулярное выражение позволяет пользовательскому свойству numaset на конкретной виртуальной машине указать режим выделения (interleave, strict, preferred) и используемый узел. Два значения отделяются двоеточием (:). Регулярное выражение позволяет задать в качестве nodeset:

один конкретный узел (numaset=strict:1: указывает, что будет задействован только узел 1)
диапазон узлов (numaset=strict:1-4: указывает, что будут задействованы узлы 1–4)
только не этот конкретный узел (numaset=strict:^3: указывает, что не будет задействован узел 3)
любую комбинацию вышеуказанных вариантов через запятую (numaset=strict:1-4,6: указывает, что задействованы узлы 1–4 и 6).

Скрипт:

/usr/libexec/vdsm/hooks/before_vm_start/50_numa
#!/usr/bin/python

import os
import sys
import hooking
import traceback

'''
numa hook
=========
add numa support for domain xml:

<numatune>
    <memory mode="strict" nodeset="1-4,^3" />
</numatune>

memory=interleave|strict|preferred

numaset="1" (use one NUMA node)
numaset="1-4" (use 1-4 NUMA nodes)
numaset="^3" (don't use NUMA node 3)
numaset="1-4,^3,6" (or combinations)

syntax:
    numa=strict:1-4
'''

if os.environ.has_key('numa'):
    try:
        mode, nodeset = os.environ['numa'].split(':')

        domxml = hooking.read_domxml()

        domain = domxml.getElementsByTagName('domain')[0]
        numas = domxml.getElementsByTagName('numatune')

        if not len(numas) 0:
            numatune = domxml.createElement('numatune')
            domain.appendChild(numatune)

            memory = domxml.createElement('memory')
            memory.setAttribute('mode', mode)
            memory.setAttribute('nodeset', nodeset)
            numatune.appendChild(memory)

            hooking.write_domxml(domxml)
        else:
            sys.stderr.write('numa: numa already exists in domain xml')
            sys.exit(2)
    except:
        sys.stderr.write('numa: [unexpected error]: %s\n' % traceback.format_exc())
        sys.exit(2)

Приложение B: Пользовательские свойства сети

B.1. Описание параметров bridge_opts

Таблица 93. Параметры bridge_opts**
Параметр	Описание
`forward_delay`	Задает время (в десятых долях секунды), которое мост будет проводить в состояниях прослушивания и обучения. Если за это время цикл коммутации не будет обнаружен, мост перейдет в состояние перенаправления. Это позволяет успеть проверить трафик и конфигурацию сети перед нормальной эксплуатацией.
`group_addr`	Для отправки общего запроса установите это значение в 0. Для отправки запросов, относящихся к конкретной группе и к конкретным группе и источнику, задайте в качестве этого значения 6-байтовый MAC-адрес, а не IP-адрес. Допустимые значения: 01:80:C2:00:00:0x, за исключением 01:80:C2:00:00:01, 01:80:C2:00:00:02 и 01:80:C2:00:00:03.
`group_fwd_mask`	Включает мост для передачи адресов локальной группы по каналу. Изменение этого заданного по умолчанию значения позволит задать нестандартное поведение моста (bridge).
`hash_max`	Максимальное количество бакетов в хэш-таблице. Этот параметр вступает в силу немедленно и не может быть установлен в значение меньше текущего количества записей в мультивещательной группе. Значение должно быть степенью двойки.
`hello_time`	Задает интервал времени (в десятых долях секунды) между отправкой приветственных сообщений, анонсирующих позицию моста в топологии сети. Применяется, только если этот мост является корневым мостом связующего дерева (Spanning Tree).
`max_age`	Задает максимальное время (в десятых долях секунды) для получения приветственного сообщения от другого корневого моста, прежде чем этот мост будет сочтен неработающим и начнется процесс переключения.
`multicast_last_member_count`	Задает количество запросов "последнего члена", отправляемых в мультивещательную группу после получения от хоста сообщения "покинуть группу".
`multicast_last_member_interval`	Задает время (в десятых долях секунды) между запросами "последнего члена".
`multicast_membership_interval`	Задает время (в десятых долях секунды), в течение которого мост будет ждать ответа от члена мультивещательной группы, прежде чем прекратит отправку мультивещательного трафика на хост.
`multicast_querier`	Указывает, будет ли мост активно запускать формирователь мультивещательных запросов. Когда мост получает запрос "членства на мультивещательном хосте" от другого хоста сети, этот хост отслеживается, исходя из времени получения запроса и длительности интервала мультивещательного запроса. Если позже мост попытается перенаправить трафик для этой мультивещательной группы или обменивается данными с запрашивающим мультивещательным маршрутизатором, то этот таймер подтверждает корректность формирователя запросов. Если корректность подтверждена, мультивещательный трафик доставляется через имеющуюся на мосте таблицу членства в мультивещательной группе, в противном случае трафик отправляется через все порты моста.Широковещательные домены с членством в мультивещательной группе (или ожидающие такого членства) должны иметь по крайней мере один работающий формирователь мультивещательных запросов для повышения производительности.
`multicast_querier_interval`	Задает максимальное время (в десятых долях секунды) между последним запросом "членства на мультивещательном хосте", полученным от хоста, чтобы убедиться в его корректности.
`multicast_query_use_ifaddr`	Логическое выражение. Значение по умолчанию равно нулю, и в этом случае формирователь запросов использует 0.0.0.0 в качестве адреса-источника для сообщений IPv4. Изменение этого значения задает IP-адрес моста в качестве адреса-источника.
`multicast_query_interval`	Задает время (в десятых долях секунды) между запросами-сообщениями, отправляемыми мостом для проверки действительности членства в мультивещательной группе. В это время (или если от моста запросят отправить мультивещательный запрос на такое членство) мост проверяет состояние своего собственного формирователя мультивещательных запросов, исходя из времени, когда была запрошена проверка, плюс `multicast_query_interval`. Если мультивещательный запрос на такое членство был отправлен в течение последнего интервала `multicast_query_interval`, то он не отправляется повторно.
`multicast_query_response_interval`	Время (в десятых долях секунды), в течение которого хосту разрешено отвечать на запрос после его отправки.Не должно превышать значения `multicast_query_interval`.
`multicast_router`	Позволяет включать или выключать порты при подключении мультивещательных маршрутизаторов. Порт с одним или несколькими мультивещательными маршрутизаторами будет получать весь мультивещательный трафик. Значение 0 полностью отключает, 1 позволяет системе автоматически определять наличие маршрутизаторов, основываясь на запросах, а 2 позволяет портам всегда получать весь мультивещательный трафик.
`multicast_snooping`	Включает/выключает слежение. Слежение позволяет мосту прослушивать сетевой трафик между маршрутизаторами и хостами, чтобы поддерживать карту для фильтрации мультивещательного трафика по соответствующим каналам.Этот параметр позволяет пользователю повторно включить слежение, если оно было автоматически выключено из-за конфликта хэширования, однако слежение невозможно повторно включить, если конфликт хэширования не был разрешен.
`multicast_startup_query_count`	Задает количество запросов, отправляемых при запуске для определения информации о членстве.
`multicast_startup_query_interval`	Задает время (в десятых долях секунды) между запросами, отправляемыми при запуске для определения информации о членстве.

B.2. Как настроить Менеджер управления для использования ethtool

Свойства ethtool для сетевых карт хоста можно настроить на Портале администрирования. Ключ ethtool_opts недоступен по умолчанию – его нужно добавить в Менеджер управления, используя инструмент настройки engine. Кроме того, необходимо установить на хосты соответствующий пакет хуков VDSM.

Добавление ключа ethtool_opts в Менеджер управления

Чтобы добавить ключ, в Менеджере управления запустите следующую команду:
```
# engine-config -s UserDefinedNetworkCustomProperties=ethtool_opts=.* --cver=4.4
```
Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```
На хостах, где необходимо настроить свойства ethtool, установите пакет хуков VDSM.
```
# dnf install vdsm-hook-ethtool-options
```

Теперь ключ ethtool_opts доступен на Портале администрирования. Узнать о том, как применять свойства ethtool к логическим сетям, можно в разделе Изменение сетевых интерфейсов хоста и назначение логических сетей хостам.

B.3. Как настроить Менеджер управления для использования FCoE

Свойства Fibre Channel over Ethernet (FCoE) для сетевых карт хоста можно настроить на Портале администрирования. Ключ fcoe недоступен по умолчанию – его нужно добавить в Менеджер управления, используя инструмент настройки engine. Чтобы выяснить, не включен ли уже ключ fcoe, выполните следующую команду:

# engine-config -g UserDefinedNetworkCustomProperties

Кроме того, необходимо установить на хосты соответствующий пакет хуков VDSM. В зависимости от карты FCoE на хостах может также потребоваться специальная конфигурация.

Порядок действий:

Чтобы добавить ключ, в Менеджере управления запустите следующую команду:
```
# engine-config -s UserDefinedNetworkCustomProperties='fcoe=^((enable|dcb|auto_vlan)=(yes|no),?)*$'
```
Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```
Установите пакет хуков VDSM на каждый хост, на котором необходимо настроить свойства FCoE. Пакет доступен по умолчанию на хостах с zVirt Node.
```
# dnf install vdsm-hook-fcoe
```

Теперь ключ fcoe доступен на Портале администрирования. Узнать о том, как применять свойства FCoE к логическим сетям, можно в разделе Изменение сетевых интерфейсов хоста и назначение логических сетей хостам.

Приложение C: Плагины пользовательского интерфейса zVirt

C.1. Общие сведения о плагинах пользовательского интерфейса zVirt

zVirt поддерживает плагины, предоставляющие нестандартные функции. Это упрощает использование Портала администрирования для интеграции с другими системами. Каждый плагин интерфейса представляет собой набор расширений пользовательского интерфейса, которые могут упаковываться и распространяться для использования с zVirt.

Плагины пользовательского интерфейса zVirt интегрируются с Порталом администрирования прямо на клиенте с помощью языка программирования JavaScript. Плагины вызываются Порталом администрирования и выполняются в среде выполнения JavaScript в веб-браузере. Плагины пользовательского интерфейса могут использовать язык JavaScript и его библиотеки.

Если во время выполнения наступают какие-либо ключевые события, Портал администрирования вызывает отдельные плагины с помощью функций обработчика событий, обеспечивающих связь между Порталом администрирования и плагином. Хотя Портал администрирования поддерживает несколько функций обработчика событий, плагин декларирует только те функции, который представляют интерес с точки зрения его реализации. Каждый плагин должен зарегистрировать соответствующие функции обработчика событий в ходе начальной загрузки, прежде чем плагин будет использоваться Порталом администрирования.

Чтобы облегчить взаимодействие между плагином и Порталом администрирования, в результате которого запускается расширение пользовательского интерфейса, Портал администрирования предоставляет API плагина как глобальный (верхнеуровневый) объект pluginApi JavaScript, который могут использовать отдельные плагины. Каждый плагин получает отдельный экземпляр pluginApi, что позволяет Порталу администрирования управлять вызовом API-функций каждого плагина на протяжении его жизненного цикла.

C.2. Жизненный цикл плагина пользовательского интерфейса zVirt

Основной жизненный цикл плагина пользовательского интерфейса делится на три стадии:

Обнаружение плагина.
Загрузка плагина.
Начальный запуск плагина.

C.2.1. Обнаружение плагина пользовательского интерфейса zVirt

Создание дескрипторов плагинов – первый шаг процесса обнаружения плагинов. Дескрипторы плагинов содержат важные метаданные плагинов и необязательные конфигурации по умолчанию для конкретных плагинов.

В рамках обработки запросов к HTML-страницам Портала администрирования (HTTP GET) инфраструктура плагинов пользовательского интерфейса пытается обнаружить и загрузить дескрипторы плагинов из локальной файловой системы. Для каждого дескриптора плагина инфраструктура также пытается загрузить соответствующие пользовательские конфигурации плагина, используемые для переопределения конфигураций конкретных плагинов по умолчанию (если они есть) и подстройки поведения плагина во время выполнения. Пользовательская конфигурация плагина является необязательной. После загрузки дескрипторов и соответствующих пользовательских файлов конфигурации oVirt Engine собирает данные плагинов пользовательского интерфейса и встраивает их в HTML-страницу Портала администрирования для оценки во время выполнения.

По умолчанию дескрипторы плагинов находятся в $ENGINE_USR/ui-plug-ins с сопоставлением по умолчанию ENGINE_USR=/usr/share/ovirt-engine, как определено локальной конфигурацией oVirt Engine. Ожидается, что дескрипторы плагинов будут соответствовать спецификациям формата JSON, но дескрипторы плагинов делают возможными комментарии в стиле Java/C++ (разновидностей /* и //) в дополнение к спецификациям формата JSON.

По умолчанию пользовательские файлы конфигурации плагина находятся в $ENGINE_ETC/ui-plug-ins с сопоставлением по умолчанию ENGINE_ETC=/etc/ovirt-engine, как определено локальной конфигурацией oVirt Engine. Ожидается, что пользовательские файлы конфигурации плагина будут соответствовать тем же правилам в отношении формата содержимого, что и дескрипторы плагина.

Пользовательские файлы конфигурации плагина обычно соответствуют соглашению о присвоении имен <descriptorFileName>-config.json.

C.2.2. Загрузка плагина пользовательского интерфейса zVirt

После обнаружения плагина и встраивания его данных в HTML-страницу Портала администрирования Портал администрирования пытается загрузить плагин при запуске приложения (если только он не настроен так, чтобы не загружаться при запуске приложения).

Для каждого обнаруженного плагина Портал администрирования создает элемент HTML iframe, используемый для загрузки его хост-страницы. Хост-страница плагина необходима для инициации процесса начального запуска плагина, и этот процесс начального запуска используется для оценки кода плагина в контексте плагина элемента iframe. Инфраструктура плагинов пользовательского интерфейса поддерживает обслуживание ресурсных файлов плагина (таких как хост-страница плагина) из локальной файловой системы. Хост-страница плагина загружается в элемент iframe, и код плагина подвергается оценке. После оценки кода плагина он связывается с Порталом администрирования посредством API плагина.

C.2.3. Начальный запуск плагина пользовательского интерфейса zVirt

Типовой процесс начального запуска состоит из следующих шагов:

Процесс начального запуска плагина

Получить экземпляр pluginApi для данного плагина
Получить объект конфигурации плагина для среды выполнения (необязательно)
Зарегистрировать соответствующие функции обработчика событий
Сообщить инфраструктуре плагинов пользовательского интерфейса о необходимости продолжить инициализацию плагина

Следующий фрагмент кода иллюстрирует вышеупомянутые шаги на практике:

// Access plug-in API using 'parent' due to this code being evaluated within the context of an iframe element.
// As 'parent.pluginApi' is subject to Same-Origin Policy, this will only work when WebAdmin HTML page and plug-in
// host page are served from same origin. WebAdmin HTML page and plug-in host page will always be on same origin
// when using UI plug-in infrastructure support to serve plug-in resource files.
var api = parent.pluginApi('MyPlugin');

// Runtime configuration object associated with the plug-in (or an empty object).
var config = api.configObject();

// Register event handler function(s) for later invocation by UI plug-in infrastructure.
api.register({
     // UiInit event handler function.
  UiInit: function() {
    // Handle UiInit event.
     window.alert('Favorite music band is ' + config.band);
         }
});

// Notify UI plug-in infrastructure to proceed with plug-in initialization.
api.ready();

C.3. Файлы, относящиеся к плагинам пользовательского интерфейса, и пути к этим файлам

Таблица 94. Файлы, относящиеся к плагинам пользовательского интерфейса, и пути к этим файлам
Файл	Путь	Примечания
Файлы дескрипторов плагинов (метаданные)	/usr/share/ovirt-engine/ui-plugins/my-plugin.json
Пользовательские файлы конфигурации плагинов	/etc/ovirt-engine/ui-plugins/my-plugin-config.json
Ресурсные файлы плагинов	/usr/share/ovirt-engine/ui-plugins/<resourcePath>/PluginHostPage.html	<resourcePath> определяется соответствующим атрибутом в дескрипторе плагина.

C.4. Пример развертывания плагина пользовательского интерфейса

Следуйте этим инструкциям, чтобы создать плагин пользовательского интерфейса, запускающий программу Hello World! при авторизации на Портале администрирования Менеджера управления.

Развертывание плагина Hello World!

Создайте дескриптор плагина, создав следующий файл в Менеджере управления по пути /usr/share/ovirt-engine/ui-plugins/helloWorld.json:
```
{
    "name": "HelloWorld",
    "url": "/ovirt-engine/webadmin/plugin/HelloWorld/start.html",
    "resourcePath": "hello-files"
}
```
Создайте хост-страницу плагина, создав следующий файл в Менеджере управления по пути /usr/share/ovirt-engine/ui-plugins/hello-files/start.html:
```
<!DOCTYPE html><html><head>
<script>
var api = parent.pluginApi('HelloWorld');
api.register({
    UiInit: function() { window.alert('Hello world'); }
});
api.ready();
</script>
</head><body></body></html>
```

Если плагин Hello World! успешно реализован, то при авторизации на Портале администрирования вы увидите этот экран:

Рисунок 24. Успешная реализация плагина Hello World!

Приложение D: Включение FIPS в zVirt

zVirt можно настроить в соответствии с Федеральным стандартом обработки информации (FIPS), в частности FIPS 140-2. Можно включить режим FIPS выборочно, на определенных виртуальных машинах, машинах без ОС ("bare metal") или во всей среде в зависимости от требований организации к обеспечению соответствия FIPS.

В zVirt машину без ОС с поддержкой FIPS можно создать либо установкой ОС в режиме FIPS, либо переключением системы в режим FIPS после установки ОС. Однако, чтобы избежать системных конфликтов, перед установкой и настройкой zVirt необходимо переключиться в режим FIPS.

Рекомендуется устанавливать Linux при включенном режиме FIPS, а не включать режим FIPS позже. Включение режима FIPS во время установки гарантирует, что система будет генерировать все ключи с помощью алгоритмов, одобренных FIPS, и проводить непрерывное тестирование и мониторинг.

Сначала включите FIPS на каждой машине без ОС, а затем – в Менеджере управления.

Включение FIPS в hosted engine
Включение FIPS в zVirt Node
Настройка хостов FIPS с помощью Менеджера управления

D.1. Включение FIPS в hosted engine

Можно включить FIPS в hosted engine во время развертывания с помощью командной строки.

Порядок действий:

Запустите скрипт развертывания hosted engine. См. Развертывание менеджера управления в режиме Hosted Engine c помощью командной строки.
Когда скрипт развертывания выведет запрос Do you want to apply a default OpenSCAP security profile?, введите Yes
Следуя инструкциям на экране, выберите VPP - профиль защиты для Virtualization 1.0 для Red Hat Enterprise Linux Hypervisor (RHELH) (VPP - Protection Profile for Virtualization 1.0 for Red Hat Enterprise Linux Hypervisor (RHELH)).

Проверка:

Убедитесь, что FIPS включен, введя команду fips-mode-setup --check `на хосте. Команда должна вернуть `FIPS mode is enabled:

# fips-mode-setup --check
FIPS mode is enabled.

D.2. Включение FIPS в zVirt Node

Режим FIPS можно включить при установке zVirt Node. zVirt не поддерживает перевод предоставленной машины с zVirt Node в режим FIPS.

zVirt Node поставляется как единый образ системы. Если вы выберете дополнительные профили безопасности, пакеты которых не входят в этот образ системы, их установка может оказаться невозможной.

Порядок действий:

Загрузите и начните устанавливать zVirt Node.
Когда установщик выведет Резюме установки (Installation Summary), нажмите Политика безопасности (Security Policy).
Нажмите профиль VPP - профиль защиты для Virtualization 1.0 для zVirt Node (VPP - Protection Profile for Virtualization 1.0 for zVirt Node).
Нажмите Выбрать профиль (Select profile), установите параметр Применить политику безопасности (Apply security policy) в значение Включен (On) и нажмите Готово (Done).
На экране Резюме установки (Installation Summary) убедитесь, что параметр Политика безопасности (Security Policy) имеет статус Все в порядке (Everything okay), и завершите процесс установки.

Проверка:

Убедитесь, что FIPS включен, введя команду fips-mode-setup --check на хосте. Команда должна вернуть FIPS mode is enabled:

# fips-mode-setup --check
FIPS mode is enabled.

D.3. Настройка хостов FIPS с помощью Менеджера управления

После включения режима FIPS на каждой машине хоста необходимо настроить хосты в Менеджере управления.

Порядок действий:

На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
Выберите хост, нажмите Изменить (Edit) и в окне Изменить хост (Edit Host) выберите вкладку Ядро (Kernel).
Если в разделе Параметры загрузки ядра (Kernel boot parameters) флажки неактивны, нажмите Сброс (Reset).
Установите флажок в поле Режим FIPS (FIPS mode) и нажмите OK.
Выберите хост и нажмите Управление (Management) → Обслуживание (Maintenance), а затем OK.
Когда хост находится в режиме обслуживания, выберите хост и нажмите Настройки (Installation) → Переустановить (Reinstall).
После переустановки выберите хост и нажмите Управление (Management) → Перезапустить (Restart).
После перезагрузки выберите хост и нажмите Настройки (Installation) → Регистрация сертификата (Enroll certificate).
Нажмите Блок уведомлений (Notification Drawer) и проверьте раздел События (Events). Дождитесь успешного завершения регистрации сертификата для хоста.
Выберите хост и нажмите Управление (Management) → Включить (Activate).
Повторите эти шаги для каждого хоста в кластере.

D.4. Дополнительные ресурсы

Установка хоста виртуализации
Политики безопасности, доступные в Руководстве по безопасности SCAP

Приложение E: zVirt и шифрованная связь

E.1. Замена сертификата Менеджера управления, выданного Центром сертификации

Не изменяйте разрешения и параметры владения для каталога /etc/pki и его подкаталогов. Разрешение для каталога /etc/pki и /etc/pki/ovirt-engine должно оставаться в значении по умолчанию: 755.

Вы можете настроить в своей организации сертификат, выданный альтернативным Центром сертификации, чтобы идентифицировать Менеджер управления для пользователей, подключающихся через HTTPS.

Использование сертификата, выданного альтернативным Центром сертификации, для HTTPS-подключений не влияет на сертификат, используемый для аутентификации между Менеджером управления и хостами. Они будут продолжать использовать самоподписанный сертификат, созданный Менеджером управления.

Предварительные условия:

Сертификат, выданный альтернативным Центром сертификации. Это сертификат, который выдал Центр сертификации и который вы хотите использовать. Он предоставляется как файл PEM. Цепочка сертификатов должна быть полной вплоть до корневого сертификата. Порядок сертификатов в цепочке имеет решающее значение и должен быть от последнего промежуточного сертификата до корневого сертификата. В этой процедуре предполагается, что сертификат альтернативного Центра сертификации предоставляется в файле /tmp/3rd-party-ca-cert.pem.
Закрытый ключ, который вы хотите использовать для Apache httpd. Он не должен иметь пароля. В этой процедуре предполагается, что он находится в файле /tmp/apache.key. Этот сертификат выпущен Центром сертификации. В этой процедуре предполагается, что он находится в файле /tmp/apache.cer.

Если вы получили закрытый ключ и сертификат от вашего Центра сертификации в файле P12, то для их извлечения используйте следующую процедуру. Если файл в другом формате, свяжитесь с вашим Центром сертификации. После извлечения закрытого ключа и сертификата перейдите к Замене сертификата Менеджера управления, выданного Центром Сертификации Apache.

Извлечение сертификата и закрытого ключа из пакета P12

Внутренний Центр сертификации хранит сгенерированный внутренними средствами ключ и сертификат в файле P12 /etc/pki/ovirt-engine/keys/apache.p12. Храните новый файл в том же месте. В следующей процедуре предполагается, что новый файл P12 находится в /tmp/apache.p12.

Сделайте резервную копию текущего файла apache.p12:

# cp -p /etc/pki/ovirt-engine/keys/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12.bck

Замените текущий файл новым:

# cp /tmp/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12

Извлеките закрытый ключ и сертификат по соответствующим путям. Если файл защищен паролем, добавьте -passin pass:_password_, заменив password необходимым паролем.
```
# openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nocerts -nodes > /tmp/apache.key
# openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nokeys > /tmp/apache.cer
```

Для новых установок zVirt необходимо выполнить все шаги этой процедуры.

Замена сертификата Менеджера управления, выданного Центром Сертификации Apache

Если используется hosted engine, переведите среду в глобальный режим обслуживания.
# hosted-engine --set-maintenance --mode=global
Дополнительную информацию см. в разделе Обслуживание hosted engine.
Добавьте сертификат Центра сертификации в доверенное хранилище на уровне хоста:
```
# cp /tmp/_3rd-party-ca-cert_.pem /etc/pki/ca-trust/source/anchors
# update-ca-trust
```
Менеджер управления настроен на использование /etc/pki/ovirt-engine/apache-ca.pem, который символически связан с /etc/pki/ovirt-engine/ca.pem. Удалите символическую ссылку:
```
# rm /etc/pki/ovirt-engine/apache-ca.pem
```
Сохраните сертификат Центра сертификации как /etc/pki/ovirt-engine/apache-ca.pem:
```
# cp /tmp/_3rd-party-ca-cert_.pem /etc/pki/ovirt-engine/apache-ca.pem
```

Сделайте резервную копию существующего закрытого ключа и сертификата:

# cp /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass.bck
# cp /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/certs/apache.cer.bck

Скопируйте закрытый ключ по соответствующему пути.
```
# cp /tmp/apache.key /etc/pki/ovirt-engine/keys/apache.key.nopass
```
Установите владельца закрытого ключа в значение root, а разрешения – в значение 0640:
```
# chown root:ovirt  /etc/pki/ovirt-engine/keys/apache.key.nopass
# chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
```
Скопируйте сертификат по соответствующему пути:
```
# cp /tmp/apache.cer /etc/pki/ovirt-engine/certs/apache.cer
```
Установите владельца сертификата в значение root, а разрешения – в значение 0644:
```
# chown root:ovirt /etc/pki/ovirt-engine/certs/apache.cer
# chmod 644 /etc/pki/ovirt-engine/certs/apache.cer
```
Перезапустите сервер Apache:
```
# systemctl restart httpd.service
```
Создайте новый файл конфигурации доверенного хранилища /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf со следующими параметрами:
```
ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""
```
Скопируйте файл /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf и переименуйте его, изменив индекс на число больше 10 (например, 99-setup.conf). Добавьте в новый файл следующие параметры:
```
SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
```
Перезапустите службу websocket-proxy:
```
# systemctl restart ovirt-websocket-proxy.service
```
Если файл /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf был изменен вручную либо если используется файл конфигурации от более старой инсталляции, убедитесь, что Менеджер управления по-прежнему настроен на использование /etc/pki/ovirt-engine/apache-ca.pem как источника сертификатов.
Включите engine-backup, чтобы обновить систему по восстановлении путем создания нового файла /etc/ovirt-engine-backup/engine-backup-config.d/update-system-wide-pki.sh со следующим содержимым:
```
BACKUP_PATHS="${BACKUP_PATHS}
/etc/ovirt-engine-backup"
cp -f /etc/pki/ovirt-engine/apache-ca.pem \
/etc/pki/ca-trust/source/anchors/_3rd-party-ca-cert_.pem
update-ca-trust
```
Перезапустите службу ovirt-provider-ovn:
```
# systemctl restart ovirt-provider-ovn.service
```
Перезапустите службу ovirt-imageio:
```
# systemctl restart ovirt-imageio.service
```
Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```
Если используется hosted engine, выключите глобальный режим обслуживания.
```
# hosted-engine --set-maintenance --mode=none
```

Теперь пользователи могут подключаться к Порталу администрирования и Пользовательскому порталу, не видя предупреждения о подлинности сертификата, используемого для шифрования HTTPS-трафика.

E.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером

Чтобы настроить шифрованную связь между Менеджером управления и LDAP-сервером, получите корневой сертификат LDAP-сервера, выданный Центром сертификации, скопируйте этот корневой сертификат в Менеджер управления и создайте сертификат, выданный Центром сертификации, в PEM-кодировке. Тип хранилища ключей может быть любым типом, поддерживаемым Java. В следующей процедуре используется формат Java KeyStore (JKS).

Дополнительные сведения о создании сертификата Центра сертификации в кодировке PEM и импорте сертификатов см. в разделе X.509 CERTIFICATE TRUST STORE файла README, размещенного в /usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

Порядок действий:

В Менеджере управления скопируйте корневой сертификат LDAP-сервера, выданный Центром сертификации, в каталог /tmp и импортируйте корневой сертификат Центра сертификации с помощью keytool, чтобы создать сертификат Центра сертификации в кодировке PEM. Следующая команда импортирует корневой сертификат Центра сертификации в /tmp/myrootca.pem и создает корневой сертификат Центра сертификации в кодировке PEM myrootca.jks в /etc/ovirt-engine/aaa/. Выпишите местонахождение сертификата и пароль. Если вы используете интерактивный инструмент настройки, то это – вся информация, которая вам понадобится. Если вы настраиваете LDAP-сервер вручную, выполните оставшуюся часть процедуры, чтобы обновить файлы конфигурации.
```
$ keytool \
    -importcert \
    -noprompt \
    -trustcacerts \
    -alias _myrootca_ \
    -file _/tmp/myrootca.pem_ \
    -keystore _/etc/ovirt-engine/aaa/myrootca.jks_ \
    -storepass _password_
```

Обновите файл /etc/ovirt-engine/aaa/profile1.properties, внеся в него сведения о сертификате:

${local:_basedir} – это каталог, где находится файл конфигурации свойств LDAP, указывающий на каталог /etc/ovirt-engine/aaa. Если вы создали сертификат Центра сертификации в кодировке PEM в другом каталоге, замените ${local:_basedir} полным путем к сертификату.

Чтобы использовать startTLS (рекомендуется):

# Create keystore, import certificate chain and uncomment
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = ${local:_basedir}/_myrootca.jks_
pool.default.ssl.truststore.password = _password_

Чтобы использовать SSL:

# Create keystore, import certificate chain and uncomment
pool.default.serverset.single.port = 636
pool.default.ssl.enable = true
pool.default.ssl.truststore.file = ${local:_basedir}/_myrootca.jks_
pool.default.ssl.truststore.password = _password_

Чтобы продолжить настройку внешнего провайдера LDAP, см. раздел Настройка внешнего провайдера LDAP. Чтобы продолжить настройку LDAP и Kerberos для единого входа, см. раздел Настройка LDAP и Kerberos для единого входа.

E.3. Включение шифрованных консолей VNC для FIPS

Вы можете настроить шифрованные консоли VNC на работу с Менеджером управления и хостами, на которых включен FIPS.

Чтобы настроить шифрованные консоли VNC, выполните следующие процедуры:

Включите FIPS в zVirt
Настройте параметры консоли кластера, которому принадлежит хост, чтобы включить шифрование VNC.
Запустите Ansible-плейбук VNC SASL на каждом хосте.
Настройте инструмент удаленного просмотра (Remote Viewer) так, чтобы он доверял сертификату Менеджера управления, выданному Центром сертификации.

E.3.1. Настройка кластера на включение шифрования VNC

Порядок действий:

На Портале администрирования нажмите Ресурсы (Compute) Кластеры (Clusters).
Выберите кластер, в котором нужно включить шифрование VNC, и нажмите Изменить (Edit). Откроется окно Изменить кластер (Edit Cluster).
Выберите вкладку Консоль (Console).
Установите флажок в поле Включить VNC шифрование (Enable VNC Encryption) и нажмите OK.

E.3.2. Запуск Ansible-плейбука VNC SASL для каждого хоста

Порядок действий:

На Портале администрирования переведите созданные вами хосты с включенным FIPS в режим обслуживания:
1. На Портале администрирования нажмите Ресурсы (Compute) Хосты (Hosts).
2. В столбце Количество ВМ (Virtual Machines) убедитесь, что ни на одном хосте нет виртуальных машин. Выполните миграцию на лету, чтобы удалить все виртуальные машины со всех хостов, если необходимо. Подробные сведения см. в разделе Миграция виртуальных машин между хостами руководства по управлению виртуальными машинами.
3. Выберите каждый хост и нажмите Управление (Management) → Обслуживание (Maintenance), а атем OK.
Подключитесь к командной строке машины, на которой запущен Менеджер управления.
1. Если Менеджер управления работает на автономной машине, подключитесь к ее командной строке. Например, введите:
  # ssh root@zvirt-host
2. Если Менеджер управления работает как hosted engine, нажмите Ресурсы (Compute) Виртуальные машины (Virtual Machines), чтобы выбрать виртуальную машину hosted engine, по умолчанию названную HostedEngine, и затем нажмите Консоль (Console).
На машине с Менеджером управления запустите Ansible-плейбук VNC SASL для каждого хоста.
# cd /usr/share/ovirt-engine/ansible-runner-service-project/project/ # ansible-playbook --ask-pass --inventory=<hostname>, ovirt-vnc-sasl.yml
В качестве <hostname> введите полное имя хоста (Hostname), показанное в разделе Ресурсы (Compute) Хосты (Hosts).
Выберите хост и нажмите Настройки (Installation) → Переустановить (Reinstall).
После переустановки выберите хост и нажмите Управление (Management) → Перезапустить (Restart).
После перезагрузки выберите хост и нажмите Управление (Management) → Включить (Activate).

Поиск и устранение неполадок

При запуске Ansible-плейбука VNC SASL задача может завершиться сбоем с выводом следующего сообщения об ошибке:

Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this.  Please add this host's fingerprint to your known_hosts file to manage this host.

Чтобы решить эту проблему, выключите проверку ключа хоста, выполнив одно из следующих действий:

Выключите проверку ключа хоста навсегда, раскомментировав следующую строку в файле /etc/ansible/ansible.cfg:
```
#host_key_checking = False
```
Выключите проверку ключа хоста на время, выполнив следующую команду:
```
export ANSIBLE_HOST_KEY_CHECKING=False.
```

E.3.3. Настройка инструмента удаленного просмотра (Remote Viewer) так, чтобы он доверял сертификату Менеджера управления, выданному Центром сертификации

Настройте консоль инструмента удаленного просмотра (Remote Viewer) на клиентской машине, virt-viewer или remote-viewer так, чтобы она доверяла Центру сертификации Менеджера управления.

Порядок действий:

Перейдите по адресу https://<engine_address>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA.
Включите все настройки доверия.

На клиентской машине, где нужно запустить консоль VNC, создайте каталог для файла сертификата:

$ mkdir ~/.pki/CA

Если на этом шаге возникнет ошибка, такая как mkdir: cannot create directory ‘/home/example_user/.pki/CA’: File exists, примите меры, чтобы не допустить перезаписывания ~/.pki/CA/cacert.pem на следующем шаге. Например, включите текущую дату в имя файла.

Загрузите сертификат:

$ curl -k -o ~/.pki/CA/cacert-<today's date>.pem \
'\https://<engine_address>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA'

Установите центр сертификации в браузер:
Установка сертификата CA в Firefox
Перейдите в веб-браузере по URL-адресу портала и на странице приветствия выберите CA сертификат.

Файл с именем pki-resource (без расширения файла) будет загружен.

Откройте окно параметров/настроек:

Windows: откройте меню Инструменты и выберите Параметры…

Mac: откройте меню Firefox и выберите Настройки…

Linux: откройте меню Правка и выберите Настройки.

Выберите Конфиденциальность и безопасность и прокрутите вниз до Сертификаты.

Щелкните Просмотреть сертификаты…. Откроется диспетчер сертификатов.

Выберите вкладку Полномочия.

Нажмите Импорт

Выберите файл корневого сертификата, который вы хотите импортировать (измените тип файла на Все файлы, чтобы просмотреть загруженный файл).

Установите флажки, указывающие параметры доверия, и нажмите OK.

Нажмите OK в Диспетчере сертификатов и закройте окно Параметры/Настройки.

Убедитесь, что все процессы Firefox остановлены.

Перезапустите Firefox и перейдите по URL-адресу портала. Значок в адресной строке указывает на то, что сертификат CA установлен.
Установка сертификата CA в Google Chrome
Перейдите веб-браузере по URL-адресу портала и на странице приветствия выберите CA сертификат.

Файл с именем pki-resource (без расширения файла) будет загружен.

Перейдите в Настройки Дополнительно Управление сертификатами → вкладка Центры и нажмите ИМПОРТ.

Выберите файл корневого сертификата, который вы хотите импортировать (измените тип файла на Все файлы, чтобы просмотреть загруженный файл).

Установите все флажки, указывающие параметры доверия, и нажмите OK.

Закройте Chrome и убедитесь, что все процессы Chrome остановлены.

Перезапустите Chrome и перейдите по URL-адресу портала. Значок в адресной строке указывает на то, что сертификат CA установлен.
Установите библиотеки SASL SCRAM на клиентскую машину:
```
$ sudo dnf install cyrus-sasl-scram
```

Действия по проверке:

Запустите виртуальную машину на одном из созданных хостов с включенным FIPS.
Подключитесь к виртуальной машине с помощью консоли VNC.

Дополнительные ресурсы

Установка компонентов консоли
Замена сертификата Менеджера управления, выданного Центром сертификации

Приложение F: Прокси-серверы

F.1. SPICE-прокси

F.1.1. Общие сведения о SPICE-прокси

SPICE-прокси – это инструмент, используемый для подключения клиентов SPICE к виртуальным машинам, когда клиенты SPICE находятся вне сети, соединяющей гипервизоры. Настройка SPICE-прокси заключается в установке Squid на машину и настройке межсетевого экрана на пропускание прокси-трафика. Включение SPICE-прокси заключается в использовании engine-config в Менеджере управления для установки ключа SpiceProxyDefault в значение, состоящее из имени и порта прокси-сервера. Выключение SPICE-прокси заключается в использовании engine-config в Менеджере управления для удаления значения, в которое был установлен ключ SpiceProxyDefault.

SPICE-прокси можно использовать только в сочетании с автономным клиентом SPICE и нельзя использовать для подключения к виртуальным машинам с помощью noVNC.

F.1.2. Настройка машины со SPICE-прокси

В этой процедуре описано, как настроить машину в качестве SPICE-прокси. SPICE-прокси позволяет подключаться к сети zVirt извне. В этой процедуре используется Squid для предоставления прокси-служб.

Порядок действий:

Установите Squid на машине с прокси:
```
# dnf install squid
```

Откройте /etc/squid/squid.conf. Измените:

http_access deny CONNECT !SSL_ports

на:

http_access deny CONNECT !Safe_ports

Запустите службу squid и включите для нее автоматический запуск после перезагрузки:
```
# systemctl enable squid.service --now
```
Добавьте постоянное правило, разрешающее входящие запросы к службе squid в зоне firewalld по умолчанию:
```
# firewall-cmd --permanent --add-service=squid
```
Перезагрузите правила:
```
# firewall-cmd --reload
```
Убедитесь, что служба squid отображается в списке служб межсетевого экрана:
```
# firewall-cmd --list-services
ssh dhcpv6-client squid
```

Теперь машина настроена в качестве SPICE-прокси. Перед подключением к сети zVirt извне этой сети активируйте SPICE-прокси.

F.1.3. Включение SPICE-прокси

Далее описано, как активировать (включить) SPICE-прокси.

Порядок действий:

Чтобы настроить прокси-сервер, в Менеджере управления используйте инструмент engine-config:
```
# `engine-config -s SpiceProxyDefault=someProxy`
```
Перезапустите службу ovirt-engine:
```
# systemctl restart ovirt-engine.service
```

Адрес прокси-сервера должен иметь следующий вид:

protocol://[host]:[port]

Старые версии клиента SPICE поддерживают только HTTP. Если для клиентов более ранних версий указан HTTPS, клиент проигнорирует настройку прокси-сервера и попытается подключиться к хосту напрямую.

Теперь SPICE-прокси активирован (включен). Можно подключиться к сети zVirt через SPICE-прокси.

F.1.4. Выключение SPICE-прокси

Далее описано, как выключить (деактивироваать) SPICE-прокси.

Порядок действий:

Авторизуйтесь в Менеджере управления:
```
$ ssh root@_[IP of {engine-name}]_
```
Чтобы очистить SPICE-прокси, запустите следующую команду:
```
# engine-config -s SpiceProxyDefault=""
```
Перезапустите Менеджер управления:
```
# systemctl restart ovirt-engine.service
```

Теперь SPICE-прокси деактивирован (выключен). Больше нельзя подключиться к сети zVirt через SPICE-прокси.

F.2. Squid-прокси

F.2.1. Установка и настройка Squid-прокси

В этом разделе описано, как устанавливать и настраивать Squid-прокси на Пользовательском портале. Squid-прокси используется для ускорения доставки контента. Он кэширует часто просматриваемый контент, снижая расход полосы пропускания и ускоряя отклик.

Порядок действий:

Получите пару ключей и сертификат для порта HTTPS Squid-прокси. Эту пару ключей можно получить таким же способом, как и пару ключей для другой службы SSL/TLS. Пара ключей имеет вид двух файлов PEM, содержащих закрытый ключ и подписанный сертификат. В данном случае предположим, что они имеют имена proxy.key и proxy.cer.

Эту пару ключей и сертификат можно также сгенерировать с помощью центра сертификации engine. Если у вас уже есть закрытый ключ и сертификат для прокси-сервера и вы не хотите генерировать их с помощью центра сертификации engine, перейдите к следующему шагу.

Выберите имя хоста для прокси-сервера. Затем выберите другие компоненты отличительного имени сертификата для прокси-сервера.

Рекомендуется использовать те же названия страны и организации, что и в самом engine. Чтобы найти эту информацию, авторизуйтесь на машине, на которой установлен Менеджер управления, и выполните следующую команду:

openssl x509 -in /etc/pki/ovirt-engine/ca.pem -noout -text | grep DirName

Эта команда выведет примерно следующее:

subject= /C=US/O=Example Inc./CN=_engine.example.com_.81108

Важный фрагмент здесь: /C=US/O=Example Inc.. Используйте его, чтобы создать полное отличительное имя сертификата для прокси-сервера:

/C=US/O=Example Inc./CN=_proxy.example.com_

Авторизуйтесь на машине с прокси-сервером и сгенерируйте запрос на подписание сертификата:

# openssl req -newkey rsa:2048 -subj '/C=US/O=Example Inc./CN=_proxy.example.com_' -nodes -keyout proxy.key -out proxy.req

Отличительное имя сертификата нужно поставить в кавычки. Параметр -nodes гарантирует, что закрытый ключ не шифруется, а значит, пароль для запуска прокси-сервера вводить не нужно.

Команда генерирует два файла: proxy.key и proxy.req. proxy.key – это закрытый ключ. Храните его в надежном месте. proxy.req – это запрос на подписание сертификата. Он не требует специальной защиты.

Чтобы сгенерировать подписанный сертификат, скопируйте файл запроса на подписание сертификата с прокси-машины на машину с Менеджером управления:
```
# scp proxy.req _engine.example.com_:/etc/pki/ovirt-engine/requests/.
```
Авторизуйтесь на машине с Менеджером управления и подпишите сертификат.
# /usr/share/ovirt-engine/bin/pki-enroll-request.sh \ --name=proxy \ --days=3650 \ --subject='/C=US/O=Example Inc./CN=_proxy.example.com_'
Эта команда подписывает сертификат и делает его действительным в течение 10 лет (3650 дней). При желании можно установить более короткий срок действия сертификата.
Сгенерированный файл сертификата доступен в каталоге /etc/pki/ovirt-engine/certs и должен иметь имя proxy.cer. На прокси-машине скопируйте этот файл с машины с Менеджером управления в текущий каталог:
```
# scp _engine.example.com_:/etc/pki/ovirt-engine/certs/proxy.cer .
```
Убедитесь, что и proxy.key, и proxy.cer присутствуют на прокси-машине:
```
# ls -l proxy.key proxy.cer
```
Установите пакет Squid на прокси-машину:
```
# dnf install squid
```
Переместите закрытый ключ и подписанный сертификат в место, где прокси-сервер может получить к ним доступ, например, в каталог /etc/squid:
```
# cp proxy.key proxy.cer /etc/squid/.
```
Задайте разрешения так, чтобы пользователь squid мог читать эти файлы:
```
# chgrp squid /etc/squid/proxy.*
# chmod 640 /etc/squid/proxy.*
```

Squid-прокси должен проверить сертификат, который использует engine. Скопируйте сертификат Менеджера управления на прокси-машину. В этом примере используется путь к файлу /etc/squid:

# scp engine.example.com:/etc/pki/ovirt-engine/ca.pem /etc/squid/.

Сертификат Центра сертификации по умолчанию находится в /etc/pki/ovirt-engine/ca.pem на машине с Менеджером управления.

Задайте разрешения так, чтобы пользователь squid мог читать файл сертификата:
```
# chgrp squid /etc/squid/ca.pem
# chmod 640 /etc/squid/ca.pem
```
Если SELinux работает в режиме "принудительный" (enforcing mode), измените контекст порта 443 инструментом semanage, чтобы разрешить Squid использование порта 443:
```
# dnf install policycoreutils-python
# semanage port -m -p tcp -t http_cache_port_t 443
```

Замените существующий файл конфигурации Squid следующим:

https_port 443 key=/etc/squid/proxy.key cert=/etc/squid/proxy.cer ssl-bump defaultsite=_engine.example.com_
cache_peer _engine.example.com_ parent 443 0 no-query originserver ssl sslcafile=/etc/squid/ca.pem name=engine login=PASSTHRU
cache_peer_access engine allow all
ssl_bump allow all
http_access allow all

Перезапустите Squid-прокси:
```
# systemctl restart squid.service
```

Squid-прокси в конфигурации по умолчанию разорвет соединение после 15 минут отсутствия активности. Чтобы увеличить время неактивности, по истечении которого Squid-прокси разорвет соединение, настройте параметр read_timeout в squid.conf (например, read_timeout 10 hours).

F.3. Websocket-прокси

F.3.1. Общие сведения о Websocket-прокси

Websocket-прокси позволяет пользователям подключаться к виртуальным машинам через консоль noVNC.

Websocket-прокси можно установить и настроить на машине с Менеджером управления во время первоначальной настройки (см. Настройка Менеджера управления).

Приложение G: Адаптация оформления (брендинг)

G.1. Адаптация оформления (брендинг)

G.1.1. Адаптация оформления Менеджера управления

Разные аспекты Менеджера управления можно настроить на свой вкус, например, значки и текст во всплывающих окнах, а также ссылки на странице приветствия. Это позволяет точечно адаптировать внешний вид Менеджера управления и довести его до того состояния, в котором он в итоге будет представлен администраторам и пользователям.

Файлы, необходимые для кастомизации Менеджера управления, находятся в каталоге /etc/ovirt-engine/branding/ в системе, на которой установлен Менеджер управления. Эти файлы включают в себя набор файлов каскадных таблиц стилей для оформления различных аспектов графического интерфейса пользователя и набор файлов свойств, которые содержат сообщения и ссылки, включенные в различные компоненты Менеджера управления.

Чтобы адаптировать компонент, измените файл этого компонента и сохраните изменения. В следующий раз, когда вы откроете или обновите этот компонент, изменения будут видны.

G.1.2. Экран авторизации

На Портале администрирования и Пользовательском портале используется один и тот же экран авторизации. На экране авторизации можно настроить следующие элементы:

границу
основное изображение сверху слева
основное изображение сверху справа
основной текст

Классы для экрана авторизации находятся в common.css.

G.1.3. Экран Портала администрирования

Экран Портала администрирования – это главный экран, который отображается при авторизации на Портале администрирования. На экране Портала администрирования можно настроить следующие элементы:

логотип
фоновое изображение слева
фоновое изображение по центру
фоновое изображение справа
текст справа от логотипа

Классы для экрана Портала администрирования находятся в web_admin.css.

G.1.4. Экран Пользовательского портала

Экран Пользовательского портала отображается при авторизации на Пользовательском портале. На экране Пользовательского портала можно настроить следующие элементы:

логотип
фоновое изображение по центру
фоновое изображение справа
границу вокруг основной сетки
текст над плашкой Авторизовавшийся пользователь (Logged in user)

Классы для экрана Пользовательского портала находятся в user_portal.css.

G.1.5. Всплывающие окна

Всплывающие окна – это все окна в Менеджере управления, в которых можно создавать, изменять или обновлять такие сущности как хосты или виртуальные машины. Во всплывающих окнах можно настроить следующие элементы:

границу
основное изображение сверху слева
основное изображение сверху в центре (повторяющееся)

Классы для всплывающих окон находятся в common.css.

G.1.6. Вкладки

Во многих всплывающих окнах на Портале администрирования есть вкладки. Во вкладках можно настроить следующие элементы:

Активный
Неактивный

Классы для вкладок находятся в common.css и user_portal.css.

G.1.7. Страница приветствия

Страница приветствия – это первая страница, отображающаяся при посещении главной страницы Менеджера управления. Помимо настройки общего внешнего вида и стиля можно изменить файл шаблона, чтобы добавить ссылки на страницу с дополнительной документацией или внутренние веб-сайты. На странице приветствия можно настроить следующие элементы:

заголовок страницы
основное изображение (слева, по центру и справа)
сообщение об ошибке
ссылка переадресации и сообщение, привязанное к этой ссылке
Добавить сообщение в виде баннера или вводной фразы

Классы для страницы приветствия находятся в welcome_style.css.

Файл шаблона

Файл шаблона для страницы приветствия – это обычный HTML-файл с именем welcome_page.template, в котором нет тегов HTML, HEAD или BODY. Этот файл вставляется напрямую в страницу приветствия и служит контейнером для содержимого, отображаемого на этой странице. Поэтому необходимо изменить этот файл, чтобы добавить новые ссылки или изменить содержимое самой страницы. Другая функция файла шаблона заключается в том, что он содержит замещающий текст, например, {user_portal}, который заменяется соответствующим текстом в файле messages.properties, когда обрабатывается страница приветствия.

Вводная фраза

На страницу приветствия можно добавить пользовательский баннер сообщений. Для этого добавьте файл preamble.template, в котором содержится текст баннера, и файл preamble.css, определяющий размер баннера, и свяжите их в файле branding.properties. Файлы-примеры доступны в шаблоне примеров вводных фраз.

При обновлении engine пользовательский баннер сообщений остается на месте и нормально работает. После резервного копирования и восстановления engine, во время восстановления engine, пользовательский баннер сообщений необходимо восстановить и проверить вручную.

G.1.8. Страница "Страница не найдена"

Страница "Страница не найдена" – это страница, которая отображается при открытии ссылки на страницу, которую невозможно найти в Менеджере управления. На странице "Страница не найдена" можно настроить следующие элементы:

заголовок страницы
основное изображение сверху (слева, в центре и справа)
сообщение об ошибке
ссылка переадресации и сообщение, привязанное к этой ссылке

Классы для страницы "Страница не найдена" находятся в welcome_style.css.

Приложение H: Системные учетные записи

H.1. Учетные записи пользователей Менеджера управления

При установке пакетов ovirt-engine, ovirt-vmconsole создается ряд учетных записей системных пользователей для поддержки zVirt. Каждый системный пользователь имеет идентификатор пользователя, присваиваемый по умолчанию (UID). Создаются следующие учетные записи системных пользователей:

Пользователь vdsm (UID 36). Требуется для инструментов поддержки, которые монтируют домены хранения NFS и обращаются к ним.
Пользователь ovirt (UID 108). Владелец экземпляра Wildfly ovirt-engine.
Пользователь ovirt-vmconsole (UID 992). Требуется для гостевой консоли, подключаемой по последовательному интерфейсу

H.2. Группы Менеджера управления

При установке пакетов ovirt-engine, ovirt-vmconsole создается ряд групп системных пользователей для поддержки zVirt. Каждая группа системных пользователей имеет идентификатор группы, присваиваемый по умолчанию (GID). Создаются следующие группы системных пользователей:

Группа kvm (GID 36). Члены группы:
- Пользователь vdsm.
Группа ovirt (GID 108). Члены группы:
- Пользователь ovirt.
Группа ovirt-vmconsole (GID 998). Члены группы:
- Пользователь ovirt-vmconsole.

H.3. Учетные записи хоста виртуализации

При установке пакетов vdsm, sanlock, ovirt-vmconsole и qemu-kvm на хосте виртуализации создается ряд учетных записей системных пользователей. Каждый системный пользователь имеет идентификатор пользователя, присваиваемый по умолчанию (UID). Создаются следующие учетные записи системных пользователей:

Пользователь vdsm (UID 36).
Пользователь qemu (UID 107).
Пользователь sanlock (UID 179).
Пользователь ovirt-vmconsole (UID 998).

Присваиваемые идентификаторы пользователей (UID) и идентификаторы групп (GID) могут варьироваться от системы к системе. За пользователем vdsm зарезервирован UID 36, а за группой kvm зарезервирован GID 36.

Если UID 36 или GID 36 уже используется другой учетной записью в системе, то при установке пакетов vdsm и qemu-kvm-rhev возникнет конфликт.

H.4. Группы хостов виртуализации

При установке пакетов ovirt-vmconsole и qemu-kvm на хосте виртуализации создается ряд групп системных пользователей. Каждая группа системных пользователей имеет идентификатор группы, присваиваемый по умолчанию (GID). Создаются следующие группы системных пользователей:

Группа kvm (GID 36). Члены группы:
- Пользователь qemu.
- Пользователь sanlock.
Группа qemu (GID 107). Члены группы:
- Пользователь vdsm.
- Пользователь sanlock.
Группа ovirt-vmconsole (GID 998). Члены группы:
- Пользователь ovirt-vmconsole.