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

1. Администрирование и обслуживание ПО «zVirt Max»

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

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

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

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

1.1.1. Роли

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

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

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

Процедура

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

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

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

Процедура

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

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

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

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

Катя работает системным администратором в бухгалтерии. Все виртуальные ресурсы ее отдела организованы в кластере ПО «zVirt Max» под названием Бухгалтерия. Ей назначена роль Администратора кластера (ClusterAdmin) в кластере бухгалтерии. С такой ролью она может управлять всеми виртуальными машинами в кластере, т.к. виртуальные машины – это дочерние объекты кластера. Управление виртуальными машинами включает изменение, добавление или удаление виртуальных ресурсов, например, дисков, и создание моментальных снимков. У неё нет прав на управление ресурсами за пределами кластера. Поскольку Администратор кластера (ClusterAdmin) – это роль администратора, она может использовать Портал администрирования или Пользовательский портал для управления этими ресурсами.

Пример 2. Разрешения Ключевого пользователя ВМ (VM PowerUser)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соотвествии с требованиями по безопасности информации к средствам виртуализации ФСТЭК России в ПО «zVirt Max» созданы дополнительные неизменяемые роли пользователей различных типов, такие как:

разработчик виртуальной машины (VirtualMachineDeveloper),
администратор безопасности средства виртуализации (SecurityAdministratorVirtualizationTools),
администратор средства виртуализации (VirtualizationToolAdministrator),
администратор виртуальной машины (VirtualMachineAdministrator).

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

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

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

Процедура

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

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

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

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

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

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

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

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

Процедура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Администратор хоста – это роль системного администратора только для определенного хоста. Рекомендуется использовать данную роль в кластерах с несколькими хостами, где для каждого хоста требуется системный администратор. Кнопкой Настройка (Configure) в верхней панели можно назначить администратора хоста для всех хостов в среде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка Legacy SPICE Cipher

По умолчанию консоли SPICE используют FIPS-совместимое шифрование и строку шифра. По умолчанию используется следующая строка шифра SPICE:

kECDHE+FIPS:kDHE+FIPS:kRSA+FIPS:!eNULL:!aNULL

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

Вы можете изменить строку шифра, используя Ansible-плейбук.

Изменение строки шифра

На машине с Менеджером управления создайте файл в каталоге /usr/share/ovirt-engine/playbooks. Например:
```
vim /usr/share/ovirt-engine/playbooks/change-spice-cipher.yml
```

Введите в файл следующие данные и сохраните его:

name: ПО «zVirt Max» - 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

Запустите только что созданный файл:

ansible-playbook -l _hostname_ /usr/share/ovirt-engine/playbooks/change-spice-cipher.yml

Либо можно переконфигурировать хост Ansible-плейбуком ovirt-host-deploy, используя опцию --extra-vars с переменной host_deploy_spice_cipher_string:

ansible-playbook -l _hostname_ \
  --extra-vars host_deploy_spice_cipher_string=”DEFAULT:-RC4:-3DES:-DES” \
  /usr/share/ovirt-engine/playbooks/ovirt-host-deploy.yml

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

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

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

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

Подробную информацию о работе политик планирования см. в справке «Как работает политика планирования кластера».

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

Политика планирования Равномерное распределение (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 Max».

Процедура

Нажмите Управление (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).

Таблица 12. Настройки в окнах "Новая политика планирования" и "Редактировать политику планирования"
Имя поля	Описание
Имя (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.

Таблица 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), привязанные к типу экземпляра, обозначены значком цепи рядом с ними ( ). Если значение одного из этих полей изменится, то виртуальная машина будет отключена от типа экземпляра, который изменится на Пользовательский (Custom), а значок цепи будет выглядеть разорванным ( ). Однако, если значение снова станет прежним, целостность цепи будет восстановлена, а тип экземпляра вернется к изначально выбранному.

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

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

Процедура

Нажмите Управление (Administration) → Настройка (Configure).
Откройте вкладку Типы экземпляров (Instance Types).
Нажмите Новый (New).
В поля Имя (Name) и Описание (Description) введите имя и описание типа экземпляра.
Нажмите Показать расширенные настройки (Show Advanced Options) и сконфигурируйте настройки типа экземпляра. Настройки в окне Новый тип экземпляра (New Instance Type) аналогичны настройкам в окне Новая виртуальная машина (New Virtual Machine) и отличаются лишь соответствующими полями. См. Описание настроек в окнах "Новая виртуальная машина (New Virtual Machine)" и "Изменить виртуальную машину (Edit 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 Max» может автоматически генерировать и назначать MAC-адреса новым виртуальным сетевым устройствам, что помогает предотвратить дублирование MAC-адресов. Пулы MAC-адресов используют память эффективнее, когда все MAC-адреса, относящиеся к кластеру, находятся в пределах диапазона назначенного пула MAC-адресов.

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

Если несколько кластеров ПО «zVirt Max» совместно используют сеть, не следует полагаться исключительно на пул 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-адресов. Дополнительные сведения о добавлении новых разрешений пользователей см. в Разделе 1.1.1. Роли.

Процедура

Нажмите Управление (Administration) → Настройка (Configure).
Откройте вкладку Пулы MAC-адресов (MAC Address Pools).
Выберите нужный пул MAC-адресов.
Отредактируйте разрешения пользователей для пула MAC-адресов:
- Чтобы добавить разрешения пользователей в пул MAC-адресов:
  - Нажмите Добавить (Add) в панели разрешений пользователей в нижней части окна Настройка (Configure).
  - Найдите и выберите нужных пользователей.
  - Выберите нужную роль из выпадающего списка Роль для связи (Role to Assign).
  - Нажмите OK, чтобы добавить разрешения пользователя.
- Чтобы удалить разрешения пользователей из пула MAC-адресов:
  - Выберите разрешение пользователя, которое нужно удалить, в панели разрешений пользователей в нижней части окна Настройка (Configure).
  - Нажмите Удалить (Remove), чтобы удалить разрешения пользователя.

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

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

Процедура

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

1.2. Дашборд

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

Рисунок 6. Дашборд

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

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

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

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

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

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

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

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

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

1.2.2.1. Максимально используемые ресурсы

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

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

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

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

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

1.2.3.1. ЦП

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

1.2.3.2. Память

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

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

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

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

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

1.3. Поиск

1.3.1. Как устроен поиск в ПО «zVirt Max»

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

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

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

result type: {criteria} [sortby sort_spec]

В таблице 15 показано, как прописывать и использовать поисковые запросы в ПО «zVirt Max».

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

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

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

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

Hosts: Vms.status = down

Таблица 16. Примеры поисковых запросов с автозаполнением
Ввод	Отображаемые элементы	Действие
h	Хосты (Hosts) (всего один вариант).	Выберите Хосты (Hosts) или наберите Хосты (Hosts).
Hosts:	Все свойства хостов	Наберите 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 для списка доменов хранения.

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

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

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

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

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

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

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

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

Можно задать поиск по двум критериям с помощью логических операторов И (AND) и ИЛИ (OR). Например: 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 – по убыванию).

Например: events: severity > normal sortby time desc

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

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

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

Таблица 18. Поиск центров данных
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Clusters.clusters-prop	Зависит от типа свойства.	Свойство кластеров, ассоциированных с центром данных.
name	Строка	Имя центра данных.
description	Строка	Описание центра данных.
type	Строка	Тип центра данных.
status	Список	Доступность центра данных.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

Datacenter: type = nfs and status != up

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

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

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

Таблица 19. Поиск кластеров
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
Datacenter.datacenter-prop	Зависит от типа свойства	Свойство центра данных, ассоциированного с кластером.
Datacenter	Строка	Центр данных, к которому относится кластер.
name	Строка	Уникальное имя, определяющее кластеры в сети.
description	Строка	Описание кластера.
initialized	Строка	Значение "True" или "False", обозначающее статус кластера.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

Clusters: initialized = true or name = Default

По запросу в примере будет выдан список кластеров, которые инициализированы или имеют название "Default".

1.3.10. Поиск хостов

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

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

Пример

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	Зависит от типа свойства	Свойство хоста, ассоциированного с сетью.
name	Строка	Имя, которое определяет сеть.
description	Строка	Ключевые слова или текстовое описание сети, которые можно дополнительно использовать при создании сети.
vlanid	Целое число	Идентификатор VLAN сети.
stp	Строка	Показывает, включен или выключен STP-протокол для сети.
mtu	Целое число	Максимальный размер передаваемого блока данных для логической сети.
vmnetwork	Строка	Показывает, используется ли сеть исключительно для трафика виртуальных машин.
datacenter	Строка	Центр данных, к которому подключена сеть.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

Network: mtu > 1500 and vmnetwork = true

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

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

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

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

Пример

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	Строка	Имя, которое определяет хранилище в сети.
description	Строка	Ключевые слова или текстовое описание диска, которые можно дополнительно использовать при создании диска.
provisioned_size	Целое число	Виртуальный объем диска.
size	Целое число	Объем диска.
actual_size	Целое число	Фактический объем, выделенный для диска.
creation_date	Целое число	Дата создания диска.
bootable	Строка	Показывает, можно ли загрузить диск. Допустимы следующие значения: 0, 1, да (yes) или нет (no).
shareable	Строка	Показывает, можно ли подключить диск к нескольким виртуальным машинам одновременно. Допустимы следующие значения: 0, 1, да (yes) или нет (no).
format	Строка	Формат диска. Возможны значения не используется (unused), не назначен (unassigned), копирование при записи (cow) или не определен (raw).
status	Строка	Статус диска. Возможны значения не назначен (unassigned), в порядке (ok), заблокирован (locked), недействителен (invalid или недопустим (illegal).
disk_type	Строка	Тип диска. Возможны значения образ (image) или логический номер устройства (lun).
number_of_vms	Целое число	Количество виртуальных машин, к которым подключен диск.
vm_names	Строка	Имя виртуальной машины или машин, к которым подключен диск.
quota	Строка	Имя квоты, установленной для виртуального диска.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

Disks: format = cow and provisioned_size > 8

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

1.3.14. Поиск томов

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

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

Пример

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	Строка	Имя виртуальной машины.
status	Список	Доступность виртуальной машины.
ip	Целое число	IP-адрес виртуальной машины.
uptime	Целое число	Сколько минут виртуальная машина уже работает.
domain	Строка	Домен (обычно домен Active Directory), в котором сгруппированы эти машины.
os	Строка	Операционная система, выбранная при создании виртуальной машины.
creationdate	Дата	Дата создания виртуальной машины.
address	Строка	Уникальное имя, определяющее виртуальную машину в сети.
cpu_usage	Целое число	Процент использования вычислительной мощности.
mem_usage	Целое число	Процент использования оперативной памяти.
network_usage	Целое число	Процент использования сети.
memory	Целое число	Максимальная заданная память.
apps	Строка	Приложения, установленные в настоящий момент на виртуальной машине.
cluster	Список	Кластер, которому относится виртуальная машина.
pool	Список	Пул виртуальных машин, к которому относится виртуальная машина.
loggedinuser	Строка	Имя пользователя, авторизованного в настоящий момент на виртуальной машине.
tag	Список	Теги, к которым относится виртуальная машина.
datacenter	Строка	Центр данных, к которому относится виртуальная машина.
type	Список	Тип виртуальной машины (сервер или рабочая станция).
quota	Строка	Имя квоты, ассоциированной с виртуальной машиной.
description	Строка	Ключевые слова или текстовое описание виртуальной машины, которые можно дополнительно использовать при создании виртуальной машины.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.
next_run_configuration_exists	Логическое выражение	Изменения конфигурации, внесенные в виртуальную машину и ожидающие подтверждения.

Пример

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

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

Пример

Vms: cluster = Default and os = windows7

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

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

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

Таблица 26. Поиск пулов
Свойство (ресурса или типа ресурса)	Тип	Описание (пример)
name	Строка	Имя пула.
description	Строка	Описание пула.
type	Список	Тип пула.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

Pools: type = automatic

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

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

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

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

Пример

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	Строка	Имя пользователя.
lastname	Строка	Фамилия пользователя.
username	Строка	Уникальное имя пользователя.
department	Строка	Департамент, к которому относится пользователь.
group	Строка	Группа, к которой относится пользователь.
title	Строка	Должность пользователя.
status	Строка	Статус пользователя.
role	Строка	Роль пользователя.
tag	Строка	Тег, к которому относится пользователь.
pool	Строка	Пул, к которому относится пользователь.
sortby	Список	Сортирует результаты поиска по одному из свойств ресурса.
page	Целое число	Отображаемый номер страницы результатов.

Пример

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

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

1.3.19. Поиск событий

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

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

Пример

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 Max»

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

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

Чтобы создать, изменить или удалить теги на Портале администрирования, нажмите значок Теги (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. Пользовательская настройка хостов с помощью тегов

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

Процедура

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

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

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

2.1. Политики QoS

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

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

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

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

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

2.1.2.2. Описание настроек в окнах "Новая политика QoS сети (New Virtual Machine Network QoS)" и "Изменить QoS сети (Edit Virtual Machine 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, MaxPeakNetworkQoSValue или MaxBurstNetworkQoSValue. Для сохранения изменений перезапустите службу ovirt-engine. Например:

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 в отношении сети хоста

Создайте политику QoS в отношении сети хоста.

Процедура

Нажмите Ресурсы (Compute) → Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку QoS.
В разделе Сеть хоста (Host Network), нажмите Новая (New).
Введите Имя QoS (QoS Name) и описание для политики QoS.
Введите необходимые значения для полей Общие веса (Weighted Share), Ограничение скорости [Мб/с] (Rate Limit [Mbps]) и Подтвержденная скорости [Мб/с] (Committed Rate [Mbps]).
Нажмите 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 [Mbps]): Максимальная полоса пропускания для использования сетью. Подтвержденная скорость [Мб/с]* (Committed Rate [Mbps]): Минимальная полоса пропускания, требуемая для сети. Требуемая Гарантированная скорость не гарантируется и будет варьироваться в зависимости от сетевой инфраструктуры и Гарантированной скорости, требуемой для других сетей на том же логическом канале связи.

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

Например:

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.3.4. Политика QoS в отношении ЦП

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

2.1.3.5. Создайте политику QoS в отношении ЦП

Процедура

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

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

2.1.3.6. Удаление политики QoS в отношении ЦП

Удалите политику QoS в отношении ЦП.

Процедура

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

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

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

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

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

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

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

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

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

2.2.2. Возможные состояния центра данных

Таблица 32. Возможные состояния центра данных
Состояние	Описание	Причины перехода в данное состояние
В обслуживании (Maintenance)	Центр данных находится в режиме обслуживания	Центр данных переведен в режим обслуживания администратором для выполнения плановых работ, например, технического обслуживания оборудования или обновления инфраструктуры
Неработоспособен (Not operational)	Центр данных не готов к работе	Существуют проблемы с питанием, сетевым оборудованием или другими критически важными компонентами инфраструктуры центра данных
Проблемный (Problematic)	Центр данных имеет проблемы, требующие внимания	Обнаружены аномалии в работе центра данных, например, высокая загрузка ресурсов, ошибки оборудования или проблемы с производительностью. Возможно требуется внимание администратора
Не инициализирован (Uninitialized)	Центр данных не инициализирован в системе	Центр данных только что создан или добавлен в систему и еще не прошел процесс инициализации
Работает (Up)	Центр данных работает (доступен и готов к работе)	Центр данных успешно инициализирован, все необходимые сервисы работают, ресурсы доступны для использования

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

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

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

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

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

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

Изменить приоритет SPM для хоста можно на вкладке SPM в окне Изменить хост (Edit Host).

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

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

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

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

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

Процедура

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

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

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

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

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

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

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

Процедура

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

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

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

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

Процедура

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

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

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

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

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

Процедура

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

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

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

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

Ограничения

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

Процедура

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

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

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

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

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

Процедура

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

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

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

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

Процедура

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

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

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

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

Процедура

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

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

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

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

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

Процедура

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

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

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

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

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

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

Процедура

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

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

2.3. Кластеры

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

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

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

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

Во время установки ПО «zVirt Max» создает кластер по умолчанию в центре данных по умолчанию.

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

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

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

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

Процедура

Нажмите Ресурсы (Compute) → Кластеры (Clusters).
Нажмите Новый (New).
В выпадающем списке выберите Центр данных (Data Center), к которому будет относиться кластер.
В поля Имя (Name) и Описание (Description) введите имя и описание кластера.
В выпадающем списке Сеть управления (Management Network) выберите сеть, чтобы назначить роль сети управления.
Выберите Архитектура ЦП (CPU Architecture).

В качестве Типа ЦП (CPU Type) выберите самое старое семейство ЦП среди хостов, которые войдут в кластер. Типы ЦП перечисляются от самого старого к самому новому.

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

В выпадающем списке выберите Версию совместимости (Compatibility Version) кластера.
В выпадающем списке выберите Тип коммутатора (Switch Type).

Выберите Тип межсетевого экрана (Firewall Type) для хостов в кластере: Firewalld (по умолчанию) или iptables.

Тип iptables поддерживается только на хостах в кластерах с версией совместимости ПО «zVirt Max» 2.0 (4.3). Добавлять хосты ПО «zVirt Max» 3.0 можно только к кластерам с типом межсетевого экрана firewalld.

Установите флажок Включить службу Virt (Enable Virt Service), чтобы указать, будет ли кластер заполняться хостами с виртуальными машинами.

Служба Gluster в zVirt Max 1.1 не поддерживается.
При желании можно установить флажок /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-адресов см. в Разделе 1.1.5. Пулы MAC-адресов.
Нажмите OK, чтобы создать кластер и открыть окно Помощник по созданию кластера (Cluster - Guide Me).
Окно Помощника (Guide Me) содержит список сущностей, которые нужно сконфигурировать для кластера. Сконфигурируйте эти сущности или отложите конфигурирование, нажав Настроить позже (Configure Later). Чтобы возобновить конфигурирование, выберите кластер и нажмите Дополнительные действия (More Actions), а затем нажмите Помощник (Guide Me).

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

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

Таблица 34. Общие настройки кластера
Поле	Описание/действие
Центр данных (Data Center)	Центр данных, в котором будет содержаться кластер. Центр данных должен быть создан до добавления кластера.
Имя (Name)	Имя кластера. В этом текстовом поле должно быть не больше 40 знаков. Имя должно быть уникальным и представлять собой любую комбинацию латинских букв в верхнем и нижнем регистре, цифр, дефисов и знаков подчеркивания.
Описание/комментарий (Description/Comment)	Описание кластера или дополнительные примечания. Эти поля являются рекомендованными, но не обязательными.
Сеть управления (Management Network)	Логическая сеть, которой будет назначена роль сети управления. По умолчанию – ovirtmgmt. Эта сеть также будет использоваться для миграции виртуальных машин, если сеть миграции не подключена к хосту-источнику или хосту-приемнику. В существующих кластерах сеть управления можно изменить, только нажав кнопку Управление сетями (Manage Networks) на вкладке Логические сети (Logical Networks) в подробном представлении.
Архитектура ЦП (CPU Architecture)	Архитектура ЦП кластера. Все хосты в кластере должны иметь указанную архитектуру. В зависимости от выбранной архитектуры ЦП доступны различные типы ЦП. не определено (undefined): все остальные типы ЦП. x86_64: ЦП типа Intel и AMD.
Тип ЦП (CPU Type)	Самое старое семейство ЦП в кластере. Список типов ЦП приведен в разделе Требования к ЦП на портале технической поддержке. Его изменение после создания кластера приведет к серьезному нарушению работы. Установите тип ЦП, ориентируясь на самую старую модель ЦП хоста в кластере. Использоваться могут только те функции, которые есть во всех моделях. Для ЦП типа Intel и AMD модели ЦП перечисляются в логическом порядке от самой старой к самой новой.
Версия совместимости (Compatibility Version)	Версия ПО «zVirt Max». Нельзя выбрать более раннюю версию, чем та, что указана для центра данных.
Тип коммутатора (Switch Type)	Тип коммутатора, используемого кластером. Мост Linux (Linux Bridge) – стандартный коммутатор ПО «zVirt Max». Open vSwitch – обеспечивает поддержку сетевых функций Open vSwitch.
Тип межсетевого экрана (Firewall Type)	Указывает тип межсетевого экрана для хостов в кластере: Firewalld (по умолчанию) или iptables. Тип iptables поддерживается только на хостах Red OS 7.3 в кластерах с версией совместимости ПО «zVirt Max» 2.0 (4.3). Добавлять хосты Red OS 7.3 можно только к кластерам с типом межсетевого экрана firewalld. Изменение типа межсетевого экрана существующего кластера потребует переустановки всех хостов в кластере для того, чтобы изменения вступили в силу.
Провайдер сети по умолчанию (Default Network Provider)	Указывает внешнего поставщика сети по умолчанию, которого будет использовать кластер. Если выбрать Открытую виртуальную сеть (Open Virtual Network, OVN), то хосты, добавленные в кластер, автоматически настраиваются на взаимодействие через поставщика OVN. Изменение поставщика сети по умолчанию потребует переустановки всех хостов в кластере для того, чтобы изменения вступили в силу.
Верхний порог памяти для логирования (Maximum Log Memory Threshold)	Задает пороговое значение максимального потребления памяти (в процентах или в виде абсолютной величины в МБ), факт достижения которого вносится в журнал. Сообщение вносится в журнал, если использование памяти хоста превышает это процентное значение или если объем доступной памяти хоста падает ниже абсолютного значения в МБ. Значение по умолчанию – 95%.
Включить службу Virt (Enable Virt Service)	При нажатии кнопки-переключателя хосты в этом кластере будут использоваться для запуска виртуальных машин.

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

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

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

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

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

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

Таблица 35. Настройки оптимизации
Поле	Описание/действие
Оптимизация памяти (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% от объема системной памяти на каждом хосте.
Потоки ЦП (CPU Threads)	Установка флажка Считать потоки как ядра (Count Threads As Cores) позволяет хостам обеспечить работу виртуальных машин с общим количеством процессорных ядер, превышающим количество ядер хоста. Если этот флажок установлен, открытые потоки хостов трактуются как ядра, которые виртуальные машины могут использовать. Например, 24-ядерная система с 2 потоками на ядро (всего 48 потоков) может запускать виртуальные машины, каждая из которых содержит до 48 ядер, а алгоритмы расчета загрузки ЦП хоста будут сравнивать нагрузку с удвоенным количеством потенциально используемых ядер.
Динамическое выделение памяти (Memory Balloon)	Если установлен флажок Включить оптимизацию динамического выделения (Enable Memory Balloon Optimization), то на виртуальных машинах, работающих на хостах в этом кластере, становится возможным выделение памяти в объеме, превышающем физически доступный (memory overcommitment). Когда этот флажок установлен, Менеджер избыточного выделения памяти (Memory Overcommit Manager, MoM) начинает применять балунинг памяти во всех возможных ситуациях с ограничением гарантированного объема памяти для каждой виртуальной машины. Для балунинга памяти виртуальная машина должна иметь устройство балунинга с соответствующими драйверами. Каждая виртуальная машина включает в себя устройство балунинга, если оно не удалено специально. Каждый хост в этом кластере получает обновление политики балунинга, когда его статус меняется на Включен (Up). При необходимости вы можете вручную обновить политику балунинга на хосте, не меняя статус. См. Раздел 2.3.2.10. Обновление политики Менеджера избыточного выделения памяти (MoM) на хостах в кластере. Важно понимать, что в некоторых сценариях балунинг памяти (ballooning) может вступать в конфликт с объединением одинаковых страниц памяти (KSM). В таких случаях Менеджер избыточного выделения памяти (MoM) будет пытаться скорректировать объем балунинга (ballooning), чтобы минимизировать конфликты. Кроме того, в ряде сценариев балунинг памяти может привести к тому, что производительность для виртуальной машины будет неоптимальной. Администраторам рекомендуется с осторожностью использовать балунинг памяти в целях оптимизации.
Контроль KSM	Если выбрана опция Включить KSM (Enable KSM), то Менеджер избыточного выделения памяти может запустить KSM, когда это необходимо и может дать экономию памяти, выгода от которой перевешивает затраты на ЦП.

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

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

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

Политика

Описание

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

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

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

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

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

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

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

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

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

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

Приостановка при необходимости

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

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

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

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

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

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

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

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

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

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

Не назначена (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.
LowUtilization: Выражается в процентах. Если в течение заданного интервала времени хост загружает ЦП на уровне ниже нижнего предела загрузки, то Менеджер управления будет переносить виртуальные машины на другие хосты кластера. Менеджер управления отключит питание на исходном хосте и перезапустит его снова, когда того потребует балансировка нагрузки или когда в кластере не будет достаточно свободных хостов. Значение по умолчанию – 20.
ScaleDown: Уменьшает влияние весовой функции Резервирование высокой доступности (HA Reservation) методом деления оценки хоста на указанную величину. Это необязательное свойство, которое может быть добавлено в любую политику, включая политику Не назначена (none).
HostsInReserve: Указывает количество хостов, которые должны продолжать работать, даже если на них нет запущенных виртуальных машин. Это необязательное свойство, которое может быть добавлено к политике Энергосбережение (power_saving).
EnableAutomaticHostPowerManagement: Включает автоматическое управление питанием на всех хостах в кластере. Это необязательное свойство, которое может быть добавлено к политике Энергосбережение (power_saving). Значение по умолчанию – верно (true).
MaxFreeMemoryForOverUtilized: Указывает минимальный объем свободной оперативной памяти, обязательный для хоста, в МБ. Если объем свободной оперативной памяти на хосте меньше указанного, то Менеджер управления считает хост перегруженным. Например, если установить для этого свойства значение 1000, то хост, у которого меньше 1 ГБ свободной оперативной памяти, будет перегружен.

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

Это свойство можно добавить к политикам Энергосбережение (power_saving) и Равномерное распределение (evenly_distributed). Хотя оно появляется в списке свойств для политики Равномерное распределение ВМ (vm_evenly_distributed), оно не применяется к ней.

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

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

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

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

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

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

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

Для DefaultCustomSerialNumber:

Значение по умолчанию: Фиктивный серийный номер
Возможные значения: Любая строка (ограничение: максимум 255 знаков)
Пример командной строки: engine-config --set DefaultCustomSerialNumber="My very special string value" IMPORTANT: Перезапустите Менеджер управления для применения настроек.
Идентификатор хоста (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 – это файл журнала Менеджера избыточного выделения памяти.

Свойства политики планирования в кластере 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.5. Описание настроек политик планирования.

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

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

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

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

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

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

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

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

Процедура

Нажмите Ресурсы (Compute) → Кластеры (Clusters) и выберите кластер.
Нажмите Изменить (Edit).
Откройте вкладку Политика планирования (Scheduling Policy).
Выберите одну из следующих политик:
- Не задана (none)
- Равномерное распределение ВМ (vm_evenly_distributed)
  - Чтобы включить балансировку нагрузки, в поле HighVmCount укажите минимальное количество виртуальных машин, которое должно быть запущено хотя бы на одном хосте.
  - В поле MigrationThreshold задайте максимальную допустимую разницу между количеством виртуальных машин на наиболее загруженном и наименее загруженном хостах.
  - В поле SpmVmGrace укажите количество слотов для виртуальных машин, которое должно быть зарезервировано на хостах SPM.
  - При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в Разделе 3.1.3. Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах.
- evenly_distributed
  - В поле CpuOverCommitDurationMinutes укажите время (в минутах), в течение которого хост может работать при загрузке ЦП, выходящей за заданные значения, прежде чем вступит в действие политика планирования.
  - В поле HighUtilization укажите процент загрузки ЦП, при котором начинается миграция виртуальных машин на другие хосты.
  - При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в Разделе 3.1.3. Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах.
- power_saving
  - В поле CpuOverCommitDurationMinutes укажите время (в минутах), в течение которого хост может работать при загрузке ЦП, выходящей за заданные значения, прежде чем вступит в действие политика планирования.
  - В поле LowUtilization укажите процент загрузки ЦП, ниже которого хост будет считаться недогруженным,
  - В поле HighUtilization укажите процент загрузки ЦП, при котором начинается миграция виртуальных машин на другие хосты.
  - При желании в поле HeSparesCount введите количество дополнительных узлов с ролью hosted engine, на которых нужно зарезервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления в случае ее переноса или выключения. Дополнительную информацию см. в Разделе 3.1.3. Настройка слотов памяти, резервируемых для 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). Дополнительную информацию см. в разделе 1.1.3. Политики планирования в Руководстве администратора.
- Идентификатор хоста (Host ID): Установите серийный номер каждой виртуальной машины в значение, соответствующее UUID хоста.
- Код ВМ (Vm ID): Установите серийный номер каждой виртуальной машины в значение, соответствующее UUID виртуальной машины.
- Настраиваемый серийный номер (Custom serial number): Установите серийный номер каждой виртуальной машины в значение, которое вы задаете в следующем параметре Пользовательский серийный номер (Custom Serial Number).
Нажмите OK.

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

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

Процедура

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

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

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

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

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

Процедура

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

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

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

Процедура

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

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

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

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

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

Процедура

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

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

Чтобы увеличить количество виртуальных машин на хосте, можно использовать избыточное выделение памяти (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.8. Оптимизация памяти и избыточное выделение памяти

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

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

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

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

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

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

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

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

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

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

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

Менеджер избыточного выделения памяти (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.

Динамическое выделение памяти (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 начинает применять балунинг памяти во всех возможных ситуациях с ограничением гарантированного объема памяти для каждой виртуальной машины. См. Раздел 2.3.2.3. Описание настроек оптимизации.

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

Объединение одинаковых страниц памяти (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.3. Описание настроек оптимизации.

2.3.2.9. UEFI и чипсет Q35

Чипсет Q35 с UEFI и SecureBoot – это предварительные версии технологий, представленные для оценки.

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

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

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

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

Чтобы использовать UEFI на виртуальной машине, необходимо настроить кластер виртуальной машины для совместимости с версией 4.4 или более поздней. Затем можно установить UEFI для любой существующей виртуальной машины или задать его как тип BIOS по умолчанию для новых виртуальных машин в кластере. Доступны следующие опции:

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

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

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

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

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

Чипсет Q35 с UEFI и SecureBoot – это предварительные версии технологий, представленные для оценки.

Процедура

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

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

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

Чипсет Q35 с UEFI и SecureBoot – это предварительные версии технологий, представленные для оценки.

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

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

Процедура

Чтобы настроить виртуальную машину для использования чипсета Q35 с UEFI:

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

2.3.2.11. Изменение версии совместимости кластера

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

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

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

Ограничения

После обновления уровня совместимости кластера до 4.6 сетевые карты Virtio нумеруются как другое устройство. Поэтому, возможно, потребуется их перенастройка. Рекомендуем протестировать виртуальные машины перед обновлением кластера; для этого нужно установить уровень совместимости кластера в значение 4.6 на виртуальной машине и проверить сетевое подключение.
Если сетевое соединение для виртуальной машины не работает, то перед обновлением версии кластера настройте виртуальную машину с помощью пользовательской эмулируемой машины, которая соответствует текущей эмулируемой машине, например, pc-q35-rhel8.3.0 для версии совместимости 4.5.

Процедура

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

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

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

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

2.4.1. Возможные состояния логических сетей

Таблица 43. Возможные состояния логических сетей
Состояние	Описание	Причины перехода в данное состояние
Неработоспособна (Non operational)	Сетевая конфигурация не функционирует должным образом	Ошибки конфигурации сети (например, неправильные VLAN ID, неверные настройки маршрутизации), или проблемы с физической инфраструктурой сети (например, недоступный коммутатор), или невыполненные зависимости (например, отсутствует VLAN на коммутаторе)
Работоспособна (Operational)	Сетевая конфигурация работает нормально и готова к использованию	Сеть успешно настроена, все необходимые параметры корректны или физическая инфраструктура сети доступна, все зависимости выполнены

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

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

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

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

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

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

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

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

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

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

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

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

Процедура

Нажмите Ресурсы (Compute) → Центры данных (Data Centers) или Ресурсы (Compute) → Кластеры (Clusters).
Нажмите на имя центра данных или кластера. Откроется подробное представление Details.
Откройте вкладку Логические сети (Logical Networks).
Откройте окно Новая логическая сеть (New Logical Network):
- В подробном представлении центра данных нажмите Создать (New).
- В подробном представлении кластера нажмите Добавить сеть (Add Network).
В полях Имя (Name), Описание (Description) и Комментарий (Comment) укажите значения для логической сети.
Дополнительно: Включите Включить тегирование VLAN (Enable VLAN tagging).
Дополнительно: Выключите Сеть ВМ (VM Network).
Дополнительно: Установите флажок в поле Создать на внешнем провайдере (Create on external provider). Это выключает параметры "Метка сети" и "Сеть ВМ". Подробности см. в Разделе 2.9. Внешние провайдеры.
Выберите Внешний провайдер (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) укажите, должна ли сеть использовать Группы безопасности (Security Groups). Подробности см. в Разделе 2.4.1.9. Описание общих настроек логической сети.
На вкладке Кластер (Cluster) выберите кластеры, которым будет назначена эта сеть. Можно также указать, будет ли логическая сеть обязательной сетью.
Если поставлен флажок Создать на внешнем провайдере (Create on external provider), то будет видна вкладка Подсеть (Subnet). На вкладке Подсеть (Subnet) выберите Создать подсеть (Create subnet), введите Имя (Name), CIDR и адрес Шлюза (Gateway) и выберите Версию IP (IP Version) для подсети, которую будет предоставлять логическая сеть. Можно также добавить DNS-серверы, если необходимо.
На вкладке vNIC-профили (vNIC Profiles) добавьте vNIC-профили к логической сети, если необходимо.
Нажмите OK.

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

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

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

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

Процедура

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

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

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

2.4.2.4. Настройка MTU логической сети

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

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

Процедура

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

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

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

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

Процедура

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

Если сеть предоставлена внешним провайдером, то при желании для удаления логической сети сразу из Менеджера управления и внешнего провайдера поставьте флажок Удалить внешнюю сеть(-и) также и из провайдера(-ов) (Remove external network(s) from the provider(s) as well). Поле для флажка неактивно, если внешний провайдер находится в режиме только чтение.
Нажмите OK.

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

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

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

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

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

Настройка роли "маршрут по умолчанию"

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

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

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

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

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

Для добавления статических маршрутов к хостам можно использовать 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.2.8. Удаление статического маршрута на хосте

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

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

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

Процедура

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

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

Процедура

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

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

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

Таблица 44. Настройки окон Новая логическая сеть (New Logical Network) и Изменить логическую сеть (Edit Logical Network)
Имя поля	Описание
Имя (Name)	Имя логической сети. В этом текстовом поле должно быть уникальное имя, представляющее собой любую комбинацию латинских букв в верхнем и нижнем регистре, цифр, дефисов и знаков подчеркивания. Имейте в виду, что хотя имя логической сети может быть длиннее 15 знаков и может содержать знаки, отличные от ASCII, идентификатор на хосте (vdsm_name) будет отличаться от заданного имени.
Описание (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, подключенных к гипервизорам, и не должны использоваться какие-либо настройки разворота пакетов, которые бы возвращали кадры назад.
Максимальный размер передаваемого блока данных (MTU)	Выберите либо значение Default, тем самым установив максимальный размер передаваемого блока данных (MTU) в значение, указанное в круглых скобках (), либо Пользовательское (Custom) значение MTU и задайте его для логической сети. Это можно использовать, чтобы привести MTU, поддерживаемый вашей новой логической сетью, в соответствие MTU, поддерживаемому оборудованием, с которым взаимодействует эта сеть. Если выбрано значение Custom, то укажите числовое значение в поле ввода текста. + IMPORTANT: В случае изменения настроек MTU сети необходимо распространить это изменение на работающие виртуальные машины в сети: Выполните горячее выключение и повторное включение каждой виртуальной сетевой карты виртуальной машины, к которой нужно применить эту настройку MTU, или перезапустите виртуальные машины. В противном случае эти интерфейсы перестанут работать при переносе виртуальной машины на другой хост.
Метка сети (Network Label)	Позволяет задать для сети новую метку или выбрать одну из существующих меток, уже прикрепленных к сетевым интерфейсам хоста. Если выбирается существующая метка, логическая сеть будет автоматически назначена всем сетевым интерфейсам хоста с этой меткой.
Группы безопасности (Security Groups)	Позволяет назначать группы безопасности портам в этой логической сети. Выключена (Disabled) отключает функцию групп безопасности. Включена (Enabled) включает эту функцию. Когда порт создается и подключается к этой сети, функция безопасности будет включена. Это означает, что доступ к виртуальным машинам и от них будет зависеть от групп безопасности, которые в настоящее время предоставляются. Наследовать из конфигурации (Inherit from Configuration) разрешает портам наследовать поведение из файла конфигурации, заданного для всех сетей. По умолчанию этот файл выключает группы безопасности. Подробности см. в Разделе 2.4.3.6. Назначение групп безопасности логическим сетям и портам.

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

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

Имя поля

Описание

Кластер (Attach/Detach Network to/from Cluster(s))

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

Имя (Name) – имя кластера, к которому будут применяться настройки. Это неизменяемое значение.
Выбрать все (Attach All) – позволяет подключить логическую сеть ко всем кластерам в центре данных или отключить ее от них. Либо поставьте или снимите флажок Подключить (Attach) рядом с именем каждого кластера, чтобы подключить логическую сеть к данному кластеру или отключить ее от него.
Выбрать всех (Required All) – позволяет указать, является ли логическая сеть обязательной сетью на всех кластерах. Либо поставьте или снимите флажок Обязательно (Required) рядом с именем каждого кластера, чтобы указать, является ли логическая сеть обязательной сетью для конкретного кластера.

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

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

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

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

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

Процедура

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

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

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

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

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

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

Это один из вопросов на тему, как настроить и сконфигурировать SR-IOV в ПО «zVirt Max». Дополнительные сведения см. в разделе Настройка и конфигурирование технологии SR-IOV.

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

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

Виртуальные функции можно настроить так же, как и отдельную сетевую карту, в том числе:

Назначить одну или несколько логических сетей для виртуальной функции;
Создать бондинг интерфейсов с виртуальными функциями;
Назначить виртуальные сетевые карты (vNIC) виртуальным функциям для сквозного доступа к устройствам.

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

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

Для того чтобы vNIC была подключена к виртуальной функции, ее свойство сквозного доступа должно быть включено. Подробнее см. в Разделе 2.4.2.4. Включение сквозного доступа на 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.5. Виртуальные сетевые карты (vNICs)

2.5.1. Обзор vNIC-профилей

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

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

Таблица 47. Возможные состояния виртуальных сетевых карт
Состояние соединения	Состояние карты	Описание	Причины перехода в данное состояние
Включено (Up)	Подключена (Plugged)	Сетевой интерфейс находится в своем слоте и подключен, виртуальная сетевая карта подключена	Сетевой интерфейс задан на виртуальной машине, подключен к сетевому кабелю, виртуальная сетевая карта подключена
Включено (Up)	Не подключена (Unplugged)	Сетевой интерфейс находится в своем слоте и подключен, но виртуальная сетевая карта не подключена	Сетевой интерфейс задан на виртуальной машине, подключен к сетевому кабелю, но не активен, т.к. виртуальная сетевая карта не подключена
Выключено (Down)	Подключена (Plugged)	Сетевой интерфейс находится в своем слоте, но не подключен ни к одной сети, виртуальная сетевая карта подключена	Сетевой интерфейс задан только на Менеджере управления и не ассоциируется с виртуальной машиной
Выключено (Down)	Не подключена (Unplugged)	Сетевой интерфейс не подключен ни к одной сети, виртуальная сетевая карта не подключена	Сетевой интерфейс задан только на Менеджере управления и не ассоциируется с виртуальной машиной

2.5.2.1. Создание или изменение vNIC-профилей

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

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

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Выберите вкладку vNIC-профили (vNIC Profiles).
Нажмите Новый (New) или Изменить (Edit).
Введите имя и описание профиля в поля Имя (Name) и Описание (Description).
Выберите подходящую политику QoS из списка QoS.
Выберите Сетевой фильтр (Network Filter) из выпадающего списка, чтобы настроить трафик сетевых пакетов к виртуальным машинам и от них.
Установите флажок в поле Сквозной доступ (Passthrough), чтобы включить сквозной доступ на vNIC и разрешить прямое назначение устройства виртуальной функции. Если включить свойство сквозного доступа, то по причине несовместимости будут выключены политика QoS, фильтрация сети и зеркалирование портов. Дополнительные сведения о сквозном доступе см. в Разделе 2.4.2.4. Включение сквозного доступа на vNIC-профиле.
Если выбран Сквозной доступ (Passthrough), то при желании можно снять флажок Мигрируемый (Migratable), чтобы выключить возможность миграции для vNIC, которые используют этот профиль. Если оставляете флажок в этом поле, то см. раздел Дополнительные предварительные условия для виртуальных машин с картами vNIC с включенной технологией SR-IOV в Руководстве пользователя.
Используйте флажки в полях Зеркалирование портов (Port Mirroring) и Разрешить всем пользователям использовать этот профиль (Allow all users to use this Profile), чтобы включать и выключать эти опции.
Выберите пользовательское свойство из списка пользовательских свойств, где по умолчанию отображается Выберите ключ… (Please select a key…). Нажимая кнопки + и -, добавляйте или удаляйте пользовательские свойства.
Нажмите OK.

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

Описание настроек в окне "Профиль интерфейса ВМ (VM Interface Profile)"

Имя поля Описание

Сеть (Network)

Выпадающий список доступных сетей, к которым можно применить vNIC-профиль.

Имя (Name)

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

Описание (Description)

Описание vNIC-профиля. Это поле является рекомендованным, но необязательным.

Политика QoS (QoS)

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

Сетевой фильтр (Network Filter)

Выпадающий список доступных сетевых фильтров, который можно применить к vNIC-профилю. Сетевые фильтры повышают безопасность сети за счет фильтрации типов пакетов, которые могут быть отправлены на виртуальныемашины и от них. По умолчанию установлен фильтр vdsm-no-mac-spoofing, который представляет собой комбинацию no-mac-spoofing и no-arp-mac-spoofing.

Используйте параметр <Без сетевых фильтров> (<No Network Filter>) для сетей VLAN и bond-интерфейсов виртуальных машин. Отключение сетевого фильтра на доверенных виртуальных машинах может повысить производительность.

Больше недоступна возможность отключения фильтров с помощью переключения параметра EnableMACAntiSpoofingFilterRules в значение false через инструмент engine-config. Вместо этого воспользуйтесь опцией <Без сетевых фильтров> (<No Network Filter>).

Сквозной доступ (Passthrough)

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

При включенном сквозном доступе политика QoS, сетевые фильтры и зеркалирование портов в vNIC-профиле выключены.

Мигрируемый (Migratable)

Флажок в этом поле определяет, можно ли переносить карты vNIC, использующие этот профиль, или нет. Миграция включена по умолчанию для обычных vNIC-профилей: флажок в поле стоит, и снять его нельзя. Когда стоит флажок в поле Сквозной доступ (Passthrough), свойство Мигрируемый (Migratable) становится доступным, и при необходимости флажок можно снять, чтобы выключить возможность миграции карт vNIC сквозного доступа.

Аварийное переключение (Failover)

Выпадающий список для выбора доступных vNIC-профилей, действующих в качестве устройств аварийного переключения. Доступно только, когда стоят флажки в полях Сквозной доступ (Passthrough) и Мигрируемый (Migratable).

Зеркалирование портов (Port Mirroring)

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

Пользовательские свойства устройства (Device Custom Properties)

Выпадающий список, в котором можно выбрать доступные пользовательские свойства, которые можно применить к vNIC-профилю. Нажимая кнопки + и -, добавляйте или удаляйте соответствующие свойства.

2.5.2.2. Включение сквозного доступа на vNIC-профиле

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

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Выберите имя логической сети. Откроется подробное представление.
Выберите вкладку Профили vNIC (vNIC Profiles), на которой отобразится список всех vNIC-профилей для этой логической сети.
Нажмите Новый (New).
Введите имя и описание профиля в поля Имя (Name) и Описание (Description).
Поставьте флажок в поле Сквозной доступ (Passthrough).
При желании можно снять флажок Мигрируемый (Migratable), чтобы выключить возможность миграции для vNIC, которые используют этот профиль. Если флажок в этом поле остается, то см. Дополнительные предварительные условия для виртуальных машин с картами vNIC с включенной технологией SR-IOV в Руководстве пользователя.
При необходимости выберите пользовательское свойство из списка пользовательских свойств, где по умолчанию отображается Выберите ключ… (Please select a key…). Нажимая кнопки + и -, добавляйте или удаляйте пользовательские свойства.
Нажмите OK.

Теперь возможность сквозного доступа активирована в vNIC-профиле. Чтобы использовать этот профиль для прямого подключения виртуальной машины к сетевой карте или виртуальной функции PCI, подключите логическую сеть к сетевой карте и создайте новую виртуальную сетевую карту Сквозного доступа PCI (PCI Passthrough) на нужной виртуальной машине, которая использует vNIC-профиль со сквозным доступом. Более подробную информацию об этих процедурах см. в разделе 2.4.4.3. Изменение сетевых интерфейсов хоста и назначение логических сетей хостам и "Добавление нового сетевого интерфейса" в Руководстве пользователя.

2.5.2.3. Включение vNIC-профиля для миграции SR-IOV с аварийным переключением

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

Аварийное переключение – это предварительная версия технологии, представленная для оценки.

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

Свойства Сквозной доступ (Passthrough) и Мигрируемый (Migratable) отмечены флажками в профиле.
Сеть аварийного переключения подключена к хосту.
Чтобы можно было изменять vNIC-профиль, действующий в качестве устройства аварийного переключения, необходимо сначала удалить все ссылки на аварийное переключение.
Действовать как устройства аварийного переключения могут vNIC-профили, в которых снят флажок в поле Сквозной доступ (Passthrough) или которые не подключены к Внешней сети.

Процедура

На Портале администрирования перейдите в раздел Сеть (Network) → VNIC-профили (VNIC profiles).
Выберите vNIC-профиль, нажмите Изменить (Edit) и выберите vNIC-профиль аварийного переключения (Failover vNIC profile) из выпадающего списка.
Нажмите OK, чтобы сохранить настройки профиля.

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

2.5.2.4. Удаление vNIC-профиля

Удаление vNIC-профиля из среды виртуализации.

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Выберите имя логической сети. Откроется подробное представление.
Откройте вкладку Профили vNIC (vNIC Profiles), чтобы увидеть доступные vNIC-профили.
Выберите один или сразу несколько профилей и нажмите Удалить (Remove).
Нажмите OK.

2.5.2.5. Назначение vNIC-профилям групп безопасности

Эта функция доступна только при добавлении ovirt-provider-ovn в качестве внешнего провайдера сети. Невозможно создать группы безопасности через Менеджер управления. Их необходимо создать через OpenStack Networking на ovirt-provider-ovn. Дополнительные сведения см. в разделе Управление безопасностью проекта в руководстве Red Hat OpenStack Platform Users and Identity Management Guide.

Группы безопасности можно назначить 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.5.2.6. Разрешения пользователей для vNIC-профилей

Настройте разрешения пользователей, чтобы назначить пользователей на определенные vNIC-профили. Назначьте пользователю роль VnicProfileUser, чтобы он мог использовать профиль. Ограничьте доступ пользователей к определенным профилям, удалив у них разрешение на этот профиль.

Разрешения пользователей для vNIC-профилей

Нажмите Сеть (Network) → Профили vNIC (vNIC Profile).
Выберите имя vNIC-профиля. Откроется подробное представление.
Откройте вкладку Разрешения (Permissions), чтобы увидеть текущие разрешения пользователей для профиля.
Нажмите Добавить (Add) или Удалить (Remove), чтобы изменить разрешения пользователя для vNIC-профиля.
В окне Добавление разрешение для пользователя (Add Permissions to User) нажмите Мои группы (My Groups), чтобы увидеть группы пользователей. Эту опцию можно использовать для предоставления разрешений другим пользователям в ваших группах.
Разрешения пользователей для vNIC-профиля успешно настроены.

2.6. Сети внешнего провайдера

2.6.1. Импортирование сетей из внешних провайдеров

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

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Нажмите Импортировать (Import).
Из выпадающего списка Провайдер сети (Network Provider) выберите внешнего провайдера. Система автоматически обнаруживает сети, предложенные этим провайдером, и отображает их в виде списка Сети провайдера (Provider Networks).
Устанавливая флажки в соответствующие поля, выберите сети для импорта из списка Сети провайдера (Provider Networks) и нажмите стрелку вниз, чтобы переместить эти сети в список Сети для импорта (Networks to Import).
Имя импортируемой сети можно изменить. Чтобы изменить имя, нажмите на имя сети в столбце Имя (Name) и измените текст.
Из выпадающего списка Центр данных (Data Center) выберите центр данных, в который будут импортированы сети.
- Дополнительно: Уберите флажок из поля Разрешить всем (Allow All), чтобы эта сеть не была доступна всем пользователям.
Нажмите Импортировать (Import).

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

2.6.2. Ограничения относительно использования сетей внешнего провайдера

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

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

2.6.3. Настройка подсетей в логических сетях внешнего провайдера

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

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

При добавлении Открытой виртуальной сети (OVN) (ovirt-provider-ovn) в качестве внешнего провайдера сети, несколько подсетей могут быть присоединены друг к другу через маршрутизаторы. Для управления этими маршрутизаторами можно использовать OpenStack Networking API v2.0.

2.6.4. Добавление подсетей в логические сети внешнего провайдера

Создайте подсеть в логической сети, предоставленной внешним провайдером.

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Откройте вкладку Подсети (Subnets).
Нажмите Новая (New).
Введите Имя (Name) и CIDR для новой подсети.
Из выпадающего списка Версия IP (IP Version) выберите или IPv4, или IPv6.
Нажмите OK.

В версии IPv6 ПО «zVirt Max» поддерживает только статическую адресацию.

2.6.5. Удаление подсетей из логических сетей внешнего провайдера

Удалите подсеть из логической сети, предоставленной внешним провайдером.

Процедура

Нажмите Сеть (Network) → Сети (Networks).
Нажмите на имя логической сети. Откроется подробное представление.
Откройте вкладку Подсети (Subnets).
Выберите подсеть и нажмите Удалить (Remove).
Нажмите OK.

2.6.6. Назначение групп безопасности логическим сетям и портам

Функция доступна, когда Открытая виртуальная сеть (OVN) добавлена как внешний провайдер сети (as ovirt-provider-ovn). Группы безопасности нельзя создать с помощью Менеджера управления. Они создаются через OpenStack Networking API v2.0 или Ansible.

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

Процедура

Нажмите Ресурсы (Compute) → Кластеры (Clusters).
Нажмите на имя кластера. Откроется подробное представление.
Выберите вкладку Логические сети (Logical Networks).
Нажмите Добавить сеть (Add Network) и задайте свойства, убедившись при этом, что выбираете ovirt-provider-ovn из выпадающего списка Внешние провайдеры (External Providers). Дополнительные сведения см. в Разделе 2.4.1.2. Создание новой логической сети в центре данных или кластере.
Из выпадающего списка Группа безопасности (Security Group) выберите Включен (Enabled). Дополнительные сведения см. в Разделе 2.4.1.9. Описание общих настроек логической сети.
Нажмите 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.7. Хосты и сетевое взаимодействие

2.7.1. Конфигурация менеджера сети со сведениями о состоянии (nmstate)

В версии ПО «zVirt Max» 3.0 используется Конфигурация менеджера сети со сведениями о состоянии (nmstate), чтобы настраивать сети для хостов. Для использования nmstate, обновите Менеджер управления и хосты, как описано в Руководстве пользователя. Администратору не нужно устанавливать или конфигурировать nmstate, который включен по умолчанию и работает в фоновом режиме.

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

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

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

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

Если используется dnf или yum для обновления пакета nmstate вручную, перезапустите vdsmd и supervdsmd на хосте. Например:

dnf update nmstate
systemctl restart vdsmd supervdsmd

Если используется dnf или yum для обновления пакета Менеджер сети вручную, перезапустите NetworkManager на хосте. Например:

dnf update NetworkManager
systemctl restart NetworkManager

2.7.2. Обновление конфигурации ресурсов хоста

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обновить возможности (Refresh Capabilities).

Список сетевых карт во вкладке Сетевые интерфейсы (Network Interfaces) для выбранного хоста обновлен. Теперь любая новая сетевая карта может использоваться Менеджером управления.

2.7.3. Изменение сетевых интерфейсов хоста и назначение логических сетей хостам

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

Предупреждение

Изменить IP-адрес хоста в ПО «zVirt Max» можно, только удалив хост и затем добавив его снова. Чтобы изменить настройки VLAN хоста, см. Раздел 2.4.4.5. Изменение настроек VLAN хоста.

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

Если коммутатор был сконфигурирован для предоставления информации по протоколу Link Layer Discovery Protocol (LLDP), наведите указатель мыши на физический сетевой интерфейс для просмотра текущей конфигурации порта коммутатора. Так можно избежать использования неправильной конфигурации. Проверьте следующую информацию перед назначением логических сетей:

Описание порта (Port Description) TLV тип 4 (TLV type 4) и Имя системы (System Name) TLV тип 5 (TLV type 5) помогают определить, к каким портам и на каком коммутаторе коммутированы интерфейсы хоста.
ID порта сети VLAN (Port VLAN ID) отображает ID сети VLAN, сконфигурированной на порте коммутатора для ethernet-фреймов без тегов (Native VLAN). Все сети VLAN, сконфигурированные на порте коммутатора отображаются в виде комбинаций Имя сети VLAN (VLAN Name) и ID сети VLAN (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) введите длину (length) префикса, используя прямую косую черту и число в десятичной системе счисления. Например : /48
IP-адрес (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.
- Ограничение скорости [Мб/с] (Rate Limit [Mbps]): Максимальная полоса пропускания для спользования сетью.
- Подтвержденная скорость [Мб/с] (Committed Rate [Mbps]): Минимальная полоса пропускания, требуемая для сети. Требуемая Гарантированная скорость не гарантируется и будет варьироваться в зависимости от сетевой инфраструктуры и Гарантированной скорости, требуемой для других сетей на том же логическом канале связи.
Для конфигурирования сетевого моста откройте вкладку Пользовательские свойства (Custom Properties) и из выпадающего списка выберите параметр bridge_opts. Введите корректный ключ и значение в следующем формате: key=значение. Разделите несколько записей знаком пробела. Следующие ключи корректны, а значения приведены в качестве примера. Для получения дополнительной информации об этих параметрах см. Раздел B.1. Описание параметров 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. Для получения дополнительной информации см. Раздел B.2. Как настроить Менеджер управления для использования ethtool.
Для конфигурирования Fibre Channel over Ethernet (FCoE) откройте вкладку Пользовательские свойства (Custom Properties) и из выпадающего списка выберите параметр fcoe. Введите корректный ключ и значение в следующем формате: key=значение. Требуется указать хотя бы enable=yes. Можно также добавить dcb=[yes|no] и auto_vlan=[yes|no]. Разделите несколько записей знаком пробела. Параметр fcoe не доступен по умолчанию; его нужно добавить, используя инструмент конфигурации engine. Для получения дополнительной информации см. Раздел B.3. Как настроить Менеджер управления для использования FCoE.

Использовать FCoE рекомендуется вместе с отдельной выделенной логической сетью.
Чтобы изменить сеть, используемую хостом по умолчанию, с сети управления (ovirtmgmt) на сеть, не отвечающую за управление, сконфигурируйте маршрут сети, не отвечающей за управление, как используемый по умолчанию. Для получения дополнительной информации см. Раздел 2.4.1.5. Настройка логической сети, не являющейся сетью управления, в качестве маршрута по умолчанию.
Если ваше определение настроек логической сети не синхронизировано с конфигурацией сети на хосте, то поставьте флажок Синхронизировать сеть (Sync network). Для получения дополнительной информации о несинхронизированных хостах и о том, как их синхронизировать см. Раздел 2.4.4.4. Синхронизация сетей хостов.
Установите флажок Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine) для проверки сетевого подключения. Это действие возможно, только если хост находится в режиме обслуживания.
1. Нажмите 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

2.7.4. Синхронизация сетей хостов

Менеджер управления определяет сетевой интерфейс как несинхронизированный (out-of-sync), когда определение настроек интерфейса на хосте отличается от определения настроек, которое хранит Менеджер управления.

Несинхронизированные сети обозначаются значком на вкладке Сетевые интерфейсы (Network Interfaces) и значком в окне Настройка сетей хоста (Setup Host Networks).

Когда сеть хоста не синхронизирована, единственное, что можно сделать с несинхронизированной сетью в окне Настройка сетей хоста (Setup Host Networks) – это отключить логическую сеть от сетевого интерфейса или выполнить синхронизацию сети.

Причины, по которым хост становится несинхронизированным

Хост может стать несинхронизированным, если:

Внести изменения в конфигурацию на хосте, а не в окне Изменить логические сети (Edit Logical Networks), например:
- изменить идентификатор VLAN на физическом хосте;
- изменить Пользовательское значение MTU (Custom MTU) на физическом хосте.
Переместить хост в другой центр данных с тем же именем сети, но с другими значениями/параметрами.
Изменить свойство сети Сеть ВМ (VM Network), вручную удалив мост (bridge) с хоста.

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

Предотвращение рассинхронизации хоста

Следование этим рекомендациям предотвратит рассинхронизацию хоста:

Вносите изменения через Портал администрирования, а не локально на хосте.
Изменяйте настройки VLAN в соответствии с инструкциями в Разделе 2.4.4.5. Изменение настроек 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)* кластера, чтобы синхронизировать все несинхронизированные определения настроек логических сетей для всего кластера.

2.7.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.7.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.
Измените логические сети:
- Наведите указатель мыши на назначенную логическую сеть и нажмите на значок карандаша.
- Если определение настроек логической сети не синхронизировано с конфигурацией сети на хосте, то поставьте флажок Синхронизировать сеть (Sync network).
- Выберите Конфигурация (Boot Protocol):
  - Отсутствует (None);
  - DHCP;
  - Статичная (Static).
- Укажите IP-адрес (IP) и Маску подсети (Subnet Mask).
- Нажмите OK.
Поставьте флажок Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine), чтобы запустить проверку сети. Это действие будет выполнено, только если хост находится в режиме обслуживания.
Нажмите OK.
Добавьте логическую сеть к каждому хосту в кластере, изменив сетевую карту на каждом хосте в кластере. После этого сеть станет работоспособной.

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

2.7.7. Копирование сетей хостов

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

Логические сети, подключенные к хосту, кроме сети управления ovirtmgmt.
Bond-интерфейсы, подключенные к интерфейсам

Ограничения

Не копируйте конфигурации сетей, содержащие статические IP-адреса. В этом случае протокол загрузки на целевом хосте будет установлен в значение Не назначен (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.7.8. Назначение дополнительных IPv4-адресов сети хоста

При начальной настройке сеть хоста (такая как сеть управления ovirtmgmt) создается с единственным IP-адресом. Это означает, что если конфигурационный файл сетевой карты содержит несколько IP-адресов, только первый указанный IP-адрес будет назначен сети хоста. Дополнительные IP-адреса могут потребоваться при подключении к хранилищу или к серверу в отдельной частной подсети с использованием той же сетевой карты. Хук vdsm-hook-extra-ipv4-addrs позволяет настроить дополнительные IPv4-адреса для сетей хоста. Дополнительные сведения смотрите на портале технической поддержке. В следующей процедуре специфичные для хоста задачи должны быть выполнены на каждом хосте, для которого вы хотите настроить дополнительные IP-адреса.

Процедура

На хосте, для которого вы хотите настроить дополнительные IPv4-адреса, установите пакет хука VDSM. Пакет доступен по умолчанию на хостах ПО «zVirt Max», но его необходимо установить на хостах Red OS.
```
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.7.9. Добавление меток сети к сетевым интерфейсам хостов

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

Существует два способа добавления меток к сетевому интерфейсу хоста:

Вручную на Портале администрирования.
Автоматически с использованием службы LLDP Labeler.

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Сетевые интерфейсы (Network Interfaces).
Нажмите Настройка сетей хоста (Setup Host Networks).
Нажмите Метки (Labels), после чего нажмите правой кнопкой мыши [Новая метка] ([New Label]). Выберите физический сетевой интерфейс, которому нужно присвоить метку.
Введите имя метки сети в текстовое поле Метка (Label).
Нажмите OK.

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

2.7.10. Настройка службы LLDP Labeler

По умолчанию служба LLDP Labeler запускается раз в час. Этот вариант полезен, если вы меняете оборудование (например, сетевые карты, коммутаторы или кабели) или конфигурацию коммутаторов.

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

Интерфейсы должны быть подключены к коммутатору Juniper.
Коммутатор Juniper должен быть настроен на предоставление Порта VLAN (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 – путь к файлу сертификата, выданного альтернативным Центром сертификации. Если альтернативные сертификаты не используются, оставьте это значение пустым. По умолчанию - пусто.
- 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.7.11. Изменение полного доменного имени (FQDN) хоста

Используйте следующую процедуру, чтобы изменить полное доменное имя хостов.

Процедура

Переведите хост в режим обслуживания, чтобы виртуальные машины "на лету" перенеслись на другой хост. Дополнительную информацию см. в Разделе 2.5.3.5. Перевод хоста в режим обслуживания. Либо вручную выключите все виртуальные машины или перенесите их на другой хост. Дополнительную информацию см. в разделе Ручная миграция виртуальных машин Руководстве пользователя.
Нажмите Удалить (Remove) и затем OK, чтобы удалить хост из Портала администрирования.
Для обновления имени хоста воспользуйтесь инструментом hostnamectl.
```
hostnamectl set-hostname ++_++NEW++_++FQDN++_++
```
Перезагрузите хост.
Заново зарегистрируйте хост в Менеджере управления. Дополнительную информацию см. в 2.5.3.1. Добавление стандартных хостов в Менеджер управления”.

2.7.11.1. Поддержка работы в сетях IPv6

В большинстве ситуаций ПО «zVirt Max» поддерживает статическую адресацию в IPv6-сетях.

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

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

Поддерживается только статическая IPv6-адресация. Динамическая IPv6-адресация с DHCP или * Автоматическая конфигурация адресов без сохранения состояния (Stateless Address Autoconfiguration)* не поддерживаются.
Одновременная адресация IPv4 и IPv6 не поддерживается.
При работе в OVN-сетях может использоваться только IPv4 или IPv6.
Переключение кластеров от использования IPv4 к IPv6 не поддерживается.
Для IPv6 можно задать только один шлюз на хост.
Если обе сети используют один шлюз (находятся в одной подсети), то можно передать роль маршрута по умолчанию от сети управления (ovirtmgmt) другой логической сети. Хост и Менеджер управления должны иметь один и тот же шлюз IPv6. Если хост и Менеджер управления находятся в разных подсетях, то Менеджер управления может потерять связь с хостом, поскольку шлюз IPv6 был удален.

2.7.11.2. Установка и настройка SR-IOV

В этом разделе описаны шаги по установке и настройке SR-IOV со ссылками на разделы, подробно описывающие каждый шаг.

Процедура

Чтобы установить и настроить SR-IOV, выполните следующие шаги.

Настройте сквозной доступ PCI на хосте.
Измените конфигурацию виртуальных функций на сетевой карте.
Включите сквозной доступ в Профиле vNIC.

Настройте виртуальные машины с виртуальными сетевыми картами (vNIC) с включенным SR-IOV, чтобы уменьшить время неработоспособности сети во время миграции.

Количество виртуальных сетевых карт со сквозным доступом зависит от количества доступных виртуальных функций (VF) на хосте. Например, чтобы запустить виртуальную машину (ВМ) с тремя картами SR-IOV (vNIC), на хосте должны быть включены как минимум три виртуальные функции.
Поддерживаются горячее подключение и отключение.
Поддерживается миграция во время работы.
Для переноса виртуальной машины на хосте-приемнике также должно быть достаточно доступных виртуальных функций, чтобы ее принять. Во время миграции виртуальная машина высвобождает ряд виртуальных функций на хосте-источнике и занимает такое же количество виртуальных функций на хосте-приемнике.
На хосте устройство, канал или ifcae будут отображаться как любой другой интерфейс. Это устройство исчезнет, когда будет подключено к виртуальной машине, и снова появится, когда будет освобождено.
Избегайте подключения устройства хоста непосредственно к виртуальной машине для реализации функции SR-IOV.
Чтобы использовать виртуальную функцию в качестве магистрального (trunk) порта с несколькими VLAN и настроить VLAN в гостевой системе обратитесь на портал технической поддержки.

Вот пример того, как может выглядеть 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

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.7.12. Объединение сетевых интерфейсов (бондинг)

2.7.12.1. Методы бондинга

При бондинге несколько сетевых карт объединяются в одно бонд-устройство; это дает следующие преимущества:

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

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

Для используемого по умолчанию в ПО «zVirt Max» режима бондинга (Mode 4) Dynamic Link Aggregation требуется коммутатор, поддерживающий 802.3ad.

Логические сети объединенного устройства должны быть совместимы. Объединенное устройство может поддерживать только одну логическую сеть, не являющуюся виртуальной локальной сетью (VLAN). Остальные логические сети должны иметь уникальные идентификаторы (ID) VLAN.

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

Создать объединенное сетевое устройство можно одним из следующих способов:

Вручную на Портале администрирования для конкретного хоста
Автоматически с помощью службы LLDP Labeler для необъединенных сетевых карт всех хостов в кластере или центре данных

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

2.7.12.2. Создание объединенного сетевого устройства на Портале администрирования

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

Процедура

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

Перетащите сетевую карту на другую сетевую карту или на объединенное сетевое устройство.

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

В выпадающих меню выберите Имя объединенного сетевого устройства (Bond Name) и Режим бондинга (Bonding Mode). Подробности см. в Разделе 2.4.5.5. Режимы бондинга.
- При выборе Пользовательского (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.

Подключите логическую сеть к новому объединенному сетевому устройству и настройте ее. Инструкции см. в Разделе 2.4.4.3. Изменение сетевых интерфейсов хоста и назначение логических сетей хостам".

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

При желании можно выбрать Проверить соединение между хостом и Engine (Verify connectivity between Host and Engine), если хост находится в режиме обслуживания.
Нажмите OK.

Создание объединенного сетевого устройства с помощью службы LLDP Labeler

Служба LLDP Labeler позволяет автоматически создать объединенное сетевое устройство со всеми необъединенными сетевыми картами для всех хостов в одном или нескольких кластерах или во всем центре данных. Режим бондинга — это (Mode 4) Динамическая агрегация каналов (802.3ad).

Нельзя объединять сетевые карты с несовместимыми логическими сетями.

2.7.12.3. Настройка службы 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 - путь к файлу сертификата, выданного альтернативным Центром сертификации. Если альтернативные сертификаты не используются, оставьте это значение пустым. По умолчанию - пусто.
- 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.3. Изменение сетевых интерфейсов хоста и назначение логических сетей хостам.

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

2.7.12.4. Режимы бондинга

Алгоритм рассеивания пакетов определяется режимом бондинга. (Подробности см. в документе Linux Ethernet Bonding Driver HOWTO). В ПО «zVirt Max» режим бондинга по умолчанию - это (Mode 4) Динамическая агрегация каналов (802.3ad).

ПО «zVirt Max» поддерживает следующие режимы бондинга, так как их можно использовать в сетях виртуальных машин (связанных мостами):

(Mode 1) Active-Backup
- Активна одна сетевая карта. Если активная сетевая карта выйдет из строя, то одна из резервных сетевых карт заменит ее как единственную активную сетевую карту в объединенном сетевом устройстве. MAC-адрес этого объединенного сетевого устройства виден только на порту сетевого адаптера. Это предотвращает путаницу с MAC-адресами, которая может возникнуть, если MAC-адрес объединенного сетевого устройства изменится и будет показывать MAC-адрес новой активной сетевой карты.
(Mode 2) Load Balance (balance-xor)
- Сетевая карта, которая передает пакеты, выбирается путем выполнения операции XOR над MAC-адресом источника и MAC-адресом приемника и умножения на module общего количества сетевых карт. Этот алгоритм обеспечивает выбор одной и той же сетевой карты для каждого MAC-адреса приемника.
(Mode 3) Broadcast

Пакеты передаются на все сетевые карты.
(Mode 4) Dynamic Link Aggregation(802.3ad) (Default)
- Сетевые карты объединяются в группы с одинаковыми настройками скорости и дуплекса. Используются все сетевые карты в активной группе агрегации.
  
  Для (Mode 4) Dynamic Link Aggregation(802.3ad) требуется коммутатор, поддерживающий 802.3ad.

Объединенные сетевые карты должны иметь одинаковые идентификаторы агрегатора. Иначе на вкладке Сетевые интерфейсы (Network Interfaces) Менеджер управления покажет предупреждающий значок с восклицательным знаком на объединенном сетевом устройстве, а параметр ad_partner_mac объединенного сетевого устройства будет иметь значение: 00:00:00:00:00:00. Чтобы проверить идентификаторы агрегатора, введите следующую команду:

cat /proc/net/bonding/_bond0_

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

(Mode 0) Round-Robin
- Сетевые карты передают пакеты в последовательном порядке. Пакеты передаются по циклу, который начинается с первой доступной сетевой карты в объединенном сетевом устройстве и заканчивается последней доступной сетевой картой в нем. Последующие циклы начинаются с первой доступной сетевой карты.
(Mode 5) Balance-TLB, так же называемый Transmit Load-Balance
- Исходящий трафик распределяется в зависимости от нагрузки по всем сетевым картам в объединенном сетевом устройстве. Входящий трафик принимается активной сетевой картой. Если сетевая карта, получающая входящий трафик, выйдет из строя, то будет назначена другая сетевая карта.
(Mode 6) Balance-ALB, так же называемый Adaptive Load-Balance.
- (Mode 6) Balance-TLB сочетается с балансировкой нагрузки по приему для трафика IPv4. Для балансировки нагрузки по приему используется cогласование ARP.

2.8. Хосты

2.8.1. Общие сведения о хостах

Хосты, также именуемые гипервизорами – это физические серверы, на которых работают виртуальные машины. Полная виртуализация обеспечивается благодаря использованию загружаемого модуля ядра Linux, который носит название Kernel-based Virtual Machine (KVM).

KVM позволяет одновременно запускать несколько виртуальных машин под управлением Windows или Linux. Виртуальные машины работают как отдельные Linux процессы и потоки на хост-машине, а дистанционное управление ими осуществляет Менеджер управления. К ПО «zVirt Max» подключены один или несколько хостов.

Хост – это физический 64-разрядный сервер с расширениями Intel VT или AMD-V, на котором работает версия Red OS 7.3 AMD64/Intel 64.

Физический хост в ПО «zVirt Max»:

Должен принадлежать только одному кластеру в системе.
Должен иметь ЦП, которые поддерживают расширения для виртуализации аппаратного обеспечения AMD-V или Intel VT.
Должен иметь ЦП, поддерживающие всю функциональность, предоставляемую типом виртуального процессора, который был выбран при создании кластера.
Должен иметь объем ОЗУ не менее 2 ГБ.
Может иметь назначенного системного администратора с системными разрешениями.

В качестве хоста можно использовать установку Red OS 7.3 на совместимом оборудовании. ПО «zVirt Max» поддерживает хосты, работающие под управлением Red OS 7.3 Server AMD64/Intel 64 с расширениями Intel VT или AMD-V.

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

Сторонние сторожевые системы не следует устанавливать на хостах Red OS, так как они могут мешать работе сторожевого сервиса, предоставляемого службой VDSM.

2.8.2. Возможные состояния хоста

Таблица 49. Возможные состояния хоста
Состояние	Описание	Причины перехода в данное состояние
Соединение (Connecting)	Соединение с хостом не устанавливается в течение некоторого времени, но попытки подключения продолжаются	Проблемы с сетью, или временные проблемы с хостом, или хост не отвечает на ping-запросы
Недоступен (Down)	Хост не работает (недоступен)	Хост выключен, или произошел аппаратный сбой, или серьезная ошибка в операционной системе, или хост отключен от сети
Ошибка (Error)	Хост находится в состоянии ошибки	Обнаружена неисправимая ошибка на хосте или существуют проблемы с внутренними службами zVirt на хосте
Инициализация (Initializing)	Хост находится в процессе инициализации	Хост только что добавлен в систему или перезапущен после обновления
Ошибка установки (Install failed)	Установка хоста завершилась с ошибкой	Проблемы с загрузкой установочных файлов, или ошибка при выполнении установочного скрипта, или несовместимость оборудования
Установка (Installing)	Хост устанавливается	Запущена процедура установки операционной системы и агентов zVirt
Установка ОС (Installing os)	Устанавливается операционная система хоста	Хост находится на этапе установки операционной системы, непосредственно после запуска процедуры усановки
Сброс памяти (Kdumping)	Ядро хоста аварийно завершило работу и сейчас происходит сброс памяти для отладки	Обнаружен kernel panic (падение ядра операционной системы)
Обслуживание (Maintenance)	Хост находится в режиме обслуживания	Хост переведен в режим обслуживания администратором для выполнения плановых работ
Неработоспособен (Non operational)	Хост не является оперативным (не готов к работе)	Хост не проходит необходимые проверки работоспособности или выявлены проблемы с зависимыми службами
Не отвечает (Non responsive)	Хост не отвечает на запросы	Хост перегружен, или завис, или проблемы с сетевым подключением к хосту
Ожидает утверждения (Pending approval)	Хост ожидает одобрения администратора	Хост добавлен в систему, но требует ручного подтверждения администратором перед активацией
Подготовка к обслуживанию (Preparing for maintenance)	Хост готовится к режиму обслуживания	Хост проходит этап подготовки к режиму обслуживания, например, выполняется перемещение виртуальных машин
Перезагрузка (Reboot)	Хост перезагружается	Хост перезагружен администратором вручную или автоматически системой (например, после обновления)
Не назначен (Unassigned)	Хост находится в процессе активации	Хост только что добавлен и еще не назначен для запуска виртуальных машин
Работает (Up)	Хост работает (доступен и готов к работе)	Хост успешно инициализирован, отвечает на запросы и готов к запуску виртуальных машин

2.8.3. Управление хостами

2.8.3.1. Добавление стандартных хостов в Менеджер управления

Всегда используйте Менеджер управления для изменения сетевой конфигурации хостов в кластерах. В противном случае можно создать неподдерживаемую конфигурацию. Дополнительные сведения см. в разделе 2.4.4.1. Конфигурация менеджера сети со сведениями о состоянии (nmstate).

Добавление хоста в ПО «zVirt Max» может занять некоторое время, так как платформа выполняет следующие шаги: проверка поддержки виртуализации, установка пакетов и создание моста.

Процедура

На Портале администрирования выберите Ресурсы (Compute) → Хосты (Hosts).
Нажмите Новый (New).
В выпадающем списке выберите Центр данных (Data Center) и Хост кластера (Host Cluster) для нового хоста.
Введите имя и адрес нового хоста в поля Имя (Name) и Адрес (Address). Стандартный для SSH порт 22 автоматически вводится в поле Порт SSH (SSH Port).
Выберите способ аутентификации, который Менеджер управления будет использовать для доступа к хосту.
- Укажите пароль root-пользователя, чтобы использовать аутентификацию по паролю.
- Либо скопируйте ключ, отображаемый в поле (Публичный ключ SSH (SSH PublicKey), в /root/.ssh/authorize _keys на хосте, чтобы использовать аутентификацию по открытому ключу.
При желании можно нажать Дополнительные параметры (Advanced Parameters), чтобы изменить следующие дополнительные настройки хоста.
- Отключите автоматическую конфигурацию межсетевого экрана.
- Добавьте SSH-отпечаток хоста, чтобы повысить безопасность. Его можно добавить вручную или подтянуть автоматически.
При необходимости настройте управление питанием, если хост имеет поддерживаемую карту с управлением питания. Информацию о настройках параметров управления питанием см. в разделе 2.5.4.2. Описание настроек управления питанием хоста в Руководстве администратора.
Нажмите OK.

Новый хост отображается в списке хостов со статусом Установка (Installing) За ходом установки можно следить в разделе События (Events) на Панели уведомлений (Notification Drawer). После небольшой задержки статус хоста изменится на Включен (Up).

2.8.3.2. Настройка хоста для сквозного доступа PCI

Это один из разделов, описывающих установку и настройку SR-IOV в ПО «zVirt Max». Дополнительную информацию см. в документе Setting Up and Configuring SR-IOV._

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

Настройка хоста для сквозного доступа PCI

Включите расширение виртуализации и расширение IOMMU в BIOS.
Включите флаг IOMMU в ядре, установив флажок Сквозной доступ устройств хоста и SR-IOV (Hostdev Passthrough & SR-IOV) при добавлении хоста в Менеджер управления или изменив конфигурационный файл grub вручную.
- Чтобы включить флаг IOMMU на Портале администрирования, см. Добавление стандартных хостов в Менеджер управления и Описание настроек ядра.
- Чтобы изменить конфигурационный файл grub вручную, см. Включение IOMMU вручную.
Для включения сквозного доступа к графическому процессору нужно выполнить дополнительные действия по настройке как на хосте, так и в гостевой системе.

Включение 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 можно попытаться добавить iommu=pt. Опция pt включает IOMMU только для устройств в сквозном доступе и обеспечивает более высокую производительность хоста. Однако эта опция поддерживается не на всем оборудовании. Если опция pt для вашего хоста не работает, вернитесь к предыдущей опции.

Если сквозной доступ включить не удастся из-за того, что оборудование не поддерживает переназначение прерываний, можно попробовать включить опцию allow_unsafe_interrupts, если виртуальные машины являются доверенными. По умолчанию опция allow_unsafe_interrupts выключена, поскольку включить ее – значит потенциально подвергнуть хост MSI-атакам со стороны виртуальных машин. Чтобы включить ее, добавьте в файл /etc/modprode.d следующую информацию:

vi /etc/modprobe.d

options vfio_iommu_type1 allow_unsafe_interrupts=1

Обновите файл grub.cfg и перезагрузите хост, чтобы эти изменения вступили в силу:
```
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
```

Информацию о том, как включить SR-IOV и назначить выделенные виртуальные сетевые карты к виртуальным машинам, доступна в рамках портала технической поддержки.

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

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

Вложенная виртуализация позволяет одним виртуальным машинам осуществлятьхостинг других виртуальных машин. Для ясности назовем их родительскимивиртуальными машинами (parent virtual machines) и вложенными виртуальными машинами (nested virtual machines).

Дочерние виртуальные машины видимы и управляются только пользователями, имеющими доступ к родительской виртуальной машине. Они невидимы дляmадминистраторов ПО «zVirt Max».

По умолчанию вложенная виртуализация в ПО «zVirt Max» выключена. Чтобы включить вложенную виртуализацию, установите хук 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, то вложенная виртуализация включена.
Повторите эту процедуру для всех хостов в кластере.

2.8.3.4. Включение вложенной виртуализации для отдельных виртуальных машин

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

Вложенная виртуализация позволяет одним виртуальным машинам осуществлять хостинг других виртуальных машин. Для ясности назовем их родительскими виртуальными машинами (parent virtual machines) и вложенными виртуальными машинами (nested virtual machines).

Дочерние виртуальные машины видимы и управляются только пользователями, имеющими доступ к родительской виртуальной машине. Они невидимы для администраторов ПО «zVirt Max».

Чтобы включить вложенную виртуализацию не на всех, а лишь на некоторых виртуальных машинах, настройте хост или хосты на поддержку вложенной виртуализации. Затем настройте виртуальную машину или виртуальные машины на запуск на этих конкретных хостах и включите Сквозной доступ ЦП хоста (Pass-Through Host CPU). Эта опция позволяет виртуальным машинам использовать настройки вложенной виртуализации, которые вы только что задали на хосте. Эта опция также указывает, на каких хостах могут работать виртуальные машины, и требует ручной миграции.

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

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

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

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

Процедура

Настройте хосты на поддержку вложенной виртуализации:

На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts).
Выберите хост в кластере, где хотите включить вложенную виртуализацию, и нажмите Управление (Management) → Обслуживание (Maintenance) и затем OK.
Выберите хост снова, нажмите Консоль хоста (Host Console) и авторизуйтесь на консоли хоста.
В окне Изменить хост (Edit Host) выберите вкладку Ядро (Kernel).
Если в блоке Параметры загрузки ядра (Kernel boot parameters) флажки неактивны, нажмите СБРОС (RESET).
Выберите Вложенную виртуализацию (Nested Virtualization) и нажмите OK.

Это действие выведет параметр kvm-<architecture>.nested=1 в Командной строке ядра (Kernel command line). Выполнение следующих действий добавит этот параметр в Текущую командную строку ядра (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) выберите Сквозной доступ ЦП хоста (Pass-Through Host CPU). Это действие автоматически установит Режим миграции (Migration mode) в значение Разрешить только ручную миграцию (Allow manual migration only).

2.8.3.5. Перевод хоста в режим обслуживания

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

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

Виртуальные машины, которые закреплены за хостом и не могут быть перенесены, выключаются. Чтобы выяснить, какие виртуальные машины закреплены за хостом, нажмите Закреплены за хостом (Pinned to Host) на вкладке Виртуальные машины (Virtual Machines) в подробном представлении хоста.

Перевод хоста в режим обслуживания

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите нужный хост.
Нажмите Управление (Management) → Обслуживание (Maintenance). Откроется окно подтверждения Хосты в режиме обслуживания (Maintenance Host(s)).

Если нужно, укажите Причину (Reason) перевода хоста в режим обслуживания, которая будет отображаться в журналах и при повторной активации хоста. Затем нажмите OK.

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

Нажмите OK, чтобы перейти в режим обслуживания.

Все работающие виртуальные машины переносятся на альтернативные хосты. Если хост выполняет роль Менеджера пула хранения (SPM), то эта роль переносится на другой хост. Поле Статус (Status) хоста меняется на Подготовка к обслуживанию (Preparing for Maintenance) и наконец на Обслуживание (Maintenance), когда операция успешно завершается. VDSM не останавливается, пока хостnнаходится в режиме обслуживания.

Если миграция какой-либо виртуальной машины заканчивается неудачей, нажмите Управление (Management) → Активировать (Activate) на хосте, чтобы остановить операцию перевода в режим обслуживания, затем нажмите Отменить миграцию (Cancel Migration) на виртуальной машине, чтобы остановить миграцию.

2.8.3.6. Активация хоста из режима обслуживания

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Активировать (Activate).

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

2.8.3.7. Настройка правил межсетевого экрана для хостов

С помощью 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

Сохраните файл в другое место.

Новые или переустановленные хосты настраиваются с помощью обновленных правил межсетевого экрана.

Существующие хосты нужно переустановить, нажав Установка (Installation) → Переустановить (Reinstall) и выбрав Автоматически настроить межсетевой экран хоста (Automatically configure host firewall).

2.8.3.8. Удаление хоста

Иногда бывает нужно удалить хост из ПО «zVirt Max», например, если его нужно переустановить.

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance).
Как только хост перейдет в режим обслуживания, нажмите Удалить (Remove). Откроется окно с запросом на подтверждение удаления хостов Удалить хост(-ы) (Remove Host(s)).
Нажмите OK.

2.8.3.9. Обновление хостов между промежуточными релизами

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

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

Вы можете обновить все хосты в кластере вместо обновления хостов по отдельности. Это особенно полезно при обновлении до новых версий ПО «zVirt Max».

Обновить один кластер за раз.

Ограничения

В ПО «zVirt Max» при обновлении данные сохраняется только в каталогах /etc и /var. Данные в остальных каталогах перезаписываются во время обновления.
Если в кластере включена миграция, то виртуальные машины будут автоматически перенесены на другой хост в кластере.
В среде hosted engine виртуальная машина с Менеджером управления может выполнять миграцию только между узлами с ролью hosted engine в одном и том же кластере. Она не может выполнять миграцию на стандартные хосты.
В кластере должно быть зарезервировано достаточно памяти для хостов, чтобы можно было проводить обслуживание. В противном случае миграция виртуальной машины зависнет и завершится сбоем. Использование памяти обновлениями хостов можно снизить, отключив некоторые или все виртуальные машины перед обновлением хостов. * Нельзя перенести на другой хост закрепленную виртуальную машину (например, виртуальную машину, использующую vGPU). Во время обновления закрепленные виртуальные машины выключаются, если только вы не решите пропустить этот хост.

Процедура

На Портале администрирования нажмите Ресурсы (Compute) → Кластеры (Clusters) и выберите кластер. Столбец Статус обновления (Upgrade status) показывает, доступно ли обновление для каких-либо хостов в кластере.
Нажмите Обновить (Upgrade).
Выберите хосты для обновления, затем нажмите Далее (Next).
Настройте параметры:
- Остановить закрепленные ВМ (Stop Pinned VMs) – выключает все виртуальные машины, закрепленные на хостах в кластере; по умолчанию флажок стоит. Флажок можно снять, чтобы пропустить обновление этих хостов и не прерывать работу закрепленных виртуальных машин, например, когда на закрепленной виртуальной машине выполняются важные службы или процессы и нужно предотвратить ее непредсказуемое выключение во время обновления.
- Таймаут обновления (мин.) (Upgrade Timeout (Minutes)) – задает время ожидания обновления отдельного хоста до того, как обновление кластера завершится ошибкой из-за превышения времени ожидания. Значение по умолчанию – 60. Это значение можно увеличить для больших кластеров, в которых 60 минут недостаточно, или уменьшить для небольших кластеров, где хосты обновляются быстро.
- Проверить обновление (Check Upgrade) – проверяет наличие доступных обновлений для каждого хоста перед запуском процесса обновления. По умолчанию этот флажок снят, но его можно установить, чтобы точно охватить последние обновления, например, если, согласно настройкам, Менеджер управления проверяет обновления хоста реже, чем было задано по умолчанию.
- Перезагрузить после обновления (Reboot After Upgrade) – перезагружает каждый хост после его обновления; по умолчанию флажок стоит. Для ускорения процесса флажок можно снять, если ясно, что в очереди больше нет обновлений, после установки которых потребуется перезагрузка хоста.
- Использовать политику обслуживания (Use Maintenance Policy) – для политики планирования кластера задает значение cluster_maintenance во время обновления. Этот флажок установлен по умолчанию, поэтому активность ограничена, и виртуальные машины не могут запускаться, если они не являются виртуальными машинами высокой доступности. Флажок можно снять, если во время обновления будет использоваться пользовательская политика планирования, но это может привести к непредсказуемым последствиям. Прежде чем снимать флажок, убедитесь, что пользовательская политика совместима с действиями по обновлению кластера.
Нажмите Далее (Next).
Просмотрите сводку по хостам и виртуальным машинам, которые будут затронуты.
Нажмите Обновить (Upgrade).

Ход обновления хоста можно отслеживать здесь:

на вкладке Ресурсы (Compute) → Кластеры (Clusters) в столбце Статус обновления (Upgrade Status) отображается Выполняется обновление (Upgrade in progress);
на вкладке Ресурсы (Compute) → Хосты (Hosts);
в разделе События (Events) на Панели уведомлений (Notification Drawer).

Ход миграции отдельных виртуальных машин можно отслеживать в столбце Статус (Status) вкладки Ресурсы (Compute) → Виртуальные машины (Virtual Machines). В больших средах может возникнуть надобность отфильтровать результаты, чтобы показать конкретную группу виртуальных машин.

Обновление отдельных хостов

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

Менеджер обновлений проверяет только хосты со статусом Включен (Up) или Не работоспособен (Non-operational), но не со статусом Обслуживание (Maintenance).

Ограничения

В ПО «zVirt Max» при обновлении данные сохраняется только в каталогах /etc и /var. Данные в остальных каталогах перезаписываются во время обновления.
Если в кластере включена миграция, то виртуальные машины будут автоматически перенесены на другой хост в кластере. Обновляйте хост при относительно низком уровне его использования.
В среде hosted engine виртуальная машина c Менеджером управления может выполнять миграцию только между узлами с ролью hosted engine в одном и том же кластере. Она не может выполнять миграцию на стандартные хосты.
В кластере должно быть зарезервировано достаточно памяти для хостов, чтобы можно было проводить обслуживание. В противном случае миграция виртуальной машины зависнет и завершится сбоем. Использование памяти обновлениями хостов можно снизить, отключив некоторые или все виртуальные машины перед обновлением хостов.
Не обновляйте все хосты одновременно, так как один хост должен оставаться доступным для выполнения задач Менеджера пула хранения (SPM).
Нельзя перенести на другой хост закрепленную виртуальную машину (например, виртуальную машину, использующую vGPU). Закрепленные виртуальные машины должны быть выключены перед обновлением хоста.

Процедура

Убедитесь, что включены необходимые репозитории. Для просмотра списка включенных репозиториев, выполните команду dnf repolist.
На Портале администрирования нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост для обновления.
Нажмите Установка (Installation) → Проверить наличие обновлений (Check for Upgrade) и нажмите OK.
Откройте Панель уведомлений (Notification Drawer) и раскройте раздел События (Events), чтобы увидеть результат.
Если обновление доступно, то нажмите Установка (Installation) → Обновить (Upgrade).
Нажмите OK, чтобы обновить хост. Работающие виртуальные машины будут перенесены в соответствии с их политикой миграции Если миграция отключена для каких-либо виртуальных машин, то вам будет предложено выключить их.

Сведения о хосте обновляются на вкладке Ресурсы (Compute) → Хосты (Hosts), а статус меняется следующим образом: Обслуживание (Maintenance) → Установка (Installing) → Перезагрузка (Reboot) → Включен (Up)

Если не удастся выполнить обновление, то статус хоста поменяется на Не удалось установить (Install Failed). В разделе Не удалось установить (Install Failed) снова нажмите Установка (Installation) → Обновить (Upgrade).

Повторите эту процедуру для каждого хоста в ПО «zVirt Max».

Обновлять хосты нужно с Портала администрирования. Но вместо этого можно обновить хосты с помощью dnf upgrade.

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

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

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

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

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

Процедура

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

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

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

2.8.3.11. Просмотр состояния хоста

Кроме обычного Статуса (Status), у хостов есть внешний статус состояния. О внешнем статусе состояния сообщают подключаемые модули или внешние системы, его может задать администратор, и он отображается слева от Имени (Name) хоста в виде одного из следующих значков:

OK: Без значка
Информация (Info):
Предупреждение (Warning):
Ошибка (Error):
Отказ (Failure):

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

Статус состояние хоста также можно посмотреть через REST API. Запрос GET на хост будет включать в себя элемент external_status, который содержит статус состояния.

2.8.3.12. Просмотр устройств хоста

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

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts).
Нажмите на имя хоста. Откроется подробное представление.
Откройте вкладку Устройства хоста (Host Devices).

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

2.8.3.13. Настройка устаревшего шифра SPICE

По умолчанию консоли SPICE используют FIPS-совместимое шифрование и строку шифра. По умолчанию используется следующая строка шифра SPICE: kECDHE+FIPS:kDHE+FIPS:kRSA+FIPS:!eNULL:!aNULL

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

Можно изменить строку шифра, используя Ansible-плейбук.

Изменение строки шифра

На машине с Менеджером управления создайте файл в каталоге /usr/share/ovirt-engine/playbooks. Например:
```
vim /usr/share/ovirt-engine/playbooks/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

Запустите только что созданный файл:
```
ansible-playbook -l _hostname_ /usr/share/ovirt-engine/playbooks/change-spice-cipher.yml
```
Либо можно переконфигурировать хост Ansible-плейбуком ovirt-host-deploy, используя опцию --extra-vars с переменной host_deploy_spice_cipher_string:
```
ansible-playbook -l _hostname_ \
  --extra-vars host_deploy_spice_cipher_string=”DEFAULT:-RC4:-3DES:-DES” \
  /usr/share/ovirt-engine/playbooks/ovirt-host-deploy.yml
```

2.8.3.14. Настройка параметров управления питанием хоста

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

Настроить управление питанием хоста необходимо, чтобы использовать высокую доступность хоста и высокую доступность виртуальной машины. Дополнительные сведения об устройствах управления питанием см. в разделе Управление питанием в Техническом справочнике (Technical Reference).

Процедура

Нажмите Ресурсы (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 Max» поддерживает только статическую адресацию для IPv6. Одновременная адресация (IPv4 и IPv6) не поддерживается.

Выпадающий список в разделе Управление (Management) → Управление питанием (Power Management) теперь стал активным на Портале администрирования.

2.8.3.15. Настройка параметров для Менеджера пула хранения хоста

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

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts).
Нажмите Изменить (Edit).
Откройте вкладку SPM.
С помощью кнопок-переключателей выберите для хоста подходящий приоритет SPM.
Нажмите OK.

2.8.3.16. Перенос хостов с ролью hosted engine на другой кластер

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

Необходимо забрать у хоста роль hosted engine, удалив конфигурацию hosted engine с хоста.

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance). Статус хоста изменится на Обслуживание (Maintenance).
В блоке Переустановить (Reinstall) нажмите Удалить роль Hosted Engine (Hosted Engine UNDEPLOY).
Нажмите Переустановить (Reinstall).
Нажмите Изменить (Edit).
Выберите целевой центр данных и кластер.
Нажмите OK.
Нажмите Управление (Management) → Активировать (Activate).

2.8.4. Описание настроек и регулирующих механизмов в окнах "Создать хост" и "Изменить хост"

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

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

В таблице настроек Общие (General) содержится информация, которая должна быть указана на вкладке Общие (General) окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 50. Общие настройки
Имя поля	Описание
Хост кластера (Host Cluster)	Кластер и центр данных, к которым относится хост.
Имя (Name)	Имя хоста. Длина этого текстового поля ограничена 40 знаками. Имя должно быть уникальным и представлять собой любую комбинацию латинских букв в верхнем или нижнем регистре, цифр, дефисов или знаков подчеркивания.
Комментарий (Comment)	Поле для добавления обычного текста в читаемой человеком форме – комментариев, относящихся к хосту.
Имя хоста (Hostname)	IP-адрес или разрешимое имя хоста. Если используется разрешимое имя хоста, то необходимо убедиться, что все адреса, по которым разрешается имя хоста, соответствуют IPv4- и IPv6-адресам, используемым сетью управления хоста.
Пароль (Password)	Пароль root-пользователя хоста. Установите пароль при добавлении хоста. После этого пароль нельзя изменить.
Включить хост после установки (Activate host after install)	Установите этот флажок, чтобы активировать хост после успешной установки. Этот параметр включен по умолчанию и необходим для успешной активации гипервизоров. После успешной установки можно снять этот флажок, чтобы переключить статус хоста в режим Обслуживание (Maintenance). Это позволит администратору выполнять дополнительные задачи по настройке гипервизоров.
Перезагрузить хост после установки (Reboot host after install)	Установите этот флажок, чтобы перезагрузить хост после установки. Флажок стоит по умолчанию. NOTE: Изменение параметров командной строки ядра хоста или изменение типа межсетевого экрана кластера также требует перезагрузки хоста.
Публичный ключ SSH (SSH Public Key)	Скопируйте содержимое текстового поля в файл /root/.ssh/authorized_hosts на хосте, чтобы использовать для аутентификации на хосте SSH-ключ Менеджера управления, а не пароль.
Автоматически настроить межсетевой экран хоста (Automatically configure host firewall)	При добавлении нового хоста Менеджер управления может открывать требуемые порты на межсетевой экран хоста. Флажок стоит по умолчанию. Это – Дополнительный параметр (Advanced Parameter).
Публичный ключ SSH хоста (SSH Fingerprint)	Можно получить (fetch) SSH-отпечаток хоста и сравнить его с отпечатком, который ожидается от хоста, чтобы убедиться, что они совпадают. Это – Дополнительный параметр (Advanced Parameter).

2.8.4.2. Описание настроек управления питанием хоста

В таблице настроек Управление питанием (Power Management) содержится информация, которая должна быть указана на вкладке Управление питанием (Power Management) окон Новый хост (New Host) или Изменить хост (Edit Host). Управление питанием можно настроить, если у хоста есть поддерживаемая карта управления питанием.

Таблица 51. Настройки Управления питанием
Имя поля	Описание
Включить управление питанием (Enable Power Management)	Включает управление питанием на хосте. Установите этот флажок, чтобы сделать активными остальные поля на вкладке Управление питанием (Power Management).
Интеграция Kdump + (Kdump integration)	Предотвращает изоляцию хоста во время создания аварийного дампа ядра, чтобы процесс не прерывался. Если kdump доступен на хосте, но его конфигурация недействительна (служба kdump не может быть запущена), включение Интеграции Kdump (Kdump integration) приведет тому, что (повторная) установка хоста завершится ошибкой. В этом случае см. Раздел 2.5.5.4. Расширенная конфигурация 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)

Таблица 52. Настройки окна Изменить 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 – HP Integrated Lights-Out. ipmilan – Intelligent Platform Management Interface и устройства управления Sun Integrated Lights Out. rsa – IBM Remote Supervisor Adapter. rsb – интерфейс управления Fujitsu-Siemens RSB. wti – сетевой переключатель питания WTI. Дополнительные сведения об устройствах управления питанием см. в разделе Управление питанием в Техническом справочнике.
Порт (Port)	Номер порта, который устройство управления питанием использует для связи с хостом.
Слот (Slot)	Номер, который используется для идентификации блейда устройства управления питанием.
Профиль службы (Service Profile)	Имя профиля службы, которое используется для идентификации блейда устройства управления питанием. Это поле появляется вместе поля Слот (Slot), когда тип устройства - cisco_ucs.
Опции (Options)	Специальные опции устройства управления питанием. Указываются в формате 'key=значение'. См. доступные опции в документации на устройство управления питанием хоста. Если cisco_ucs используется в качестве устройства управления питанием для хостов Red Hat Enterprise Linux 7, то также необходимо добавить ssl_insecure=1 в поле Опции (Options) .
Безопасность (Secure)	Поставьте этот флажок, чтобы разрешить устройству управления питанием безопасно соединяться с хостом. Для этого можно использовать ssh, ssl или другие протоколы аутентификации в зависимости от агента управления питанием.

2.8.4.3. Описание настроек приоритета SPM

В таблице настроек SPM содержится информация, которая должна быть указана на вкладке SPM окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 53. Настройки SPM
Имя поля	Описание
Приоритет SPM (SPM Priority)	Определяет вероятность того, что хосту будет назначена роль SPM. Возможные варианты выбора приоритета: Низкий (Low), Нормальный (Normal) и Высокий (High). "Низкий" означает низкую вероятность того, что хосту будет назначена роль SPM, а "Высокий " означает высокую вероятность. По умолчанию выбирается вариант "Нормальный".

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

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

Таблица 54. Настройки консоли (Console settings)
Имя поля	Описание
Переопределить отображаемый адрес (Override display address)	Поставьте этот флажок, чтобы переопределить адреса дисплея хоста. Это полезная опция, если хосты определяются внутренним IP-адресом и располагаются за межсетевым экраном NAT. Когда пользователь подключается к виртуальной машине не из внутренней сети, виртуальная машина возвращает не частный адрес хоста, на котором она работает, а публичный IP-адрес или FQDN (который разрешается во внешней сети в публичный IP-адрес).
Адрес дисплея (Display address)	Указанный здесь адрес дисплея будет использоваться для всех виртуальных машин, работающих на данном хосте. Адрес должен иметь формат FQDN или IP-адреса.

2.8.4.5. Описание настроек провайдера сети

В таблице настроек Провайдер сети (Network Provider) описана информация, которая должна быть указана на вкладке Провайдер сети (Network Provider) окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 55. Настройки Провайдера сети (Network Provider)
Имя поля	Описание
Внешний провайдер сети (External Network Provider)	Если вы добавили внешнего провайдера сети и хотите, чтобы сеть хоста предоставлялась внешним провайдером сети, выберите его из списка.

2.8.4.6. Описание настроек ядра

В таблице настроек Ядро (Kernel) описана информация, которая должна быть указана на вкладке Ядро (Kernel) окон Новый хост (New Host) или Изменить хост (Edit Host). Общие загрузочные параметры ядра перечислены в виде флажков, с которыми легко работать.

Если нужно внести более сложные изменения, используйте текстовое поле для ввода текста в свободной форме рядом с Командной строкой ядра (Kernel command line), чтобы добавить любые необходимые параметры. После изменения любых параметров командной строки ядра переустановитехост.

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

Таблица 56. Настройки ядра
Имя поля	Описание
Passthrough устройств хоста и SR-IOV (Hostdev Passthrough & SR-IOV)	Включает флаг IOMMU в ядре, чтобы виртуальная машина могла использовать устройство хоста, как если бы оно было подключено непосредственно к виртуальной машине. Аппаратное и микропрограммное обеспечение хоста также должны поддерживать IOMMU. На оборудовании должны быть включены расширение виртуализации и расширение IOMMU. См. Настройка сквозного доступа PCI-устройств на хосте.
Вложенная виртуализация (Nested Virtualization)	Включает флаг vmx или svm, позволяющий виртуальным машинам работать внутри виртуальных машин. Вложенная виртуализация – это предварительная версия технологии, представленная для оценки: Она предназначена только для оценки и не поддерживается в продуктивных средах. Чтобы использовать эту настройку, установите хук 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 (FIPS mode)	Включает режим FIPS. Дополнительную информацию см. в Разделе D.4, “Настройка хостов FIPS с помощью Менеджера управления”.
Командная строка ядра (Kernel command line)	Это поле позволяет добавить дополнительные параметры ядра к параметрам по умолчанию.

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

2.8.4.7. Описание настроек Hosted Engine

В таблице параметров Hosted Engine описана информация, которая должна быть указана на вкладке Hosted Engine окон Новый хост (New Host) или Изменить хост (Edit Host).

Таблица 57. Настройки Hosted Engine
Имя поля	Описание
Настроить хост для размещения на нём ВМ HostedEngine (Choose hosted engine deployment action)	Доступны три варианта: Нет (None) – никакие действия не требуются. Да (Deploy) – выберите эту опцию, чтобы развернуть хост как узел с ролью hosted engine. Отменить развертывание (Undeploy) – выберите эту опцию для узла с ролью hosted engine, чтобы отменить развертывание хоста и удалить конфигурации, связанные с ролью hosted engine.

2.8.5. Устойчивость хоста

2.8.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 см. в разделе 3.6.2.2. Синтаксис команды engine-config.

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

После запуска Менеджера управления он – по истечении времени ожидания (по умолчанию – 5 минут) – автоматически пытается изолировать не реагирующие на запросы хосты, для которых включено управление питанием. Время ожидания можно настроить, изменив значение параметра engine-config DisableFenceAtStartupInSec.

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

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

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

2.8.5.2. Управление питанием с прокси в ПО «zVirt Max»

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

Варианты выбора:

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

Работоспособный изолирующий прокси-хост имеет статус либо Включен (UP), либо Обслуживание (Maintenance).

2.8.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) устройства управления питанием.
Введите номер порта SSH (SSH Port), который устройство управления питанием использует для связи с хостом.
Введите номер слота (Slot), используемый для идентификации блейда устройства управления питанием.
Введите Параметры (Options) для устройства управления питанием. Используйте список записей в формате 'key=значение', разделенных запятыми.
Поставьте флажок Безопасность (Secure), чтобы позволить устройству управления питанием безопасно соединяться с хостом.

Нажмите Тестировать (Test), чтобы убедиться в правильности настроек. После успешной проверки появится сообщение Проверка прошла успешно, Статус хоста: включен (Test Succeeded, Host Status is: on).

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

Нажмите OK, чтобы закрыть окно Изменить fence-агента (Edit fence agent).
На вкладке Управление питанием (Power Management) при желании можно развернуть блок Расширенные параметры (Advanced Parameters) и кнопками "вверх" и "вниз" задать порядок, в котором Менеджер управления будет искать изолирующий прокси в кластере и центре данных хоста.
Нажмите OK.

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

2.8.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.8.5.5. Конфигурация прослушивающего процесса fence_kdump

Измените конфигурацию прослушивающего процесса fence_kdump. Это необходимо только тогда, когда конфигурации по умолчанию недостаточно.

Процедура

Создайте новый файл (например, my-fence-kdump.conf) в /etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/.

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

Отредактированные значения нужно также изменить в engine-config, как указано в Таблице параметров конфигурации прослушивающего процесса fence_kdump (fence_kdump Listener Configuration Options) в Разделе 2.5.5.6. Настройка fence_kdump в Менеджере управления.

Перезапустите прослушивающий процесс fence_kdump:
```
systemctl restart ovirt-fence-kdump-listener.service
```
При необходимости можно изменить следующие параметры:

Таблица 58. Параметры конфигурации прослушивающего процесса 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.

Настройка fence_kdump в Менеджере управления

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

engine-config -g _OPTION_

Процедура

Измените конфигурацию kdump командой engine-config:

engine-config -s _OPTION_=_value_

Отредактированные значения нужно также изменить в файле конфигурации прослушивающего процесса fence_kdump, как указано в таблице Параметры конфигурации kdump (Kdump Configuration Options). См. Раздел 2.5.5.5. Конфигурация прослушивающего процесса fence_kdump.

Перезапустите службу ovirt-engine:
```
systemctl restart ovirt-engine.service
```
Если необходимо, переустановите все хосты с включенной Интеграцией kdump (Kdump integration) (см. таблицу ниже).

Следующие параметры можно настроить с помощью engine-config:

Таблица 59. Параметры конфигурации 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.8.5.6. Программная изоляция хостов

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

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

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

При первом сбое сети статус хоста меняется на Подключается (connecting).
Затем Менеджер управления делает три попытки запросить статус у VDSM или ждет в течение интервала, определяемого нагрузкой на хост. Формула определения длительности интервала задается параметрами конфигурации TimeoutToResetVdsInSeconds (по умолчанию – 60 секунд) + [DelayResetPerVmInSeconds (по умолчанию – 0,5 секунд)] * (количество работающих виртуальных машин на хосте) + [DelayResetForSpmInSeconds (по умолчанию – 20 секунд)] * 1 (если хост работает как SPM) или 0 (если хост не работает как SPM). Чтобы дать VDSM максимальное время для ответа, Менеджер управления выбирает более продолжительный из двух вышеупомянутых вариантов (три попытки получить статус VDSM или интервал, определяемый вышеприведенной формулой).
Если хост не реагирует и после истечения этого интервала, то vdsm restart выполняется по SSH.
Если vdsm restart не помогает восстановить соединение между хостом и Менеджером управления, то статус хоста меняется на Не отвечает (Non Responsive) и, если управление питанием настроено, задача изоляции передается внешнему агенту изоляции.

Программную изоляцию по SSH можно выполнять на хостах, на которых не настроено управление питанием. Она отличается от просто изоляции, которая может выполняться только на хостах, на которых настроено управление питанием.

2.8.5.7. Использование функций управления питанием хоста

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

Процедура

Нажмите Ресурсы (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.8.5.8. Изолирование хоста, не реагирующего на запросы, вручную

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

Не выбирайте Подтвердить "Хост был перезагружен" (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.9. Хранилище

2.9.1. О хранилище ПО «zVirt Max»

В ПО «zVirt Max» используется централизованная система хранения для виртуальных дисков, файлов ISO и моментальных снимков. Взаимодействие с хранилищем по сети может быть организовано с помощью:

Network File System (NFS);
других файловых систем, совместимых с POSIX;
Интерфейса малых компьютерных систем Интернета (iSCSI);
локального хранилища, подключенного непосредственно к хостам виртуализации;
протокола оптоволоконного канала (Fibre Channel Protocol, FCP);
параллельной NFS (pNFS).

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

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

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

В ПО «zVirt Max» есть три типа доменов хранения:

Домен данных: Домен данных содержит виртуальные жесткие диски и файлы OVF всех виртуальных машин и шаблонов в центре данных. В нем же хранятся моментальные снимки виртуальных машин.
- Домен данных не может использоваться несколькими центрами данных. К одному центру данных можно добавлять домены данных разных типов (iSCSI, NFS, FC и POSIX) при условии, что все они являются общими, а не локальными.
- Домен данных нужно подключать к центру данных до подключения доменов других типов.
Домен ISO: Домены ISO хранят файлы ISO (или логические CD), используемые для установки и загрузки операционных систем и приложений для виртуальных машин. Домен ISO избавляет центр данных от потребности в физических носителях. Домен ISO не может использоваться несколькими центрами данных. Домен ISO может базироваться только на NFS. К центру данных можно добавить только один домен ISO.
Домен экспорта: Домены экспорта – это репозитории временного хранения, используемые для копирования и перемещения образов между центрами данных и инсталяциями ПО «zVirt Max». Домены экспорта могут использоваться для резервного копирования виртуальных машин. Домен экспорта можно перемещать между центрами данных, но активным он может быть только в одном центре данных в каждый конкретный момент времени. Домен экспорта может базироваться только на NFS. К центру данных можно добавить только один домен экспорта.

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

Приступайте к настройке и подключению хранилища для_ ПО «zVirt Max» только после определения потребностей центра данных в ресурсах хранения.

2.9.2. Концепция доменов хранения

Домен хранения – это набор образов, имеющих общий интерфейс хранения. Домен хранения содержит полные образы шаблонов и виртуальных машин (включая моментальные снимки) или файлы ISO. Домен хранения может состоять из блочных устройств (SAN - iSCSI или FCP) или файловой системы (NAS - NFS или иных POSIX-совместимых файловых систем).

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

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

В SAN (iSCSI/FCP) каждый виртуальный диск, шаблон или моментальный снимок представляет собой логический том. Блочные устройства объединяются в логическую сущность, называемую группой томов, а затем с помощью Менеджера логических томов (Logical Volume Manager, LVM) делятся на логические тома для использования в качестве виртуальных жестких дисков.

Виртуальные диски могут иметь один из двух форматов: QCOW2 или raw.

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

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

2.9.3. Возможные состояния доменов хранения

Таблица 60. Возможные состояния доменов хранения
Состояние	Описание	Причины перехода в данное состояние
Активация (Activating)	Домен хранения находится в процессе активации	Выполняется попытка подключить домен хранения к хостам, на которых он будет использоваться
Активен (Active)	Домен хранения активен и доступен для использования	Домен хранения успешно подключен к хостам и готов к хранению виртуальных дисков и образов
Отключение (Detaching)	Домен хранения находится в процессе отключения	Выполняется отключение домена хранения от хостов, на которых он использовался
Неактивен (Inactive)	Домен хранения неактивен и недоступен для использования	Домен хранения не подключен к хостам или не настроен для использования
Заблокирован (Locked)	Домен хранения заблокирован и недоступен для изменений	Домен хранения заблокирован администратором или системой для предотвращения случайных изменений
Обслуживание (Maintenance)	Домен хранения находится в режиме обслуживания	Домен хранения переведен в режим обслуживания для выполнения плановых работ или устранения неполадок
Смешанный (Mixed)	Состояние домена хранения является смешанным, что указывает на наличие проблем	Некоторые хосты могут иметь доступ к домену хранения, а другие - нет. Требуется диагностика для устранения проблем
Подготовка к обслуживанию (Preparing_for_maintenance)	Домен хранения готовится к режиму обслуживания	Выполняется перемещение данных с домена хранения на другие хранилища перед его переводом в режим обслуживания
Не присоединен (Unattached)	Домен хранения не присоединен ни к одному хосту	Домен хранения создан, но еще не настроен для использования на хостах
Неизвестно (Unknown)	Статус домена хранения неизвестен	Возникновение проблем со связью или других ошибок

2.9.4. Подготовка и добавление хранилища NFS

2.9.4.1. Подготовка хранилища NFS

Настройте общие ресурсы NFS в файловом хранилище или на удаленном сервере, чтобы они служили доменами хранения в системах хостов ПО «zVirt Max». После экспорта общих ресурсов в удаленное хранилище и их настройки. в Менеджере управления они будут автоматически импортированы на хосты с ПО «zVirt Max».

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

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

Установите пакет утилит NFS.
```
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.9.4.2. Добавление хранилища NFS

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

Если требуется домен ISO или домен экспорта, используйте эту процедуру, но выберите ISO или Экспорт (Export) в списке Функция домена (Domain Function).

Процедура

На Портале администрирования нажмите Хранилище (Storage) → Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Примите значения по умолчанию для списков Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type), Формат (Format) и Хост (Host).
Введите Путь экспорта (Export Path), который должен использоваться для домена хранения. Путь экспорта должен иметь следующий формат: 123.123.0.10:/data (для IPv4), [2001:0:0:0:0:0:0:5db1]:/data (для IPv6), или domain.example.com:/data.
При желании можно настроить расширенные параметры:
- Нажмите Расширенные параметры (Advanced Parameters).
- Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (%) (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
- Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (GB) места (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
- Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
Нажмите OK.

Новый домен данных NFS будет иметь статус Заблокирован (Locked) до тех пор, пока диск не будет подготовлен. Затем домен данных автоматически подключается к центру данных.

2.9.4.3. Увеличение объема хранилища NFS

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения NFS. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center) и нажмите Обслуживание (Maintenance), чтобы перевести домен хранения в режим обслуживания. Это размонтирует существующий общий ресурс и позволит изменить размер домена хранения.
Измените размер хранилища на сервере NFS.
В подробном представлении откройте вкладку Центр данных (Data Center) и нажмите Активировать (Activate), чтобы смонтировать домен хранения.

2.9.5. Подготовка и добавление локального хранилища

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

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

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

2.9.5.1. Подготовка локального хранилища

В ПО «zVirt Max» локальное хранилище всегда должно определяться в файловой системе, отличной от / (root). Используйте отдельный логический том или диск, чтобы предотвратить возможную потерю данных во время обновления.

Процедура

Создайте на хосте каталог, который будет использоваться для локального хранилища:
```
mkdir -p /data/images
```
Убедитесь, что каталог имеет разрешения на чтение/запись для пользователя vdsm (UID 36) и группы kvm (GID 36):
```
chown 36:36 /data /data/images
chmod 0755 /data /data/images
```

2.9.5.2. Добавление локального домена хранения

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

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK. Статус хоста меняется на Обслуживание (Maintenance).
Нажмите Управление (Management) → Настроить локальное хранилище (Configure Local Storage).
Нажмите кнопки Изменить (Edit) рядом с полями Центр данных (Data Center), Кластер (Cluster) и Хранилище (Storage), чтобы настроить локальный домен хранения и дать ему имя.
Введите путь к локальному хранилищу в текстовое поле.
Если применимо, откройте вкладку Оптимизация (Optimization), чтобы настроить политику оптимизации памяти для нового кластера локального хранилища.
Нажмите OK.

Менеджер управления настроит локальный центр данных с локальным кластером и локальным доменом хранения. Он также поменяет статус хоста на Включен (Up).

Проверка (Verification)

Нажмите Хранилище (Storage) → Домены (Domains).
Найдите локальный домен хранения, который только что добавили.

Домен должен иметь статус Активный (Active) (), а значение в столбце Тип хранилища (Storage Type) должно быть Локальное на хосте (Local on Host).

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

2.9.6. Подготовка и добавление хранилища на базе POSIX-совместимой файловой системы

2.9.6.1. Подготовка хранилища на базе POSIX-совместимой файловой системы

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

Любая POSIX-совместимая файловая система, используемая в ПО «zVirt Max» в качестве домена хранения, должна быть кластерной файловой системой (такой как Global File System 2 (GFS2)), поддерживать динамически расширяемые файлы и прямой ввод/вывод.

Так, например, Общая файловая система Интернета (Common Internet File System, CIFS) не поддерживает прямой ввод/вывод, что делает ее несовместимой с ПО «zVirt Max» 3.0.

Не монтируйте хранилище NFS путем создания домена хранения на базе POSIX-совместимой файловой системы. Вместо этого всегда создавайте домен хранения NFS.

2.9.6.2. Добавление хранилища на базе POSIX-совместимой файловой системы

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Выберите Центр данных (Data Center), который нужно ассоциировать с доменом хранения. Выбранный центр данных должен иметь тип POSIX (POSIX-совместимая файловая система (POSIX compliant FS)). Либо выберите (нет (none)).
Выберите Данные (Data) в выпадающем списке Функция домена (Domain Function) и POSIX-совместимая файловая система (POSIX compliant FS) в выпадающем списке Тип хранилища (Storage Type).

Если применимо, выберите Формат (Format) в выпадающем меню.
Выберите хост в выпадающем списке Хост (Host).
Введите Путь (Path) к файловой системе POSIX, как в обычной команде mount.
Введите Тип VFS (VFS Type), как в обычной команде mount, используя аргумент -t. Список действительных типов VFS см. в man mount.
Введите дополнительные Параметры монтирования (Mount Options), как в обычной команде mount, используя аргумент -o. Параметры монтирования следует указывать в виде списка через запятую. Список действительных параметров монтирования см. в man mount.
При желании можно настроить расширенные параметры.
- Нажмите Расширенные параметры (Advanced Parameters).
- Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (%) (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
- Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (GB) (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
- Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
Нажмите OK.

2.9.7. Подготовка и добавление блочного хранилища

2.9.7.1. Подготовка хранилища iSCSI

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

Если вы используете блочное хранилище и собираетесь развернуть виртуальные машины на неформатированных (raw) устройствах или подключенных напрямую LUN и управлять ими с помощью Менеджера логических томов (LVM), то создайте фильтр, чтобы скрыть гостевые логические тома. Это предотвратит активацию гостевых логических томов при загрузке хоста, что в противном случае могло бы привести к устареванию логических томов и повреждению данных. Используйте команду vdsm-tool config-lvm-filter, чтобы создать фильтры для LVM.

ПО «zVirt Max» в настоящее время не поддерживает блочное хранилище с размером блока 4 кБ. Нужно настраивать блочное хранилище со стандартным размером блока – 512 байт.

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

Чтобы этого не произошло, добавьте в корневую файловую систему SAN файл конфигурации с несколькими путями для загрузочного LUN, чтобы убедиться, что он будет поставлен в очередь, как только подключение появится:

cat /etc/multipath/conf.d/host.conf
multipaths {
    multipath {
        wwid _boot_LUN_wwid_
        no_path_retry queue
    }
}

2.9.7.2. Добавление хранилища iSCSI

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

Процедура

Нажмите Хранилище (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, которые не используются средой. Параметры Обнаружение целей (Discover Targets) можно использовать для добавления LUN на несколько таргетов или нескольких путей к одному LUN.
  
  LUN, используемые вне среды, также отображаются.

Если для обнаружения iSCSI-таргетов используется метод REST API discoveriscsi, то можно использовать FQDN или IP-адрес, но нужно использовать подробные сведения iSCSI, взятые из результатов обнаружения таргетов, чтобы авторизоваться в таргетах, используя метод REST API iscsilogin.

В поле Адрес (Address) укажите FQDN или IP-адрес iSCSI-хоста.
В поле Порт (Port) укажите порт для соединения с хостом в процессе поиска таргетов. Значение по умолчанию = 3260.
Если для защиты хранилища используется CHAP, установите флажок
Аутентификация пользователя (User Authentication). Введите *Имя пользователя CHAP (CHAP user name) и Пароль CHAP (CHAP password).
Нажмите Обнаружить (Discover).

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

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

Когда для авторизации используется метод REST API iscsilogin, используйте подробные сведения iSCSI, взятые из результатов обнаружения таргетов, в методе discoveriscsi.

Нажмите + рядом с нужным таргетом. Развернется соответствующая запись с отображением всех неиспользуемых LUN, подключенных к таргету.
Поставьте флажок для каждого LUN, который используете для создания домена хранения.
При желании можно настроить расширенные параметры:
- Нажмите Расширенные параметры (Advanced Parameters).
- Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (%) (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
- Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (GB) (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
- Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку места после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
- Установите флажок Сброс после удаления (Discard After Delete), чтобы включить освобождение пространства после удаления. Этот параметр можно изменить после создания домена. Этот параметр доступен только на блочных доменах хранения.
Нажмите OK.

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

Чтобы перенести текущую сеть хранения на bond-интерфейс iSCSI, см. раздел Перенос логической сети на bond-интерфейс iSCSI.

2.9.7.3. Настройка доступа iSCSI по нескольким путям

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

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

В целях резервирования можно создавать bond-интерфейс iSCSI с несколькими таргетами и логическими сетями.

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

Один или несколько iSCSI-таргетов
Одна или несколько логических сетей, соответствующих следующим требованиям:
- Не определена как Обязательная (Required) или Сеть ВМ (VM Network).
- Назначена интерфейсу хоста.
- Назначен статический IP-адрес в той же сети VLAN и подсети, что и другим логическим сетям в bond-интерфейсе iSCSI.

Процедура

Нажмите Ресурсы (Compute) → Центры данных (Data Centers).
Нажмите на имя центра данных. Откроется подробное представление.
Выберите вкладку Многоканальный iSCSI, нажмите Добавить (Add).
В окне Добавить bond iSCSI (Add iSCSI Bond), введите Имя (Name) и Описание (Description).
Выберите логическую сеть из раздела Логические сети (Logical Networks) и домен хранения из раздела Цели iSCSI (Storage Targets). Все выбранные пути должны идти к одному и тому же таргету.
Нажмите OK.

Хосты центра данных соединены с iSCSI-таргетами через логические сети и bond-интерфейс iSCSI.

2.9.7.4. Миграция логической сети в bond-интерфейс iSCSI

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

Процедура

Измените текущую логическую сеть так, чтобы она не была Обязательной (Required):
- Нажмите Ресурсы (Compute) → Кластеры (Clusters).
- Нажмите на имя кластера. Откроется подробное представление.
- Во вкладке Логические сети (Logical Networks) выберите текущую логическую сеть (net-1) и нажмите Управление сетями (Manage Networks).
- Уберите флажок Сделать обязательной (Require) и нажмите OK.
Создайте новую логическую сеть, которая не обозначена как Обязательная (Required) или Сеть ВМ (VM network):
- Нажмите Добавить сеть (Add Network). Откроется окно Новая логическая сеть (New Logical Network).
- Во вкладке Общие (General) введите Имя (Name) (net-2) и уберите флажок Сеть ВМ (VM network).
- Во вкладке Кластер (Cluster) уберите флажок Сделать обязательной (Require) и нажмите OK.
Удалите текущий сетевой bond-интерфейс и переназначьте логические сети:
- Нажмите Ресурсы (Compute) → Хосты (Hosts).
- Нажмите на имя хоста. Откроется подробное представление.
- Во вкладке Сетевые интерфейсы (Network Interfaces) нажмите Настройка сетей хоста (Setup Host Networks).
- Перетащите net-1 вправо, чтобы отменить назначение.
- Перетащите текущий bond-интерфейс вправо, чтобы удалить его.
- Перетащите net-1 и net-2 влево, чтобы назначить их физическим интерфейсам.
- Нажмите на значок карандаша у net-2. Откроется окно Изменить сеть (Edit Network).
- Во вкладке IPV4 выберите Статичная (Static).
- Введите IP-адрес (IP) и Сетевую маску /префикс маршрутизации (Netmask/Routing Prefix) подсети и нажмите OK.
Создайте bond-интерфейс iSCSI:
- Нажмите Ресурсы (Compute) → Центры данных (Data Centers).
- Нажмите на имя центра данных. Откроется подробное представление.
- Выберите вкладку Многоканальный iSCSI, нажмите Добавить (Add).
- В окне Добавить bond iSCSI (Add iSCSI Bond) введите Имя (Name), выберите сети net-1 и net-2 и нажмите OK.

В центре данных имеется bond-интерфейс iSCSI, содержащий старые и новые логические сети.

2.9.7.5. Подготовка хранилища FCP

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

Системные администраторы ПО «zVirt Max» должны иметь практические знания о работе 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.9.7.6. Добавление хранилища FCP

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите Новый домен (New Domain).
Задайте Имя (Name) для домена хранения.
Выберите из раскрывающегося списка Центр данных (Data Center) FCP. Если подходящего центра данных FCP пока нет, выберите (none).
Из выпадающих списков выберите Функция домена (Domain Function) и Тип хранилища (Storage Type). Типы доменов хранения, не совместимые с выбранным центром данных, недоступны.

Выберите активный хост в поле Хост (Host). Если это не первый домен данных в центре данных, нужно выбрать хост SPM в центре данных.

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

Если выбран тип хранилища Fibre Channel, то в окне Новый домен (New Domain) будут автоматически отображаться известные таргеты с неиспользуемыми LUN. Поставьте флажок LUN ID, чтобы выбрать все доступные LUN.
При желании можно настроить расширенные параметры.
- Нажмите Расширенные параметры (Advanced Parameters).
- Введите процентное значение в поле Порог предупреждения о малом объеме свободного места в домене (%) (Warning Low Space Indicator). Если свободное пространство, доступное в домене хранения, ниже этого процентного значения, пользователю показываются (и вносятся в журнал) предупреждающие сообщения.
- Введите значение в ГБ в поле Порог блокировки при критическом значении свободного места в домене (GB) (Critical Space Action Blocker). Если свободное пространство, доступное в домене хранения, ниже этого значения, пользователю показываются (и вносятся в журнал) сообщения об ошибках, а любое новое действие, которое потребляет пространство, даже временно, будет заблокировано.
- Установите флажок Очистить после удаления (Wipe After Delete), чтобы включить очистку после удаления. Этот параметр можно изменить после создания домена, но это не изменит свойства "очистить после удаления" уже существующих дисков.
- Установите флажок Сброс после удаления (Discard After Delete), чтобы включить освобождение пространства после удаления. Этот параметр можно изменить после создания домена. Этот параметр доступен только на блочных доменах хранения.
Нажмите OK.

Новый домен данных FCP останется со статусом Заблокирован (Locked) во время подготовки к использованию. Затем он будет автоматически подключен к центру данных.

2.9.7.7. Увеличение объема хранилища iSCSI или FCP

Увеличить размер хранилища iSCSI или FCP можно несколькими способами:

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

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

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

У домена хранения должен быть статус Включен (UP).
LUN должен быть доступен всем хостам со статусом Включен (UP), иначе операция не удастся, и LUN не будет добавлен в домен. Однако это не затронет сами хосты. Если вновь добавленный хост или хост, выходящий из режима обслуживания, или хост в состоянии Неработоспособен (Non Operational) не может получить доступ к LUN, то состояние хоста будет Неработоспособен (Non Operational).

Увеличение объема существующего домена хранения iSCSI или FCP

Нажмите Хранилище (Storage) → Домены (Domains) и выберете домен iSCSI или FCP.
Нажмите Управление доменом (Manage Domain).
Нажмите Таргеты (Targets) → LUNs и нажмите кнопку Обнаружение целей (Discover Targets), чтобы развернуть представление.
Введите информацию о соединении сервера хранения и нажмите Обнаружить (Discover), чтобы начать подключение.
Нажмите LUNs → Таргеты (Targets) и установите флажок вновь доступного LUN.
Нажмите OK, чтобы добавить LUN в выбранный домен хранения.

Это увеличит домен хранения на размер добавленного LUN.

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

Обновление размера LUN

Нажмите Хранилище (Storage) → Домены (Domains) и выберете домен iSCSI или FCP.
Нажмите Управление доменом (Manage Domain).
Нажмите LUNs → Таргеты (Targets).
В столбце Дополнительный размер (Additional Size) нажмите кнопку LUN Добавить (Add Additional_Storage_Size) для обновления.
Нажмите OK для обновления LUN, чтобы задать новый размер хранилища.

2.9.7.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.9.7.9. Удаление устаревших LUN

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

ПО «zVirt Max» не управляет серверами 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.9.7.10. Создание фильтра LVM

Фильтр LVM может быть задан в /etc/lvm/lvm.conf, чтобы принимать или отклонять устройства из списка томов на основе запроса регулярного выражения.

Например, чтобы проигнорировать /dev/cdrom, можно использовать filter=["r|^/dev/cdrom$|"] или добавить следующий параметр в команду lvm: lvm: lvs --config 'devices{filter=["r|cdrom|"]}'.

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

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

Это решение предназначено для конфигурирования фильтра 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.9.8. Импортирование существующих доменов хранения

2.9.8.1. Общие сведения об импортировании существующих доменов хранения

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

Ниже рассмотрено импортирование каждого типа домена хранения:

Данные (Data)

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

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

ISO

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

Экспорт (Export)

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

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

2.9.8.2. Импортирование доменов хранения

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите Импортировать домен (Import Domain).
Выберите Центр данных (Data Center), в который вы хотите импортировать домен хранения.
Введите Имя (Name) для домена хранения.
В выпадающих списках выберите Функция домена (Domain Function) и Тип хранилища (Storage Type).

Выберите хост в выпадающем списке Хост (Host).

Введите сведения о домене хранения.

Поля для ввода сведений о домене хранения меняются в зависимости от значений, выбранных в списках Функция домена (Domain Function) и Тип хранилища (Storage Type). Это такие же поля, как и при добавлении нового домена хранения.

Установите флажок Активировать домен в центре данных (Activate Domain in Data Center), чтобы активировать домен хранения после его подключения к выбранному центру данных.
Нажмите OK.

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

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

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

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

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

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

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

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

Процедура

Выключите все виртуальные машины, работающие в необходимом домене хранения.
Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).
Нажмите Обслуживание (Maintenance), затем OK.
Нажмите Отсоединить (Detach), затем OK.
Нажмите Подключить (Attach).
Выберите центр данных, являющийся приемником, и нажмите OK.

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

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

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

Процедура

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

Установите флажок Активировать домен в центре данных (Activate Domain in Data Center), чтобы автоматически активировать домен хранения после подключения.
Нажмите OK.

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

2.9.8.5. Импортирование шаблонов из импортированных доменов хранения данных

Импортируйте шаблон из домена хранения данных, импортированного в ПО «zVirt Max». Процедура предполагает, что импортированный домен хранения данных подключен к центру данных и активирован.

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя импортированного домена хранения. Откроется подробное представление.
Откройте вкладку Импортировать шаблон (Template Import).
Выберите один или несколько шаблонов для импорта.
Нажмите Импортировать (Import).
Для каждого шаблона в окне Импортировать шаблон(ы) (Import Templates(s)) убедитесь, что в списке Кластер (Cluster) выбран правильный кластер.
Сопоставьте внешние vNIC-профили виртуальных машин с профилями в целевом кластере (кластерах):
- Нажмите Сопоставление vNic-профилей (vNic Profiles Mapping).
- Выберите vNIC-профиль в выпадающем списке Целевой vNic-профиль (Target vNic Profile).
- Если в окне Импортировать шаблоны (Import Templates) выбрано несколько целевых кластеров, то выберите каждый целевой кластер в выпадающем списке Целевой кластер (Target Cluster) и убедитесь в корректности сопоставления.
- Нажмите OK.
Нажмите OK.

Импортированные шаблоны больше не отображаются в списке на вкладке Импортировать шаблон (Template Import).

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

2.9.9.1. Выгрузка образов в домен хранения данных

Выгружать образы виртуальных дисков и образы ISO в домен хранения данных можно на Портале администрирования или с помощью 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 и включите все настройки доверия.
Браузер с поддержкой HTML 5.

Процедура

Нажмите Хранилище (Storage) → Диски (Disks).
Выберите Старт (Start) в меню Загрузить (Upload).
Нажмите Начать (Choose File) и выберите образ для выгрузки.
Заполните поля Параметры диска (Disk Options). Описания соответствующих полей см. в Разделе 2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

Индикатор выполнения отображает статус выгрузки. Выгрузку можно приостановить, отменить или возобновить из меню Загрузить (Upload).

Если во время выгрузки время ожидания истечет и будет выдано сообщение Причина: истекло время ожидания из-за неактивности соединения (Reason: timeout due to transfer inactivity), то увеличьте значение времени ожидания и перезапустите службу ovirt-engine:

engine-config -s TransferImageClientInactivityTimeoutInSeconds=6000
systemctl restart ovirt-engine

2.9.9.2. Выгрузка образов в домен ISO

Хотя домен ISO считается устаревшим, эта информация предоставляется на случай, если вдруг его необходимо использовать.

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

Процедура

Авторизуйтесь как root-пользователь на хосте, который относится к центру данных, где расположен ваш домен хранения ISO.

Отобразите дерево каталогов /rhv/data-center:

tree /rhev/data-center
.
|-- 80dfacc7-52dd-4d75-ab82-4f9b8423dc8b
|   |-- 76d1ecba-b61d-45a4-8eb5-89ab710a6275 -> /rhev/data-center/mnt/10.10.10.10:_rhevnfssd/76d1ecba-b61d-45a4-8eb5-89ab710a6275
|   |-- b835cd1c-111c-468d-ba70-fec5346af227 -> /rhev/data-center/mnt/10.10.10.10:_rhevisosd/b835cd1c-111c-468d-ba70-fec5346af227
|   |-- mastersd -> 76d1ecba-b61d-45a4-8eb5-89ab710a6275
|   |-- tasks -> mastersd/master/tasks
|   `-- vms -> mastersd/master/vms
|-- hsm-tasks
`-- mnt
    |-- 10.10.10.10:_rhevisosd
    |   |-- b835cd1c-111c-468d-ba70-fec5346af227
    |   |   |-- dom_md
    |   |   |   |-- ids
    |   |   |   |-- inbox
    |   |   |   |-- leases
    |   |   |   |-- metadata
    |   |   |   `-- outbox
    |   |   `-- images
    |   |       `-- 11111111-1111-1111-1111-111111111111
    |   `-- lost+found [error opening dir]

(….)

Аккуратно скопируйте образ из исходного местоположения по полному пути 11111111-1111-1111-1111-111111111111:
```
scp root@isosource:/isos/example.iso/rhev/data-center/mnt/10.96.4.50:++_++rhevisosd b835cd1c-111c-468d-ba70-fec5346af227/images/11111111-1111-1111-1111-111111111111
```
Разрешения для только что скопированного файла образа ISO должны быть 36:36 (vdsm:kvm). Если это не так, измените принадлежность файла ISO пользователю и группе на 36:36 (пользователь и группа vdsm):
```
scp root@isosource:/isos/example.iso /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.9.9.3. Перевод доменов хранения в режим обслуживания

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

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

Расширять домены iSCSI путем добавления LUN можно, только когда домен активен.

Процедура

Выключите все виртуальные машины, работающие в домене хранения.
Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).

Нажмите Обслуживание (Maintenance).

Флажок Игнорировать ошибку обновления OVF (Ignore OVF update failure) позволяет домену хранения переходить в режим обслуживания даже в случае ошибки обновления OVF.

Нажмите OK.

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

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

2.9.9.4. Изменение доменов хранения

Параметры домена хранения можно менять через Портал администрирования. В зависимости от состояния домена хранения (активен или неактивен), для изменения доступны разные поля. Такие поля как Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type) и Формат (Format) изменить невозможно.

Активен (Active): Когда домен хранения находится в активном состоянии, поля Имя (Name), Описание (Description), Комментарий (Comment), Порог предупреждения о малом объеме свободного места в домене (%) (%) (Warning Low Space Indicator (%)), Порог блокировки при критическом значении свободного места в домене (GB) (ГБ) (Critical Space Action Blocker (GB)), Очистить после удаления (Wipe After Delete) и Сброс после удаления (Discard After Delete) можно изменять. Поле Имя (Name) можно изменять только тогда, когда домен хранения активен. Все остальные поля можно изменять и тогда, когда домен хранения неактивен.
Неактивен (Inactive): Когда домен хранения находится в режиме обслуживания или не подключен, т.е. в неактивном состоянии, можно изменять все поля, кроме Имя (Name), Центр данных (Data Center), Функция домена (Domain Function), Тип хранилища (Storage Type) и Формат (Format). Домен хранения должен быть неактивным, чтобы можно было изменять подключения к хранилищу, параметры монтирования и другие расширенные параметры. Это поддерживается только для типов хранилища NFS, POSIX и локального.

Подключения к хранилищу iSCSI невозможно изменять на Портале администрирования, но можно – через REST API.

Изменение активного домена хранения

Нажмите Хранилище (Storage) → Домены (Domains) и выберите домен хранения.
Нажмите Управление доменом (Manage Domain).
Измените редактируемые поля нужным образом.
Нажмите OK.

Изменение неактивного домена хранения

Нажмите Хранилище (Storage) → Домены (Domains).
Если домен хранения активен, переведите его в режим обслуживания:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Обслуживание (Maintenance).
- Нажмите OK.
Нажмите Управление доменом (Manage Domain).
Измените путь к хранилищу и прочие сведения нужным образом. В сведениях о новом подключении должен быть указан тот же тип хранилища, что и для исходного подключения.
Нажмите OK.
Активируйте домен хранения:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Активировать (Activate).

2.9.9.5. Обновление OVF

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Выберите домен хранения и нажмите Дополнительные действия (More Actions), затем нажмите Обновить OVF (Update OVFs).

OVF обновляются, и в поле События (Events) отображается сообщение.

2.9.9.6. Активация доменов хранения из режима обслуживания

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

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя неактивного домена хранения. Откроется подробное представление.
Откройте вкладку Центры данных (Data Centers).
Нажмите Активировать (Activate).

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

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

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Выберите вкладку Центр данных (Data Center).
Нажмите Обслуживание (Maintenance).
Нажмите OK, чтобы перейти в режим обслуживания.
Нажмите Отсоединить (Detach).
Нажмите OK, чтобы отключить домен хранения.

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

2.9.9.8. Подключение домена хранения к центру данных

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Откройте вкладку Центр данных (Data Center).
Нажмите Подключить (Attach).
Выберите подходящий центр данных.
Нажмите OK.

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

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

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

Процедура

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

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

2.9.9.10. Уничтожение домена хранения

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Выберите домен хранения и нажмите Дополнительные действия (More Actions) и затем Уничтожить (Destroy).
Установите флажок в поле Подтвердить операцию (Approve operation).
Нажмите OK.

2.9.9.11. Создание профиля диска

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

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

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения данных. Откроется подробное представление.
Откройте вкладку Профили диска (Disk Profiles).
Нажмите Новый (New).
Введите Имя (Name) и Описание (Description) для профиля диска.
Выберите политику QoS из списка QoS для применения к профилю диска.
Нажмите OK.

2.9.9.12. Удаление профиля диска

Удалите существующий профиль диска из ПО «zVirt Max».

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения данных. Откроется подробное представление.
Откройте вкладку Профили диска (Disk Profiles).
Выберите профиль диска, который нужно удалить.
Нажмите Удалить (Remove).
Нажмите OK.

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

2.9.9.13. Просмотр статуса состояния домена хранения

У домена хранения есть внешний статус состояния в дополнение к обычному Статусу (Status). Внешний статус состояния сообщается внешними системами и подключаемыми модулями или задается администратором и отображается слева от Имени (Name) домена хранения в виде одного из следующих значков:

OK: Без значка
Информация (Info):
Предупреждение (Warning):
Ошибка (Error):
Отказ (Failure):

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

Статус состояния домена хранения можно также посмотреть с помощью REST API. Запрос GET о домене хранения будет включать в себя элемент external_status, содержащий статус состояния.

2.9.9.14. Установка флажка "Сброс после удаления (Discard After Delete)" для домена хранения

Когда установлен флажок Сброс после удаления (Discard After Delete), на удаляемом логическом томе вызывается команда blkdiscard, и используемому хранилищу сообщается, что блоки свободны. Массив хранения может использовать освободившееся место и распределять его по запросу. Опция Сброс после удаления (Discard After Delete) работает только в блочном хранилище. Флажок не доступен в Менеджере управления для файлового хранилища такого, как NFS.

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

Опция Сброс после удаления (Discard After Delete) доступна только в доменах блочного хранилища таких, как iSCSI или Fibre Channel.
Используемое хранилище должно поддерживать опцию Освободить (Discard).

Опция Сброс после удаления (Discard After Delete) может быть включена при создании домена блочного хранилища или при его изменении. См. Подготовка и добавление блочного хранилища и Изменение доменов хранения.

2.9.9.15. Включение поддержки 4-килобайтных блоков в средах с более 250 хостами

По умолчанию локальные домены хранения поддерживают блоки в 4 кБ в ПО «zVirt Max», где располагается до 250 хостов. Блоки размером 4 кБ могут обеспечить лучшую производительность, особенно на больших файлах, а также необходимы при использовании средств, требующих совместимости с блоками в 4 кБ, например VDO.

Область блокировки, распределяемая Sanlock, достигает 1 МБ, когда максимальное количество хостов равно, как по умолчанию, 250. С увеличением максимального количества хостов при использовании хранилища с блоками в 4 кБ растет и область блокировки. Например, если используется 2 000 хостов, то область блокировки может достигать 8 МБ.

Можно включить поддержку блоков в 4 кБ в средах с более 250 хостами, установив параметр конфигурации engine MaxNumberOfHostsInStoragePool.

Процедура

На машине c Менеджером управления включите необходимое максимальное количество хостов:
```
engine-config -s MaxNumberOfHostsInStoragePool=_NUMBER_OF_HOSTS_
```
Перезапустите сервер JBoss Application Server:
```
service jboss-as restart
```
Например, если в кластере 300 хостов, введите:
```
engine-config -s MaxNumberOfHostsInStoragePool=300
service jboss-as restart
```

Проверка

Просмотр значения параметра MaxNumberOfHostsInStoragePool в Менеджере управления:

engine-config --get=MaxNumberOfHostsInStoragePool
 MaxNumberOfHostsInStoragePool: 250 version: general

2.9.9.16. Мониторинг доступного места в домене хранения

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

Используя Виртуальный оптимизатор данных (VDO) и поддержку тонких пулов, можно увидеть больше доступного места, чем есть физически. Такое поведение ожидаемо для VDO, но Менеджер управления не может предсказать, какое количество данных можно фактически записать. Параметр Предупреждение о недостатке подтвержденного места (Warning Low Confirmed Space Indicator) сообщает, когда на домене физически заканчивается место и показывает сколько подтвержденного места осталось. Подтвержденное место — это пространство, фактически доступное для записи данных.

Процедура

На Портале администрирования нажмите Хранилище (Storage) → Домен хранения (Storage Domain) и нажмите на имя домена хранения.
Нажмите Управление доменом (Manage Domain). Откроется диалоговое окно Управление доменами (Manage Domain).
Разверните Расширенные параметры (Advanced Parameters).
Для параметра Порог предупреждения о малом объеме свободного места в домене (%) (%) (Warning Low Space Indicator (%)) задайте процентное значение. Когда доступное место в домене хранения достигает этого значения, Менеджер управления предупреждает, что место в домене заканчивается.
Для параметра Порог блокировки при критическом значении свободного места в домене (GB) (ГБ) (Critical Space Action Blocker (GB)) задайте значение в гигабайтах. Когда доступное место в домене хранения достигает этого значения, Менеджер управления производит выключение.
Для параметра Предупреждение о недостатке подтвержденного места (%) (Warning Low Confirmed Space Indicator (%)) задайте процентное значение. Когда доступное место в домене хранения достигает этого значения, Менеджер управления предупреждает, что место, фактически доступное для записи данных, заканчивается.

2.10. Пулы

2.10.1. Введение в пулы виртуальных машин

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

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

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

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

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

2.10.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 на Портале администрирования (см. раздел 2.7.2. Создание пула виртуальных машин). Дополнительные сведения см. в разделе Использование файла Sysprep для автоматизации настройки виртуальных машин в Руководстве пользователя.

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools).
Нажмите Новый (New).
Выберите Кластер (Cluster) в выпадающем списке.
Выберите Шаблон (Template) и версию в выпадающем меню. Шаблон содержит стандартные настройки для всех виртуальных машин в пуле.
Выберите Операционную систему (Operating System) в выпадающем списке.

Используйте Профиль нагрузки (Optimized for), чтобы оптимизировать виртуальные машины для Рабочей станции (Desktop) или Сервера Server).

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

Введите Имя (Name) и при желании Описание (Description) и Комментарий (Comment).

Имя (Name) пула применяется к каждой виртуальной машине в пуле с числовым суффиксом. Можно настроить нумерацию виртуальных машин с помощью знака ? в качестве заполнителя.
Пример 1. Примеры имен пулов и нумерации виртуальных машин
- Пул: MyPool
  
  Виртуальные машины: MyPool-1, MyPool-2, … MyPool-10
- Пул: MyPool-???
  
  Виртуальные машины: MyPool-001, MyPool-002, … MyPool-010
Укажите Количество ВМ (Number of VMs) в пуле.
Укажите количество виртуальных машин для предварительного запуска в поле Предзапускаемые ВМ (Prestarted).
Укажите Максимальное количество ВМ на пользователя (Maximum number of VMs per user), которое одному пользователю разрешено запускать во время cеанса. Минимальное значение: 1.
Установите флажок Защита от удаления (Delete Protection), чтобы включить защиту от удаления.
Если вы создаете пул виртуальных машин не на базе Windows или используете стандартный файл sysprep, то пропустите этот шаг. Если вы создаете пользовательский файл sysprep для пула виртуальных машин Windows:
- Нажмите кнопку Показать расширенные настройки (Show Advanced Options).
- Перейдите на вкладку Запуск инициализации (Initial Run) и установите флажок Использовать Cloud-Init/Sysprep (Use 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>

Пример 2. Пример ключа продукта 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>
```

Пример 3. Пример учетных данных домена

<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), чтобы виртуальные машины запускались в режиме сохранения состояния. Это позволяет сохранять на виртуальной машине изменения, внесенные предыдущим пользователем.
Нажмите OK.
1. Дополнительно. Переопределите 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-диск с гостевыми инструментами 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.10.3. Описание настроек и средств управления в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

2.10.3.1. Описание общих настроек в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В таблице представлена информация, которая должна быть указана на вкладке Общие (General) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Создать виртуальную машину (New Virtual Machine).

Таблица 61. Общие настройки (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 для развертывания в качестве шаблона.

Описание настроек типа в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице представлена информация, которая должна быть указана на вкладке Тип (Type) окон Новый пул (New Pool) и Изменить пул (Edit Pool).

Таблица 62. Настройки на вкладке Тип (Type)
Имя поля	Описание
Тип пула (Pool Type)	В этом выпадающем меню можно указать тип пула виртуальных машин. Доступны следующие опции: Автоматически (Automatic): После того как пользователь прекратил использовать виртуальную машину, взятую из пула виртуальных машин, она автоматически возвращается в пул. Руководстве пользователя о (Manual): После того как пользователь прекратил использовать виртуальную машину, взятую из пула виртуальных машин, администратор вручную возвращает ее в пул.
Пул состояний (Stateful Pool)	Здесь можно указать, что состояние виртуальной машины в пуле надо сохранять при ее передаче другому пользователю, т.е. изменения, внесенные предыдущим пользователем, сохранятся на виртуальной машине.

2.10.3.2. Описание настроек консоли в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В таблице описана информация, которая должна быть указана на вкладке Консоль (Console) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Создать виртуальную машину (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine).

Таблица 63. Настройки на вкладке Консоль (Console)
Имя поля	Описание
Перезаписать адрес SPICE прокси (Override SPICE proxy)	Поставьте флажок в это поле, чтобы разрешить переопределение SPICE-прокси, заданного в глобальной конфигурации. Эта функция полезна, когда пользователь (например, подключающийся через Пользовательский портал) располагается вне сети, в которой находятся хосты.
Переопределенный адрес SPICE-прокси (Overridden SPICE proxy address)	Прокси-сервер, посредством которого клиент SPICE соединяется с виртуальными машинами. Этот прокси-сервер переопределяет как глобальный SPICE-прокси, заданный для ПО «zVirt Max», так и SPICE-прокси, заданный для кластера, к которому относится пул виртуальных машин, если таковой имеется. Адрес должен быть задан в следующем формате: protocol://host:_port_

2.10.3.3. Описание настроек хоста пула виртуальных машин

В таблице описаны опции, имеющиеся на вкладке Хост (Host) окон Новый пул (New Pool) и Изменить пул (Edit Pool).

Таблица 64. Пул виртуальных машин: настройки хоста

Имя поля

Доп. элемент

Описание

Начать работу (Start Running On)

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

Любой хост в кластере (Any Host in Cluster) – виртуальная машина может запускаться и работать на любом из доступных хостов кластера.

Заданный(е) хост(ы) (Specific Host(s)) – виртуальная машина будет запускаться на конкретном хосте кластера. Однако Менеджер управления или администратор может перенести виртуальную машину на другой хост кластера в зависимости от настроек миграции и высокой доступности виртуальной машины. Выберите конкретный хост или группу хостов из списка доступных хостов.

Параметры ЦП (CPU options)

Сквозной доступ ЦП хоста (Pass-Through Host CPU)

Если выбрана эта опция, то виртуальные машины могут использовать флаги ЦП хоста. Если выбрана эта опция, то Параметры миграции (Migration Options) установлены в значение Разрешить только ручную миграцию (Allow manual migration only).

Миграция только на хосты с одинаковой частотой 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)

Здесь определяется политика синхронизации состояния памяти при миграции. Если флажок не стоит, то политику определяет хост.

Кластер по умолчанию (Минимальное время простоя) (Cluster default (Minimal downtime)) – переопределения в vdsm.conf все еще применяются. Гостевой хук-механизм выключен. Минимальное время простоя (Minimal downtime): миграция виртуальных машин в типичных ситуациях разрешена. У виртуальных машин не должно быть значительного простоя. Процесс миграции будет прерван, если синхронизация состояния памяти слишком затянулась (зависит от итераций QEMU, максимум 500 миллисекунд). Гостевой хук-механизм включен. * Миграция с пост-копированием (Post-copy migration)*: когда применяется эта политика, она приостанавливает виртуальные ЦП мигрирующей виртуальной машины на хосте-источнике, переносит только минимальное количество страниц памяти, активирует виртуальные ЦП виртуальной машины на хосте-приемнике и переносит оставшиеся страницы памяти, пока виртуальная машина работает на хосте-приемнике.

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

Приостановка процессов при необходимости (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 (NUMA Pinning)

2.10.3.4. Описание настроек выделения ресурсов в окнах "Новый пул (New Pool)" и "Изменить пул (Edit Pool)"

В следующей таблице представлена информация, которая должна быть указана на вкладке Выделение ресурсов (Resource Allocation) окон Новый пул (New Pool) и Изменить пул (Edit Pool), для конкретных пулов виртуальных машин. Все прочие настройки идентичны настройкам в окне Создать виртуальную машину (New Virtual Machine). Дополнительные сведения см. в разделе Описание настроек выделения ресурсов в виртуальной машине в Руководстве пользователя.

Таблица 65. Настройки выделения ресурсов
Имя поля	Доп. элемент	Описание
Выделение диска (Disk Allocation)	Автоматический выбор таргета (Auto select target)	Установите этот флажок, чтобы автоматически выбрать домен хранения, в котором больше всего свободного места. Поля Цель (Target) и Профиль диска (Disk Profile) отключены.
	Формат (Format)	Это поле только для чтения и всегда показывает QCOW2.

2.10.3.5. Изменение пула виртуальных машин

После создания пула виртуальных машин его свойства можно менять. Доступные для изменения свойства пула виртуальных машин идентичны тем, что доступны при создании нового пула виртуальных машин, за исключением того, что свойство Количество ВМ (Number of VMs) заменено на свойство Увеличить количество ВМ в пуле на (Increase number of VMs in pool by).

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

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
Измените свойства пула виртуальных машин.
Нажмите Ok.

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

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

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

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
В поле Предзапущенные ВМ (Prestarted Vms) введите нужное количество виртуальных машин для предварительного запуска.
Откройте вкладку Тип (Type). Убедитесь, что для параметра Тип пула (Pool Type) установлено значение Автоматически (Automatic).
Нажмите OK.

2.10.3.7. Добавление виртуальных машин в пул виртуальных машин

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

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Изменить (Edit).
В поле Увеличить количество ВМ в пуле на (Increase number of VMs in pool by) введите количество дополнительных виртуальных машин.
Нажмите OK.

2.10.3.8. Отключение виртуальных машин от пула виртуальных машин

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

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools).
Нажмите имя пула. Откроется подробное представление.
Откройте вкладку Виртуальные машины (Virtual Machines), чтобы посмотреть список виртуальных машин в пуле.
Убедитесь, что виртуальная машина имеет статус Выключен (Down); отключить работающую виртуальную машину нельзя.
Выберите одну или несколько виртуальных машин и нажмите Отключить (Detach).
Нажмите OK.

Виртуальная машина остается в среде, и ее можно просмотреть и получить к ней доступ, выбрав Ресурсы (Compute) → Виртуальные машины (Virtual Machines). Обратите внимание, что значок меняется, указывая на то, что отключенная виртуальная машина является независимой виртуальной машиной.

2.10.3.9. Удаление пула виртуальных машин

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

Процедура

Нажмите Ресурсы (Compute) → Пулы (Pools) и выберите пул виртуальных машин.
Нажмите Удалить (Remove).
Нажмите OK.

2.11. Виртуальные диски

2.11.1. Общие сведения о хранилище виртуальной машины

ПО «zVirt Max» поддерживает три типа хранилищ: NFS, iSCSI и FCP.

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

По умолчанию в NFS, локальном или POSIX-совместимом центре данных SPM создает виртуальный диск, используя формат с динамическим выделением пространства, в виде файла в файловой системе.

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

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

При использовании виртуального диска с динамическим выделением пространства создается логический том размером 1 ГБ. Хост, на котором запущена виртуальная машина, непрерывно ведет мониторинг логического тома. Как только использование приблизится к пороговому значению, хост оповестит SPM, и SPM увеличит размер логического тома на 1 ГБ. Хост отвечает за возобновление работы виртуальной машины после увеличения размера логического тома. Если виртуальная машина перейдет в состояние приостановки работы, то это будет означать, что SPM не смог вовремя увеличить размер диска. Это происходит, когда SPM слишком занят или когда в хранилище недостаточно дискового пространства.

Виртуальный диск формата raw (с предварительно выделенным пространством) обеспечивает намного более быструю запись, чем виртуальный диск формата QCOW2 (с динамическим выделением пространства. Создание виртуального диска с динамическим выделением пространства занимает гораздо меньше времени. Формат с динамическим выделением пространства подходит для виртуальных машин с не интенсивным потоком операций ввода-вывода. Формат с предварительно выделенным пространством рекомендуется для виртуальных машин с большим количеством операций записи при вводе-выводе. Если виртуальная машина способна записывать более 1 ГБ каждые четыре секунды, то по возможности используйте диски с предварительно выделенным пространством.

2.11.2. Общие сведения о виртуальных дисках

ПО «zVirt Max» предусматривает хранилища двух типов: С предварительно выделенным пространством (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) одинаковы. У динамически расширяемых дисков значения этих параметров могут быть разными в зависимости от размера выделенного дискового пространства.

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

Таблица 66. Допустимые комбинации типов и форматов хранилища
Хранилище	Формат	Тип	Примечание
NFS	Raw	С предварительно выделенным пространством	Неформатированный файл, изначальный размер которого равен размеру пространства, заданного для виртуального диска.
NFS	Raw	Динамически расширяемый	Неформатированный файл с изначальным размером, близким к нулю.
NFS	QCOW2	Динамически расширяемый	Файл формата QCOW2 с изначальным размером, близким к нулю. Последующие уровни будут отформатированы в формате QCOW2.
SAN	Raw	С предварительно выделенным пространством	Неформатированное блочное устройство, изначальный размер которого равен размеру пространства, заданного для виртуального диска.
SAN	QCOW2	Динамически расширяемый	Блочное устройство формата QCOW2, изначальный размер которого намного меньше размера, заданного для виртуального диска (сейчас - 1 ГБ) и которому дисковое пространство выделяется по мере необходимости (сейчас - с шагом 1 ГБ).

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

Таблица 67. Возможные состояния виртуальных дисков
Состояние	Описание	Причины перехода в данное состояние
Недопустимый (Illegal)	Диск недоступен для виртуальной машины и требуются действия пользователя для устранения проблемы	Повреждение диска, или ошибка файловой системы, или проблемы с разрешением доступа, или некорректные метаданные диска
Заблокирован (Locked)	Диск используется системой и в данный момент недоступен для виртуальных машин	Диск находится в процессе записи, создания снимка (snapshot), миграции или другой операции обслуживания
OK	Статус диска нормальный, и он доступен для использования виртуальной машиной	Диск успешно создан, отмонтирован и готов к использованию. Нет ошибок и блокировок

2.11.4. Настройки для очистки виртуальных дисков после удаления

Если поставить флажок wipe_after_delete, который на Портале администрирования отображается как Очистить после удаления (Wipe After Delete), то при удалении виртуального диска используемые данные будут заменены нулями. Если для него установлено значение "false" (это значение по умолчанию), то при удалении диска эти блоки будут доступны для повторного использования, но данные не будут стерты. Поэтому эти данные можно будет восстановить, так как блоки не были обнулены.

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

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

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

В процессе настройки значение по умолчанию для флажка wipe_after_delete можно изменить на true (см. раздел 3.5.4. Настройка Менеджера управления на отправку ловушек SNMP) или с помощью инструмента 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

В случае успешной очистки файл журнала будет содержать запись storage_domain_id/volume_id was zeroed and will be deleted. Например:

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.11.4.1. Общие диски в ПО «zVirt Max»

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

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

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

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

Диск можно снабдить меткой "Может быть общим (Shareable)" либо при его создании, либо позже при его изменении.

2.11.5. Диски "только для чтения (Read Only)" в ПО «zVirt Max»

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

Это можно сделать при создании или изменении диска, подключенного к виртуальной машине: откройте вкладку Диски (Disks) в подробном представлении виртуальной машины и установите флажок Только для чтения (Read Only). Таким образом несколько гостевых машин, учитывающих особенности кластера, могут читать один и тот же диск, при этом администратор сохраняет за собой права на запись.

Статус диска "только для чтения" нельзя изменить во время работы виртуальной машины.

Для монтирования журналируемой файловой системы требуется доступ с правами на чтение и запись. Использование параметра Только для чтения (Read Only) не подходит для виртуальных дисков, содержащих файловые системы EXT3, EXT4 или XFS.

2.11.6. Задачи, относящиеся к виртуальному диску

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

Созданием диска Образ (Image) полностью управляет Менеджер управления. Для дисков Прямой LUN требуются уже существующие таргеты, подготовленные извне.

Можно создать виртуальный диск, подключенный к конкретной виртуальной машине. Дополнительные параметры доступны при создании подключенного виртуального диска, как указано в Разделе 2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)".

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

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Нажмите имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks).
Нажмите Новый (New).
Нажатием соответствующей кнопки задайте тип создаваемого виртуального диска: Образ (Image) или Прямой LUN.
Выберите параметры, необходимые для виртуального диска. Параметры меняются в зависимости от выбранного типа диска. Подробное описание каждого параметра для каждого типа диска см. в 2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

Можно также создать плавающий виртуальный диск, не принадлежащий ни одной виртуальной машине. Этот диск можно подключить к одной или к нескольким виртуальным машинам, если его можно сделать общим. При создании виртуального диска недоступны некоторые параметры, указанные в Разделе 2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)".

Создание плавающего виртуального диска

Нажмите Хранилище (Storage) → Диски (Disks).
Нажмите Новый (New).
Нажатием соответствующей кнопки задайте тип создаваемого виртуального диска: Образ (Image) или Прямой LUN.
Выберите параметры, необходимые для виртуального диска. Параметры меняются в зависимости от выбранного типа диска. Подробное описание каждого параметра для каждого типа диска см. в Разделе 2.8.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)".
Нажмите OK.

2.11.6.2. Описание настроек в окне "Новый диск (New Virtual Disk)"

Поскольку окна "Новый диск (New Virtual Disk)" для создания плавающих и подключенных виртуальных дисков очень похожи, их настройки описываются в одном разделе.

Таблица 68. Настройки в окнах "Новый диск (New Virtual Disk)" и "Изменить виртуальный диск (Edit Virtual Disk)": Образ (Image)
Имя поля	Описание
Размер (ГБ) (Size(GB))	Размер нового виртуального диска в ГБ.
Псевдоним (Alias)	Имя виртуального диска (не более 40 знаков).
Описание (Description)	Описание виртуального диска. Это поле является рекомендованным, но не обязательным.
Интерфейс (Interface)	Это поле появляется только при создании подключенного диска. Виртуальный интерфейс, который диск представляет виртуальным машинам. VirtIO обеспечивает более высокую скорость, но для него требуются драйверы. В ОС на базе Red Hat Enterprise Linux 5 и более новых версиях эти драйверы уже есть. В 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, выберите Цели (Targets) → LUNs или LUNs → Цели (Targets). Если выбрать Цели (Targets) → LUNs, то доступные LUN будут отсортированы в соответствии с хостом, на котором они обнаружены, а если выбрать LUNs → Цели (Targets), то будет показан один общий список LUN.

Заполните поля в разделе Обнаружение целей (Discover Targets) и нажмите Обнаружить (Discover), чтобы обнаружить целевой сервер. Затем нажмите кнопку Войти везде (Login All), чтобы просмотреть список доступных LUN на целевом сервере, и нажатием кнопки-переключателя рядом с каждым LUN выберите LUN для добавления.

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

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

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

Таблица 69. Настройки в окнах "Новый диск (New Virtual Disk) и "Изменить виртуальный диск (Edit Virtual Disk)": Прямой LUN
Имя поля	Описание
Псевдоним (Alias)	Имя виртуального диска (не более 40 знаков).
Описание (Description)	Описание виртуального диска. Это поле является рекомендованным, но не обязательным. По умолчанию в это поле вставляются последние 4 знака идентификатора LUN ID. Действие по умолчанию можно настроить, установив для ключа конфигурации PopulateDirectLUNDiskDescriptionWithLUNId соответствующее значение с помощью команды engine-config. Для ключа конфигурации можно установить значение -1, чтобы использовать полный LUN ID, или значение 0, чтобы игнорировать эту функцию. Если задать положительное целое число, то описание будет заполнено соответствующим количеством знаков LUN ID.
Интерфейс (Interface)	Это поле появляется только при создании подключенного диска. Виртуальный интерфейс, который диск представляет виртуальным машинам. VirtIO обеспечивает более высокую скорость, но для него требуются драйверы. В ОС на базе Red Hat Enterprise Linux 5 и более новых версиях эти драйверы уже есть. В 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.11.6.3. Общие сведения о миграции между хранилищами "на лету"

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

Обратите внимание на следующее при выполнении миграции между хранилищами "на лету":

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

2.11.6.4. Перемещение виртуального диска

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

Обратите внимание на следующее при переносе диска:

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

Процедура

Нажмите Хранилище (Storage) → Диски (Disks) и выберите один или несколько виртуальных дисков для переноса.
Нажмите Перенести (Move).
Из списка Цель (Target) выберите домен хранения, в который виртуальный(е) диск(и) будет(ут) перенесены.
Из списка Профиль диска (Disk Profile) выберите профиль для диска(ов), если применимо.
Нажмите OK.

Виртуальные диски перемещаются в целевой домен хранения. Во время перемещения в столбце Статус (Status) высвечивается Заблокирован (Locked), а индикатор выполнения отображает прогресс выполнения переноса.

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

Копирование виртуального диска

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

Процедура

Нажмите Хранилище (Storage) → Диски (Disks) и выберите виртуальный(ые) диск(и).
Нажмите Копировать (Copy) .
При желании задайте новое имя в поле Псевдоним (Alias).
Из списка Цель (Target) выберите домен хранения, в который диск(и) будет(ут) скопирован(ы).
Из списка Профиль диска (Disk Profile) выберите профиль для диска(ов), если применимо.
Нажмите OK.

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

2.11.6.6. Повышение производительности диска

На Портале администрирования на вкладке Выделение ресурсов (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.11.6.7. Выгрузка образов в домен хранения данных

Образы виртуальных дисков и ISO-образы можно выгрузить в домен хранения данных с помощью Портала администрирования. См. Раздел 2.6.9.1. Выгрузка образов в домен хранения данных.

2.11.6.8. Импортирование образа диска из импортированного домена хранения

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

Только диски, совместимые с QEMU, можно импортировать в Менеджер управления.

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя импортированного домена хранения. Откроется подробное представление.
Откройте вкладку Импорт диска (Disk Import).
Выберите один или несколько дисков и нажмите Импортировать (Import).
Выберите подходящий Профиль диска (Disk Profile) для каждого диска.
Нажмите OK.

2.11.6.9. Импортирование незарегистрированного образа диска из импортированного домена хранения

Импортируйте плавающие виртуальные диски из домена хранения. Плавающие диски, созданные вне ПО «zVirt Max», не регистрируются в Менеджере управления. Сканируйте домен хранения, чтобы обнаружить незарегистрированные плавающие диски для импортирования.

Только диски, совместимые с QEMU, можно импортировать в Менеджер управления.

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена хранения. Откроется подробное представление.
Нажмите Дополнительные действия (More Actions), затем нажмите Сканировать диски (Scan Disks), чтобы Менеджер управления мог обнаружить незарегистрированные диски.
Откройте вкладку Импорт диска (Disk Import).
Выберите один или несколько образов дисков и нажмите Импортировать (Import).
Выберите подходящий Профиль диска (Disk Profile) для каждого диска.
Нажмите OK.

2.11.6.10. Импортирование виртуального диска из OpenStack Image Service

Виртуальные диски, управляемые службой OpenStack Image Service, можно импортировать в Менеджер управления, если служба OpenStack Image Service была добавлена в Менеджер управления как внешний провайдер.

Нажмите Хранилище (Storage) → Домены (Domains).
Нажмите на имя домена OpenStack Image Service. Откроется подробное представление.
Откройте вкладку Образы (Images) и выберите образ.
Нажмите Импортировать (Import).
Выберите Центр данных (Data Center), в который будет импортирован образ.
Из выпадающего списка Имя домена (Domain Name) выберите домен хранения, в котором будет храниться образ.
При желании из выпадающего списка Квота (Quota) выберите квоту для применения к образу.
Нажмите OK.

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

2.11.6.11. Экспортирование виртуального диска в OpenStack Image Service

Виртуальные диски можно экспортировать в службу OpenStack Image Service, которая была добавлена в Менеджер управления как внешний провайдер.

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

Нажмите Хранилище (Storage) → Диски (Disks) и выберите диски для экспорта.
Нажмите Дополнительные действия (More Actions) и затем Экспортировать (Export).
Из выпадающего списка Имя домена (Domain Name) выберите службу OpenStack Image Service, куда будут экспортированы диски.
Из выпадающего списка Квота (Quota) выберите квоту для дисков, если применимо.
Нажмите OK.

2.11.6.12. Присвоение пространства виртуального диска

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

2.12.1. Общая информация о внешних провайдерах в ПО «zVirt Max»

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

Сейчас в ПО «zVirt Max» поддерживаются следующие внешние провайдеры:

KubeVirt/Openshift Virtualization

Openshift Virtualization (ранее контейнерная виртуализация или "CNV") позволяет внедрять виртуальные машины (ВМ) в контейнерные рабочие процессы, чтобы можно было разрабатывать, управлять и разворачивать виртуальные машины рядом с контейнерами и бессерверными средами. В Менеджере управления добавление этого провайдера является одним из требований для использования {container-platform-virt}. Для получения дополнительной информации см. Раздел 2.9.2.3. Добавление KubeVirt/Openshift Virtualization в качестве внешнего провайдера.

Служба OpenStack Image Service (Glance) для управления образами

Служба OpenStack Image Service предоставляет каталог образов виртуальных машин. В ПО «zVirt Max» эти образы можно импортировать в Менеджер управления и использовать в качестве плавающих дисков или подключить к виртуальным машинам и преобразовать в шаблоны. После добавления службы OpenStack Image Service в Менеджер управления она отображается как домен хранения, не подключенный ни к одному из центров данных. Виртуальные диски в ПО «zVirt Max» также можно экспортировать в службу OpenStack Image Service как виртуальные диски.

VMware для выделения виртуальных машин

Виртуальные машины, созданные в VMware, можно преобразовать, используя V2V (virt-v2v), и импортировать в ПО «zVirt Max». После добавления провайдера VMware в Менеджер управления можно импортировать виртуальные машины, которые он предоставляет. Преобразование V2V выполняется на указанном прокси-хосте в рамках импортирования.

RHEL 5 Xen для выделения виртуальных машин

Виртуальные машины, созданные в RHEL 5 Xen, можно преобразовать, используя V2V (virt-v2v), и импортировать в ПО «zVirt Max». После добавления хоста RHEL 5 Xen в Менеджер управления можно импортировать виртуальные машины, которые он предоставляет. Преобразование V2V выполняется на указанном прокси-хосте в рамках импортирования.

KVM для выделения виртуальных машин

Виртуальные машины, созданные в KVM, можно импортировать в ПО «zVirt Max». После добавления хоста KVM в Менеджер управления можно импортировать виртуальные машины, которые он предоставляет.

Open Virtual Network (OVN) для выделения сетей

Open Virtual Network (OVN) - расширение Open vSwitch (OVS), предоставляющее программно-определяемые сети. После добавления OVN в Менеджер управления можно импортировать существующие сети OVN и создать новые сети OVN из Менеджера управления. Можно также автоматически установить OVN на Менеджер управления, используя engine-setup.

2.12.2. Добавление внешних провайдеров

2.12.2.1. Добавление экземпляра Red Hat Satellite для выделения хостов

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

Процедура

Нажмите Управление (Administration) → Провайдеры (Providers).
Нажмите Добавить (Add).
Введите Имя (Name) и Описание (Description).
Из выпадающего списка Тип (Type) выберите Foreman/Satellite.
В текстовом поле URL провайдера (Provider URL) введите URL или FQDN машины, на которой установлен экземпляр Satellite. Номер порта указывать не нужно.

Экземпляр Satellite нельзя добавить с помощью IP-адресов.
Поставьте флажок Требуется аутентификация (Requires Authentication).
Для экземпляра Satellite введите Имя пользователя (Username) и Пароль (Password). Нужно использовать то же имя пользователя и тот же пароль, которые использовались бы для авторизации на портале выделения ресурсов Satellite.
Проверка учетных данных:
- Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на экземпляре Satellite с использованием предоставленных учетных данных.
- Если в экземпляре Satellite используется SSL, то откроется окно Импортировать сертификаты провайдера (Import provider certificates); нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром Satellite, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

2.12.2.2. Добавление экземпляра OpenStack Image (Glance) для управления образами

Добавьте экземпляр OpenStack Image (Glance) в Менеджер управления для управления образами.

Процедура

Нажмите Управление (Administration) → Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробности на вкладке Общие настройки (General Settings). Дополнительные сведения об этих полях см. в Разделе 2.9.2.14. Описание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
Из выпадающего списка Тип (Type) выберите Образ OpenStack (OpenStack Image).
В текстовом поле URL провайдера (Provider URL) введите URL или FQDN машины, на которой установлен экземпляр OpenStack Image.
При желании установите флажок Требуется аутентификация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для пользователя экземпляра OpenStack Image, зарегистрированного в Keystone. Нужно также задать URL-адрес аутентификации сервера Keystone, задав Протокол (Protocol) (должен быть HTTP), Имя хоста (Hostname) и Порт API (API Port).

Укажите Арендатора (Tenant) для экземпляра OpenStack Image.
Проверка учетных данных:
- Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на экземпляре OpenStack Image с использованием предоставленных учетных данных.
- Если в экземпляре OpenStack Image используется SSL, то откроется окно Импортировать сертификаты провайдера. Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром OpenStack Image, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

2.12.2.3. Добавление KubeVirt/Openshift Virtualization в качестве внешнего провайдера

Для запуска виртуальных машин в контейнере на платформе OpenShift Container Platform, добавьте OpenShift в качестве внешнего провайдера в ПО «zVirt Max».

Эта функция называется OpenShift Virtualization.

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

На платформе OpenShift Container Platform ваш кластер конфигурируется для OpenShift Virtualization.

Процедура

На Портале администрирования выберите Управление (Administration) → Провайдеры (Providers) и нажмите Создать (New).
В разделе Добавить провайдера (Add Provider) выберите значение 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).

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

Выберите Ресурсы (Compute) → Виртуальные машины (Virtual Machines), чтобы развернуть виртуальную машину в новом кластере.
На веб-консоли OpenShift Container Platform, в представлении Администратор (Administrator) выберите Процессы (Workloads) → Виртуальные машины (Virtual Machines) для просмотра развернутой виртуальной машины.

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

Информация об OpenShift Virtualization.
Раздел 2.9.2.14. Описание общих настроек при добавлении провайдера.

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

Добавьте экземпляр VMware vCenter, чтобы импортировать виртуальные машины из VMware в Менеджер управления.

ПО «zVirt Max» использует V2V, чтобы перед импортированием преобразовать виртуальные машины VMware в корректный формат. Пакет virt-v2v должен быть установлен хотя бы на одном хосте. Пакет virt-v2v доступен на хостах как VDSM-зависимость при добавлении в ПО «zVirt Max».

Процедура

Нажмите Управление (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, на котором находятся виртуальные машины.
Проверьте учетные данные:
- Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на экземпляре VMware vCenter с использованием предоставленных учетных данных.
- Если экземпляр VMware vCenter использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром VMware vCenter, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

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

2.12.2.5. Добавление хоста RHEL 5 Xen в качестве провайдера виртуальных машин

Добавьте хост RHEL 5 Xen, чтобы импортировать виртуальные машины из Xen в ПО «zVirt Max».

ПО «zVirt Max» использует V2V, чтобы перед импортированием преобразовать виртуальные машины RHEL 5 Xen в корректный формат. Пакет virt-v2v должен быть установлен хотя бы на одном хосте. Пакет virt-v2v доступен по умолчанию на хостах как VDSM-зависимость при добавлении в ПО «zVirt Max».

Процедура

Включите аутентификацию с открытым ключом между прокси-хостом и хостом RHEL 5 Xen:
- Авторизуйтесь на прокси-хосте и сгенерируйте SSH-ключи для пользователя vdsm.
  sudo -u vdsm ssh-keygen
- Скопируйте открытый ключ пользователя vdsm на хост RHEL 5 Xen. Файл known_hosts на прокси-хосте также обновится и включит в себя хост-ключ хоста RHEL 5 Xen.
  sudo -u vdsm ssh-copy-id root@_xenhost.example.com_
- Авторизуйтесь на хосте RHEL 5 Xen, чтобы убедиться, что все работает правильно.
  sudo -u vdsm ssh root@_xenhost.example.com_
Нажмите Управление (Administration) → Провайдеры (Providers).
Нажмите Добавить (Add).
Введите Имя (Name) и Описание (Description).
Выберите XEN в выпадающем списке Тип (Type).
Выберите Центр данных (Data Center), в который будут импортироваться виртуальные машины Xen, либо Любой центр данных (Any Data Center), чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта.
Введите URI хоста RHEL 5 Xen в поле URI.
Выберите хост в выбранном центре данных с установленным пакетом virt-v2v, который будет служить Прокси-хостом (Proxy Host) во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера RHEL 5 Xen. Если выше вы выбрали Любой центр данных (Any Data Center), то вы не можете выбирать здесь хост, но зато можете указывать хост для конкретной операции импорта.
Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на хосте RHEL 5 Xen.
Нажмите OK.

2.12.2.6. Добавление хоста KVM в качестве провайдера виртуальных машин

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

Процедура

Включите аутентификацию с открытым ключом между прокси-хостом и хостом KVM:
- Авторизуйтесь на прокси-хосте и сгенерируйте SSH-ключи для пользователя vdsm.
  sudo -u vdsm ssh-keygen
- Скопируйте открытый ключ пользователя vdsm на хост KVM. Файл known_hosts на прокси-хосте также обновится и включит в себя хост-ключ хоста KVM.
  sudo -u vdsm ssh-copy-id root@_kvmhost.example.com_
- Авторизуйтесь на хосте 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.12.2.7. Добавление Open Virtual Network (OVN) в качестве внешнего провайдера сети

Вы можете использовать Open Virtual Network (OVN) для создания оверлейных виртуальных сетей, которые обеспечивают связь между виртуальными машинами без добавления VLAN или изменения инфраструктуры. OVN – это расширение Open vSwitch (OVS), которое обеспечивает встроенную поддержку виртуальных оверлейных сетей L2 и L3.

Вы можете установить новый провайдер сети OVN или добавить существующий.

Вы также можете подключить сеть OVN к собственной сети ПО «zVirt Max». Дополнительную информацию см. в Разделе 2.9.2.12. Подключение сети OVN к физической сети. Данная возможность доступна только как предварительная версия технологии, представленная для оценки.

Оvirt-provider-ovn предоставляет REST API для работы в сети OpenStack. Его можно использовать для создания сетей, подсетей, портов и маршрутизаторов. Подробности см. в документе OpenStack Networking API v2.0.

CloudForms поддерживает OVN в качестве внешнего провайдера с помощью API для работы в сети OpenStack. Подробности см. в разделе Network Managers документа Red Hat CloudForms: Managing Providers.

Подробности см. в документах Open vSwitch Documentation и Open vSwitch Manpages.

2.12.2.8. Установка нового провайдера сети OVN

При установке OVN с использованием engine-setup выполняются следующие шаги:

Установка центрального сервера OVN на машину с Менеджером управления.
Добавление OVN к ПО «zVirt Max» в качестве внешнего провайдера сети.
Установка Провайдер сети по умолчанию (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 спросит:

При настройке ovirt-provider-ovn значение ovirt-provider-ovn задается в качестве провайдера сети по умолчанию для кластера по умолчанию. Остальные кластеры можно настроить с OVN после установки. Настроить ovirt-provider-ovn (Да, Нет) [Да]: (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]

Ответьте на следующий вопрос:
```
Использовать учетные данные по умолчанию (admin@internal) для ovirt-provider-ovn (Да, Нет) [Да]?: (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, выполните следующие дополнительные действия:

Добавьте сеть в кластер Default.
- Для этого установите флажок Создать на внешнем провайдере (Create on external provider). Будет создана сеть на базе ovirt-provider-ovn.
- Дополнительно: Чтобы подключить сеть OVN к физической сети, установите флажок Подключение к физической сети (Connect to physical network) и укажите сеть ПО «zVirt Max», которую нужно использовать.
- Дополнительно: Определите, должна ли сеть использовать группу безопасности, и выберите ее в выпадающем списке Группы безопасности (Security Groups). Дополнительную информацию о доступных опциях см. в Разделе 2.4.1.9. Описание общих настроек логической сети.
Добавьте хосты к кластеру Default или переустановите хосты на нем, чтобы они использовали нового Провайдера сети по умолчанию (Default Network Provider) кластера – ovirt-provider-ovn.
Дополнительно: Измените кластеры, не являющиеся кластерами по умолчанию, и установите параметр Провайдер сети по умолчанию (Default Network Provider) в значение ovirt-provider-ovn.
- Дополнительно: Переустановите хосты на каждом кластере, не являющемся кластером по умолчанию, чтобы они использовали нового Провайдера сети по умолчанию (Default Network Provider) кластера – ovirt-provider-ovn.

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

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

2.12.2.9. Добавление существующего провайдера сети OVN

Добавление существующего центрального сервера OVN в качестве внешнего провайдера сети в ПО «zVirt Max» включает в себя следующие ключевые шаги:

Установите провайдер OVN, прокси, используемый Менеджером управления для взаимодействия с OVN. Провайдер OVN можно установить на любой машине, но он должен иметь возможность связываться с центральным сервером OVN и Менеджером управления.
Добавьте провайдера OVN в ПО «zVirt Max» в качестве внешнего провайдера сети.
Создайте новый кластер, использующий OVN в качестве провайдера сети по умолчанию. Хосты, добавленные в этот кластер, автоматически настраиваются на связь с OVN.

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

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

openvswitch-ovn-central
openvswitch
openvswitch-ovn-common
python-openvswitch

Если эти пакеты недоступны в репозиториях, уже включенных на машине провайдера, их можно загрузить с веб-сайта OVS: http://openvswitch.org/download/.

Процедура

Установите и настройте провайдер OVN.
- Установите провайдер на машине провайдера:
  dnf install ovirt-provider-ovn
- Если вы не устанавливаете провайдер на одну машину с Менеджером управления, то добавьте следующую запись в файл /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует):
  [OVIRT] ovirt-host=https://Manager_host_name
  Это нужно для аутентификации, если она включена.
- Если вы не устанавливаете провайдер на одну машину с центральным сервером OVN, то добавьте следующую запись в файл /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует):
  [OVN REMOTE] ovn-remote=tcp:__OVN_central_server_IP__:6641
- Откройте порты 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
- Запустите и включите службу:
  systemctl start ovirt-provider-ovn systemctl enable ovirt-provider-ovn
- Настройте центральный сервер OVN на прослушивание запросов с портов 6642 и 6641:
  ovn-sbctl set-connection ptcp:6642 ovn-nbctl set-connection ptcp:6641
На Портале администрирования нажмите Управление (Administration) → Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробные сведения на вкладке Общие настройки (General Settings). Дополнительную информацию об этих полях см. в Разделе 2.9.2.14. Описание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
В списке Тип (Type) выберите Внешний провайдер сети.
Нажмите на текстовое поле Сетевой плагин (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).

При желании укажите Арендатора (Tenant) для внешнего провайдера сети.

Метод аутентификации должен быть настроен в файле /etc/ovirt-provider-ovn/conf.d/10_engine_setup.conf (создайте этот файл, если он еще не существует). Перезапустите службу ovirt-provider-ovn, чтобы изменение вступило в силу.
Проверьте учетные данные:
- Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию в OVN с использованием предоставленных учетных данных.
- Если экземпляр OVN использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный экземпляром OVN, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.
Создайте новый кластер, использующий OVN в качестве провайдера сети по умолчанию. См. Раздел 2.3.2.1. Создание нового кластераи выберите провайдера сети OVN в выпадающем списке Провайдер сети по умолчанию (Default Network Provider).
Добавьте хосты к кластеру. Хосты, добавленные в этот кластер, автоматически настраиваются на связь с OVN. Чтобы добавить новые хосты, см. Раздел 2.5.3.1. Добавление стандартных хостов в Менеджер управления.
Импортируйте или добавьте сети OVN к новому кластеру. Чтобы импортировать сети, см. Импортирование сетей (Importing Networks). Чтобы создать новые сети с использованием OVN, см. Создание новой логической сети в центре данных или кластере и установите флажок Создать на внешнем провайдере (Create on external provider). По умолчанию выбрано значение ovirt-provider-ovn.

Чтобы подключить сеть OVN к собственной сети ПО «zVirt Max», установите флажок Подключение к физической сети (Connect to physical network) и укажите сеть ПО «zVirt Max», которую нужно использовать. Дополнительную информацию и предварительные требования см. в Разделе 2.9.2.12. Подключение сети OVN к физической сети.

Теперь можно создавать виртуальные машины, использующие сети OVN.

2.12.2.10. Использование 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. Если в одном плейбуке присутствуют оба параметра, то этот плейбук не работает.

Плейбук с параметром 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

Плейбук с параметром 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.12.2.11. Настройка хостов для сети туннелей 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

Например:

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-значное имя. Указания по визуализации сопоставления этих имен см. в разделе 3.6.6.1. Сопоставление имен VDSM с именами логических сетей.

Обновление сети туннелей OVN на одном хосте

Обновить сеть туннелей OVN на одном хосте можно с помощью vdsm-tool:

vdsm-tool ovn-config _OVN_Central_IP_ _Tunneling_IP_or_Network_Name_

Пример 4 Обновление хоста с помощью vdsm-tool

vdsm-tool ovn-config 192.168.0.1 MyNetwork

2.12.2.12. Подключение сети OVN к физической сети

Данная возможность зависит от поддержки Open vSwitch, которая в ПО «zVirt Max» доступна только как предварительная версия технологии, представленная для оценки.

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

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

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

В качестве Типа коммутатора (Switch Type) в кластере должно быть выбрано OVS. Хосты, добавляемые в этот кластер, не должны иметь уже настроенных сетей ПО «zVirt Max», таких как мост (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.12.2.13. Добавление внешнего провайдера сети

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

Процедура

Нажмите Управление (Administration) → Провайдеры (Providers).
Нажмите Добавить (Add) и введите подробные сведения на вкладке Общие настройки (General Settings). Дополнительную информацию об этих полях см. в Разделе 2.9.2.14. Описание общих настроек при добавлении провайдера.
Введите Имя (Name) и Описание (Description).
Выберите Внешнего провайдера сети (External Network Provider) в выпадающем списке Тип (Type).
При желании нажмите на текстовое поле Сетевой модуль (Networking Plugin) и выберите соответствующий драйвер в выпадающем меню.

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

Введите URL-адрес или FQDN машины с установленным внешним провайдером сети в текстовое поле URL-адрес провайдера (Provider URL) и далее номер порта. По умолчанию установлен флажок Только для чтения (Read-Only). Это не позволит пользователям внести изменения в провайдер внешней сети.

Чтобы ПО «zVirt Max» поддерживала установленную систему, не снимайте флажок Только для чтения (Read-Only).
При желании установите флажок Требуется аутентификация (Requires Authentication) и введите Имя пользователя (Username) и Пароль (Password) для пользователя внешнего провайдера сети, зарегистрированного в Keystone. Необходимо также указать аутентификационный URL-адрес сервера Keystone, задав Протокол (Protocol), Имя хоста (Hostname) и Порт API (API Port).

При желании укажите Арендатора (Tenant) для внешнего провайдера сети.
Проверьте учетные данные:
- Нажмите Тестировать (Test), чтобы проверить, удается ли выполнить успешную аутентификацию на провайдере внешней сети с использованием предоставленных учетных данных.
- Если провайдер внешней сети использует SSL, откроется окно Импортировать сертификаты провайдера (Import provider certificates). Нажмите OK, чтобы импортировать сертификат, предоставленный внешним провайдером сети, чтобы гарантировать, что Менеджер управления сможет взаимодействовать с экземпляром.
Нажмите OK.

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

Описание общих настроек при добавлении провайдера

На вкладке Общие (General) в окне Добавить провайдера (Add Provider) можно регистрировать основные сведения о внешнем провайдере.

Таблица 70. Добавление провайдера: общие настройки
Параметр	Пояснение
Имя (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): Необязательно. Имя арендатора, членом которого является внешний провайдер сети. Foreman/Satellite URL-адрес провайдера (Provider URL): URL-адрес или FQDN машины, на которой размещен экземпляр Satellite. Добавлять номер порта в конец URL-адреса или FQDN не нужно. Требуется аутентификация (Requires Authentication): Позволяет указать, требуется ли аутентификация для провайдера. Аутентификация обязательна, если выбрано Foreman/Satellite. Имя пользователя (Username): Имя пользователя для подключения к экземпляру Satellite. Это имя пользователя должно быть тем же, что и имя пользователя, используемое для входа на портал предоставления экземпляра Satellite. Пароль (Password): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. Этот пароль должен быть тем же, что и пароль, используемый для входа на портал предоставления экземпляра Satellite. 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, членом которого является служба OpenStack Image. Сетевые настройки OpenStack (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. Домены позволяют объединять пользователей в группы для различных целей, например для настройки конфигурации конкретного домена или параметров безопасности. Дополнительную информацию см. в разделе OpenStack Identity (keystone) Руководстве пользователя Architecture Guide по платформе Red Hat 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. Имя арендатора 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): Пароль, по которому будет выполняться аутентификация пользователя с вышеуказанным именем. RHEL 5 Xen Центр данных (Data Center): Укажите центр данных, в который будут импортироваться виртуальные машины Xen, либо выберите Любой центр данных (Any Data Center), чтобы указывать центр данных, являющийся приемником, во время каждой отдельной операции импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines)). URI: URI хоста RHEL 5 Xen. Прокси-хост (Proxy Host): Выберите хост в выбранном центре данных с установленным пакетом virt-v2v, который будет служить хостом во время операций импорта виртуальных машин. Этот хост также должен быть способен подключаться к сети внешнего провайдера RHEL 5 Xen. Если вы выбрали Любой центр данных (Any Data Center), то вы не сможете выбрать хост здесь, но зато сможете указывать хост во время конкретных операций импорта (используя функцию Импортировать (Import) на вкладке Виртуальные машины (Virtual Machines). 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.12.2.14. Изменение внешнего провайдера

Процедура

Нажмите Управление (Administration) → Провайдеры (Providers) и выберите внешнего провайдера, который нужно изменить.
Нажмите Изменить (Edit).
Измените текущие значения параметров провайдера на желаемые.
Нажмите OK.

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

Процедура

Нажмите Управление (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 Max».
Локальный (local) – агенту с признаком высокой доступности на узле, выдающем команду, запрещено вести мониторинг состояния виртуальной машины с Менеджером управления. В локальном режиме обслуживания этот узел освобождается от размещения виртуальной машины с Менеджером управления; если же виртуальная машина с Менеджером управления размещалась на нем на момент перевода в этот режим, то Менеджер управления будет перенесен на другой узел при условии, что один из узлов доступен. Локальный режим обслуживания рекомендуется при применении системных изменений или обновлений к узлу с ролью hosted engine.
Не назначен (none) – отключает режим обслуживания, обеспечивая работоспособность агентов с признаком высокой доступности.

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

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

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

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

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

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

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

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

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

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

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

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

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 на общем хранилище, поэтому все хосты, развернутые после изменения конфигурации, используют эти значения. Чтобы применить новое значение на хосте, повторно разверните хост.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура

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

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

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

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

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

Процедура

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

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

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

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

Подключитесь к одному из узлов с ролью hosted engine:
```
$ ssh root@_host_address_
```
Переведите hosted engine в глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Проверьте, имеется ли уже запущенный экземпляр виртуальной машины с Менеджером управления:
```
hosted-engine --vm-status
```
Если экземпляр виртуальной машины с Менеджером управления уже работает, подключитесь к его хосту:
```
ssh root@_host_address_
```
Выключите виртуальную машину:
```
hosted-engine --vm-shutdown
```
Если виртуальная машина не выключается, выполните следующую команду:

hosted-engine --vm-poweroff
Запустите виртуальную машину с Менеджером управления в режиме паузы:
```
hosted-engine --vm-start-paused
```
Задайте временный пароль VNC:
```
hosted-engine --add-console-password
```
Эта команда выводит информацию, необходимую для авторизации на виртуальной машине с Менеджером управления с помощью VNC.
Авторизуйтесь на виртуальной машине с Менеджером управления с помощью VNC. Виртуальная машина с Менеджером управления по-прежнему в режиме паузы, поэтому кажется, что она зависла.

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

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

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

Загрузите виртуальную машину с Менеджером управления в режиме восстановления.
Отключите глобальный режим обслуживания
```
hosted-engine --set-maintenance --mode=none
```
Теперь можно запускать задачи восстановления на виртуальной машине с Менеджером управления.

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

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

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

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

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

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

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

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

Процедура

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

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

Процедура

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

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

engine-setup

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

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

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

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

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

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

Процедура

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

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

hosted-engine --vm-status

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

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

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

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

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

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

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

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

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

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

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

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

Процедура

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

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

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

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

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

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

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

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

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

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

engine-backup --mode=backup

engine-backup --mode=restore

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

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

--mode (режим)

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

--file (файл)

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

--log (журнал)

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

--scope (состав)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

all (всё)

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

files (файлы)

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

db (база данных)

Резервная копия только базы данных Менеджера управления.

dwhdb (база данных хранилища)

Резервная копия только базы данных Хранилища (DWH).

cinderlibdb (база данных cinderlib)

Резервная копия только базы данных Cinderlib

Параметр --scope можно прописать несколько раз.

Кроме того, можно сконфигурировать команду engine-backup на резервное копирование дополнительных файлов. Она восстанавливает все, что записывает в резервную копию.

Для восстановления базы данных в новой установке Менеджера управления недостаточно одной резервной копии базы данных. Менеджеру управления также требуется доступ к файлам конфигурации. Если значение объема не всё (all), то обязательно нужно добавить параметр --scope=files или создать резервную копию файловой системы._

Полное описание команды engine-backup доступно при вводе команды engine-backup --help на машине с Менеджером управления.

Процедура

Авторизуйтесь на Менеджере управления.
Создайте резервную копию:
```
engine-backup --scope=all --mode=backup --file= file_name  --log=_log_file_name
```
При использовании этой команды создается резервная копия в file_name.tar и файл журналов в log_file_name.

Используйте file_name.tar для восстановления среды.

Несколько сценариев резервного копирования показано на примерах ниже.

Пример 1. Полное резервное копирование

engine-backup --scope=all --mode=backup --file=_file_name_ --log=_log_file_name_

Пример 2. Резервная копия базы данных Менеджера управления

engine-backup --scope=files --scope=db --mode=backup --file=_file_name_  --log= _log _file_name_

Пример 3. Резервная копия базы данных Хранилища (DWH)

engine-backup --scope=files --scope=dwhdb --mode=backup --file= _file_name_  --log= _log_file_name_

Пример 4. Добавление конкретных файлов к резервной копии

Создайте каталог для хранения настроек конфигурации для команды engine-backup:
```
mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d
```
Создайте в новом каталоге текстовый файл ntp-chrony.sh со следующим содержимым:
```
BACKUP _ PATHS="$ { BACKUP _ PATHS}

/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"
```
При выполнении команды engine-backup укажите параметр --scope=files. Резервное копирование и восстановление включают в себя /etc/chrony.conf, /etc/ntp.conf и /etc/ovirt-engine-backup.

3.2.1.4. Восстановление из резервной копии с помощью команды engine-backup

Восстановление из резервной копии с помощью команды engine-backup предусматривает больше шагов, чем создание резервной копии, и зависит от того, куда будут восстанавливаться данные. Например, команду engine-backup можно использовать для восстановления резервных копий на новые установки ПО «zVirt Max», поверх существующих установок ПО «zVirt Max», с использованием локальных или удаленных баз данных.

Версия Менеджера управления, которая используется для восстановления из резервной копии, должна быть выше или равна версии Менеджера управления, использованной для создания резервной копии. Начиная с версии ПО «zVirt Max» 3.0, эта политика строго соблюдается командой engine-backup. Чтобы узнать версию ПО «zVirt Max» в файле резервной копии, распакуйте файл резервной копии и посмотрите значение в файле версия (version), расположенном в корневом каталоге распакованных файлов.

3.2.1.5. Восстановление из резервной копии в новую установку

Команду engine-backup можно использовать для восстановления из резервной копии в новую установку Менеджера управления. Процедура ниже должна быть выполнена на машине, на которой установлена базовая операционная система и установлены необходимые пакеты для Менеджера управления, но команда engine-setup еще не запускалась. Для этой процедуры предполагается, что к файлу или файлам резервной копии можно получить доступ с машины, на которой необходимо восстановить резервную копию.

Процедура

Авторизуйтесь на Менеджере управления. Для восстановления базы данных engine на удаленном хосте нужно будет авторизоваться и выполнить соответствующие действия на этом хосте. Аналогично, для одновременного восстановления базы данных Хранилища (DWH) на удаленном хосте нужно будет авторизоваться и выполнить соответствующие действия на этом хосте.
Восстановление полной резервной копии или резервной копии только базы данных.
- Восстановление из полной резервной копии:
  engine-backup --mode=restore --file=_file_name_ --log= _log_file_name_ --provision-db --restore-permissions
  Если Хранилище (DWH) тоже восстанавливается в составе полной резервной копии, необходимо предоставить дополнительную базу данных:
  engine-backup --mode=restore --file= _file_name_ --log=_log_file_name_ --provision-db --provision-dwh-db --restore-permissions
- Восстановление из резервной копии только базы данных через восстановление файлов конфигурации и резервной копии базы данных:
  engine-backup --mode=restore --scope=files --scope=db --file= _file_name_ --log= _log_file_name_ --provision-db --restore-permissions
  В примере выше также восстанавливается резервная копия базы данных Менеджера управления.
  engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log= _log_file_name _ --provision-dwh-db --restore-permissions
  В примере выше также восстанавливается резервная копия базы данных Хранилища (DWH).
  
  В случае положительного результата на экране появится следующее сообщение:
  You should now run engine-setup. Done.
Выполните следующую команду и следуйте подсказкам для настройки восстановленного Менеджера управления:
```
engine-setup
```

3.2.1.6. Восстановление резервной копии с перезаписью существующей установки

С помощью команды engine-backup можно восстановить резервную копию на машину, на которой уже установлен и настроен Менеджер управления. Это полезно, когда вы сделали резервную копию среды, внесли в неё изменения, а затем хотите отменить изменения, восстановив среду из резервной копии.

Изменений, внесенных в среду после создания резервной копии, например, в случае добавления или удаления хостов, не будет в восстановленной среде. Изменения необходимо будет внести заново.

Процедура

Авторизуйтесь на Менеджере управления.
Удалите файлы конфигурации и очистите базу данных, ассоциированную с Менеджером управления:
```
engine-cleanup
```
С помощью команды engine-cleanup можно очистить только базу данных Менеджера управления; она не сбрасывает базу данных и не удаляет пользователя, владеющего этой базой данных.

Восстановление из полной резервной копии или резервной копии только базы данных. Вам не нужно создавать новую базу данных или указывать учетные данные базы данных, так как пользователь и база данных уже существуют.

Восстановление из полной резервной копии:

engine-backup --mode=restore --file=_file_name_  --log=_log_file_name_  --restore-permissions

Восстановление из резервной копии только базы данных через восстановление файлов конфигурации и резервной копии базы данных:

engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name_  --log=log_file_name --restore-permissions

Чтобы восстановить только базу данных Менеджера управления (например, если база данных Хранилища (DWH) находится на другой машине), можно не указывать параметр --scope=dwhdb.

В случае положительного результата на экране появится следующее сообщение:

You should now run engine-setup.

Done.

Переконфигурируйте Менеджер управления:
```
engine-setup
```

3.2.1.7. Восстановление из резервной копии с другими учетными данными

С помощью команды engine-backup можно восстановить резервную копию на машину, на которой уже установлен и настроен Менеджер управления, но учетные данные базы данных в резервной копии отличаются от учетных данных базы данных на машине, на которой будет восстановлена резервная копия. Это полезно, когда есть резервная копия установки, и установку нужно восстановить из резервной копии, но в другой системе.

При восстановлении резервной копии для перезаписи существующей установки необходимо выполнить команду engine-cleanup для очистки существующей установки перед использованием команды engine-backup.

С помощью команды engine-cleanup можно очистить только базу данных engine. Выполнение команды engine-cleanup не сбрасывает базу данных и не удаляет пользователя, владеющего этой базой данных. Поэтому нет необходимости создавать новую базу данных или указывать учетные данные базы данных. Однако если учетные данные владельца базы данных engine неизвестны, то их необходимо изменить перед восстановлением из резервной копии.

Процедура

Авторизуйтесь на машине с Менеджером управления.
Выполните следующую команду и следуйте подсказкам, чтобы удалить файлы конфигурации Менеджера управления и очистить его базу данных:
```
engine-cleanup
```
Измените пароль для владельца базы данных engine, если учетные данные этого пользователя неизвестны:
- Введите в командной строке:
  su - postgres -c 'psql'
- Измените пароль пользователя, владеющего базой данных engine:
  postgres=# alter role _user_name_ encrypted password '_new_password_';
- При необходимости повторите эти действия для пользователя, владеющего базой данных ovirt_ engine_history.

Восстановите полную резервную копию или резервную копию только базы данных с параметром --change-db-credentials, чтобы передать учетные данные новой базы данных. Параметр database _ location для базы данных, которая по отношению к Менеджеру управления является локальной, будет иметь значение localhost.

В примерах ниже параметр -- password прописан для каждой базы данных без указания пароля, запрашивающий пароль для каждой базы данных. Либо можно использовать параметры -- *passfile=password_file для каждой базы данных, чтобы безопасно передать пароли инструменту *engine-backup без необходимости интерактивных запросов.

Восстановление из полной резервной копии:

engine-backup --mode=restore --file=_file_name_ --log=_log_file_name_ --change-db-credentials --db-host=_database_location_ --db-name=_database_name_ --db-user=engine --db-password --no-restore-permissions

Если Хранилище (DWH) тоже восстанавливается в составе полной резервной копии, то включите обновленные учетные данные в дополнительную базу данных:

engine-backup --mode=restore --file=_file_name_ --log=_log_file_name_ --change-db-credentials --db-host=_database_location_ --db-name=_database_name_ --db-user=engine --db-password --change-dwh-db-credentials --dwh-db-host=_database_location_ --dwh-db-name=_database_name_ --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions

Восстановление из резервной копии только базы данных через восстановление файлов конфигурации и резервной копии базы данных:
```
engine-backup --mode=restore --scope=files --scope=db --file=_file_name_ --log=_log_file_name_ --change-db-credentials --db-host=_database_location_ --db-name=_database_name_ --db-user=engine --db-password --no-restore-permissions
```
В примере выше также восстанавливается резервная копия базы данных Менеджера управления.
```
engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --change-dwh-db-credentials --dwh-db-host=_database_location_ --dwh-db-name=_database_name_ --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions
```
В примере выше также восстанавливается резервная копия базы данных Хранилища (DWH). В случае положительного результата на экране появится следующее сообщение:
```
You should now run engine-setup.

Done.
```

Выполните команду ниже и следуйте подсказкам, чтобы перенастроить межсетевой экран и убедиться, что служба ovirt-engine настроена правильно:
```
engine-setup
```

3.2.1.8. Резервное копирование и восстановление hosted engine

Можно создать резервную копию hosted engine и восстановить его в новой среде hosted engine. Эта процедура применяется для таких задач, как перенос среды в новый домен хранения hosted engine с другим типом хранилища.

Когда указывается файл резервной копии во время развертывания, резервная копия восстанавливается на новой виртуальной машине с Менеджером управления с новым доменом хранения hosted engine. Старый Менеджер управления удаляется, а старый домен хранения hosted engine переименовывается, и его можно удалить вручную после, убедившись, что новая среда работает корректно.

Настоятельно рекомендуется развертывание на новом хосте; если хост, используемый для развертывания, существовал в среде, с которой была сделана резервная копия, то он будет удален из восстановленной базы данных, чтобы избежать конфликтов в новой среде. При развертывании на новом хосте необходимо присвоить хосту уникальное имя. Повторное использование имени существующего хоста, включенного в резервную копию, может привести к конфликтам в новой среде.

Операция резервного копирования и восстановления включает в себя следующие основные действия:

Резервное копирование исходного Менеджера управления с помощью инструмента engine-backup.
Развертывание нового hosted engine и восстановление из резервной копии.
Включение репозиториев Менеджера управления на новой виртуальной машине с Менеджером управления.
Переустановка узлов с ролью hosted engine для обновления их конфигураций.
Удаление старого домена хранения *hosted engine8.

Для этой процедуры предполагается, что доступ и внесение изменений в исходный Менеджер управления разрешены.

Предварительные условия

FQDN готово для Менеджера управления и хоста. В DNS должны быть установлены записи прямого и обратного просмотра. FQDN нового Менеджера управления должно совпадать с FQDN исходного Менеджера управления.

Исходный Менеджер управления должен быть обновлен до последней промежуточной версии.

Если необходимо восстановиться из резервной копии, но нового виртуального устройства нет, то процесс восстановления приостанавливается, и можно авторизоваться на временной машине с Менеджером управления через SSH, зарегистрировать, подписаться или настроить каналы по мере необходимости, а также обновить пакеты Менеджера управления перед возобновлением процесса восстановления.

Уровень совместимости центра данных должен быть установлен на последнюю версию, чтобы обеспечить совместимость с обновленной версией хранилища.
В среде должен быть как минимум один обычный хост. Этот хост (и любые другие обычные хосты) будет оставаться активным, чтобы взять на себя роль SPM и разместить любые запущенные виртуальные машины. Если обычный хост еще не является SPM, переместите роль SPM до создания резервной копии, выбрав обычный хост и нажав Управление (Management) → Назначить как SPM (Select as SPM).

Если обычные хосты недоступны, есть два способа их добавить:

Удалить конфигурацию hosted engine с узла (но не удаляйте узел из среды). См. Раздел 3.1.7. Удаление хоста из среды hosted engine.
Добавьте новый обычный хост. См. Раздел 2.5.3.1. Добавление стандартных хостов в Менеджер управления.

Резервное копирование исходного Менеджера управления

Создайте резервную копию исходного Менеджера управления с помощью команды engine-backup и скопируйте файл резервной копии в отдельное место, чтобы иметь к нему постоянный доступ в течение всего процесса.

Дополнительные сведения о параметрах engine-backup --mode=backup см. в разделе 3.2.1. Резервное копирование и восстановление Менеджера управления в Руководстве администратора.

Процедура

Авторизуйтесь на одном из узлов с ролью hosted engine и переведите среду в глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```

Авторизуйтесь на исходном Менеджере управления и остановите службу ovirt-engine:

systemctl stop ovirt-engine
systemctl disable ovirt-engine

Хотя останавливать работу исходного Менеджера управления необязательно, это рекомендуется сделать, поскольку так можно быть уверенным, что после создания резервной копии в среду не будут внесены изменения. Кроме того, так можно избежать ситуации, когда исходный и новый Менеджеры управления одновременно управляют существующими ресурсами.

Выполните команду engine-backup, указав имя создаваемого файла резервной копии и имя создаваемого файла журнала, для хранения журнала резервного копирования:
```
engine-backup --mode=backup --file=_file_name_ --log=_log_file_name_
```
Скопируйте файлы на внешний сервер. В примере ниже storage.example.com – это FQDN сервера сетевого хранилища, на котором будет храниться резервная копия до востребования, а /backup/ – это любая указанная папка или путь.
```
scp -p _file_name_ _log_file_name_ storage.example.com:/backup/
```
Авторизуйтесь на одном из узлов с ролью hosted engine и выключите виртуальную машину с исходным Менеджером управления:
```
hosted-engine --vm-shutdown
```
После создания резервной копии Менеджера управления разверните новый hosted engine и восстановите резервную копию на новой виртуальной машине.

Восстановление из резервной копии на новом hosted engine

Запустите скрипт hosted-engine на новом хосте и используйте опцию --restore-from-file=path/to/file_name для восстановления Менеджера управления из резервной копии во время развертывания.

Если вы используете хранилище iSCSI и ваш iSCSI-таргет фильтрует подключения в соответствии со списком контроля доступа инициатора, то развертывание может завершиться с ошибкой ДОМЕН_ХРАНЕНИЯ_НЕДОСТУПЕН (STORAGE _ DOMAIN _ UNREACHABLE). Чтобы этого избежать, обновите конфигурацию iSCSI перед началом развертывания hosted engine.

При повторном развертывании на существующем хосте необходимо обновить настройки инициатора iSCSI хоста в /etc/iscsi/initiatorname.iscsi. IQN инициатора должен быть таким же, как и сопоставленный ранее с iSCSI-таргетом, либо обновленным до нового IQN, если применимо.
При развертывании на новом хосте обновите конфигурацию iSCSI-таргета, чтобы принимать подключения с этого хоста.

Обратите внимание, что IQN можно обновить на стороне хоста (iSCSI-инициатора) или на стороне хранилища (iSCSI-таргета).

Процедура

Скопируйте файл резервной копии на новый хост. В следующем примере host.example.com – это FQDN хоста, а /backup/ – любая указанная папка или путь.
```
scp -p  _file_name_  host.example.com:/backup/
```
Авторизуйтесь на новом хосте.
В случае развертывания на ПО «zVirt Max» Host пакет ovirt-hosted-engine-setup уже установлен, поэтому пропустите этот шаг. В случае развертывания на Red Hat Enterprise Linux установите пакет ovirt-hosted-engine-setup:
```
dnf install ovirt-hosted-engine-setup
```
Для запуска скрипта используйте менеджер окон tmux, чтобы избежать потери сеанса в случае нарушения работы сети или терминала. Установите и запустите tmux:
```
dnf -y install tmux
tmux
```
Запустите скрипт hosted-engine, указав путь к файлу резервной копии:
```
hosted-engine --deploy --restore-from-file=backup/ _file_name_
```
Чтобы в любой момент выйти из скрипта и прервать развертывание, нажмите CTRL+D.

Чтобы начать развертывание, нажмите Да (Yes).
Настройте сеть. Скрипт обнаруживает возможные сетевые карты для использования в качестве моста управления для среды.
Если нужно использовать пользовательское виртуальное устройство для установки виртуальной машины, введите путь к архиву OVA. Либо оставьте это поле пустым.
Введите root-пароль для Менеджера управления.
Введите открытый ключ SSH, который позволит авторизоваться в Менеджере управления в качестве root-пользователя, и укажите, следует ли разрешить root-пользователю доступ по SSH.
Введите конфигурацию ЦП и памяти виртуальной машины.
Введите MAC-адрес виртуальной машины с Менеджером управления или примите случайно сгенерированный адрес. Если нужно предоставить виртуальной машине с Менеджером управления IP-адрес через DHCP, убедитесь, что у вас есть действительное резервирование DHCP для этого MAC-адреса.

Введите сетевые параметры виртуальной машины. Если вы укажете Статический (Static), то введите IP-адрес Менеджера управления.

Статический IP-адрес должен относиться к той же подсети, что и хост. Например, если хост имеет адрес 10.1.1.0/24, то IP-адрес виртуальной машины с Менеджером управления должен находиться в том же диапазоне подсети (10.1.1.1-254/24).

Укажите, нужно ли добавлять записи для виртуальной машины с Менеджером управления и базового хоста в файл /etc/hosts виртуальной машины. Убедитесь, что имена хостов разрешимы.
Укажите имя и номер TCP-порта SMTP-сервера, адрес электронной почты, используемый для отправки уведомлений, и через запятую список адресов электронной почты, используемых для получения этих уведомлений:

Введите пароль пользователя admin@internal для доступа к Порталу администрирования.

Если хост перестает работать из-за отсутствия необходимой сети или схожей проблемы, развертывание приостанавливается и отображается следующее сообщение:

[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса позволяет:

Подключиться к Порталу администрирования, используя предоставленный URL-адрес.
Оценить ситуацию, выяснить, почему хост не работает, и внести необходимые исправления. Например, если развернутая система была восстановлена из резервной копии и эта резервная копия включала в себя обязательные сети (required networks) для кластера хоста, то настройте сети, подключив к ним соответствующие сетевые карты хоста.
Если все выглядит как положено и хост имеет статус Включен (Up), удалите файл блокировки, показанный в сообщении выше. Развертывание продолжается.

Выберите используемый тип хранилища:

Для NFS введите версию, полный адрес и путь к хранилищу, а также любые параметры монтирования.

Не используйте точку монтирования старого домена хранения hosted engine для нового домена хранения, так как вы рискуете потерять данные виртуальной машины.

Для iSCSI введите данные портала и выберите таргет и LUN из списков автоматически обнаруженных устройств. Во время развертывания можно выбрать только один iSCSI-таргет, но поддерживаются несколько путей для подключения всех порталов одной группы порталов.

Для Fibre Channel выберите LUN из списка автоматически обнаруженных устройств. Адаптеры шины хоста должны быть настроены и подключены, а на LUN не должно быть никаких данных. Информацию о том, как повторно использовать существующий LUN, см. в разделе Повторное использование LUN в Руководстве пользователя.

Укажите размер диска Менеджера управления.
- Скрипт продолжит работу до тех пор, пока развертывание не будет завершено.
Процесс развертывания изменяет SSH-ключи Менеджера управления. Чтобы клиентские машины смогли обращаться к новому Менеджеру управления без ошибок SSH, удалите запись исходного Менеджера управления из файла .ssh/known_hosts на всех клиентских машинах, которые обращались к исходному Менеджеру управления.

Переустановка хостов

Переустановите хосты через Портал администрирования. Процедура включает в себя остановку и перезапуск хоста.

Настоятельно рекомендуем при установке или переустановке операционной системы хоста сначала отключить все подключенные к хосту существующие хранилища, не относящиеся к ОС, чтобы избежать случайной инициализации их дисков и потенциальной потери данных.

Предварительные условия

Если в кластере включена миграция, то виртуальные машины могут автоматически мигрировать на другой хост в кластере. Поэтому переустанавливайте хост, пока уровень его использования относительно невысок.
Убедитесь, что в кластере достаточно памяти для его хостов для выполнения обслуживания. Если в кластере недостаточно памяти, то миграция виртуальных машин зависнет, а затем завершится сбоем. Прежде чем переводить хост в режим обслуживания, выключите некоторые или все виртуальные машины, чтобы уменьшить использование ресурсов памяти.
Перед выполнением переустановки убедитесь, что кластер содержит более одного хоста. Не пытайтесь переустановить все хосты одновременно. Один хост должен оставаться доступным для выполнения задач Менеджера пула хранения (SPM).

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall). Откроется окно Установить хост (Install Host).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
Нажмите OK, чтобы переустановить хост.

После переустановки хоста и возвращения его статуса к значению Включен (Up) вы сможете перенести виртуальные машины обратно на хост.

После того как вы зарегистрируете хост с ПО «zVirt Max» Host в Менеджере управления и переустановите его, Портал администрирования может ошибочно отобразить его статус как Не удалось установить (Install Failed). Нажмите Управление (Management) → Активировать (Activate), затем статус хоста поменяется на Включен (Up) и он будет готов к использованию.

После переустановки узлов с ролью hosted engine можно проверить статус новой среды, выполнив следующую команду на одном из узлов:

hosted-engine --vm-status

Во время восстановления старый домен хранения hosted engine был переименован, но не удален из новой среды на случай, если восстановление было выполнено с ошибкой. Убедившись, что среда работает нормально, можно удалить старый домен хранения hosted engine.

Удаление домена хранения

В центре данных есть домен хранения, который вы хотите удалить из среды виртуализации.

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Переведите домен хранения в режим обслуживания и отключите его:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Обслуживание (Maintenance), а затем OK.
- Нажмите Отсоединить (Detach), а затем OK.
Нажмите Удалить (Remove).
При желании установите флажок Форматирование домена, т.е. содержимое хранилища будет потеряно! (Format Domain, i.e. Storage Content will be lost!), чтобы стереть содержимое домена.
Нажмите OK.

Домен хранения навсегда удален из среды.

3.2.1.9. Восстановление hosted engine из существующей резервной копии

Если hosted engine недоступен из-за неустранимых проблем, то можно восстановить его в новой среде, используя резервную копию, сделанную до появления проблемы (если таковая копия имеется).

Когда вы указываете файл резервной копии во время развертывания, резервная копия восстанавливается на новой виртуальной машине с Менеджером управления с новым доменом хранения hosted engine. Старый Менеджер управления удаляется, а старый домен хранения hosted engine переименовывается, и его можно удалить вручную после, убедившись, что новая среда работает корректно. Настоятельно рекомендуется развертывание на новом хосте; если хост, используемый для развертывания, существовал в среде, с которой была сделана резервная копия, то он будет удален из восстановленной базы данных, чтобы избежать конфликтов в новой среде. При развертывании на новом хосте необходимо присвоить хосту уникальное имя. Повторное использование имени существующего хоста, включенного в резервную копию, может привести к конфликтам в новой среде.

Восстановление hosted engine включает в себя следующие основные действия:

Развертывание нового hosted engine и восстановление из резервной копии.
Включение репозиториев Менеджера управления на новой виртуальной машине с Менеджером управления.
Переустановка узлов с ролью hosted engine для обновления их конфигураций.
Удаление старого домена хранения hosted engine.

Для этой процедуры предполагается, что нет доступа к исходному Менеджеру управления, а новый хост может получить доступ к файлу резервной копии.

Предварительные условия

FQDN готово для Менеджера управления и хоста. В DNS должны быть установлены записи прямого и обратного просмотра. FQDN нового Менеджера управления должно совпадать с FQDN исходного Менеджера управления.

Восстановление из резервной копии на новом hosted engine

При повторном развертывании на существующем хосте необходимо обновить настройки инициатора iSCSI хоста в /etc/iscsi/initiatorname.iscsi. IQN инициатора должен быть таким же, как и сопоставленный ранее с iSCSI-таргетом, либо обновленным до нового IQN, если применимо.
При развертывании на новом хосте обновите конфигурацию iSCSI-таргета, чтобы принимать подключения с этого хоста.

Процедура

Скопируйте файл резервной копии на новый хост. В следующем примере host.example.com – это FQDN хоста, а /backup/ – любая указанная папка или путь.
```
scp -p  _file_name_  host.example.com:/backup/
```
Авторизуйтесь на новом хосте.
В случае развертывания на ПО «zVirt Max» Host пакет ovirt-hosted-engine-setup уже установлен, поэтому пропустите этот шаг. В случае развертывания на Red Hat Enterprise Linux установите пакет ovirt-hosted-engine-setup:
```
dnf install ovirt-hosted-engine-setup
```
Для запуска скрипта используйте менеджер окон tmux, чтобы избежать потери сеанса в случае нарушения работы сети или терминала. Установите и запустите tmux:
```
dnf -y install tmux
tmux
```
Запустите скрипт hosted-engine, указав путь к файлу резервной копии:
```
hosted-engine --deploy --restore-from-file=backup/ _file_name_
```
Чтобы в любой момент выйти из скрипта и прервать развертывание, нажмите CTRL+D.

Чтобы начать развертывание, нажмите Да (Yes).
Настройте сеть. Скрипт обнаруживает возможные сетевые карты для использования в качестве моста управления для среды.
Если нужно использовать пользовательское виртуальное устройство для установки виртуальной машины, введите путь к архиву OVA. Либо оставьте это поле пустым.
Введите root-пароль для Менеджера управления.
Введите открытый ключ SSH, который позволит авторизоваться в Менеджере управления в качестве root-пользователя, и укажите, следует ли разрешить root-пользователю доступ по SSH.
Введите конфигурацию ЦП и памяти виртуальной машины.
Введите MAC-адрес виртуальной машины с Менеджером управления или примите случайно сгенерированный адрес. Если нужно предоставить виртуальной машине с Менеджером управления IP-адрес через DHCP, убедитесь, что у вас есть действительное резервирование DHCP для этого MAC-адреса.

Укажите, нужно ли добавлять записи для виртуальной машины с Менеджером управления и базового хоста в файл /etc/hosts виртуальной машины. Убедитесь, что имена хостов разрешимы.
Укажите имя и номер TCP-порта SMTP-сервера, адрес электронной почты, используемый для отправки уведомлений, и через запятую список адресов электронной почты, используемых для получения этих уведомлений:

Введите пароль пользователя admin@internal для доступа к Порталу администрирования.

[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса позволяет:

Подключиться к Порталу администрирования, используя предоставленный URL-адрес.
Оценить ситуацию, выяснить, почему хост не работает, и внести необходимые исправления. Например, если развернутая система была восстановлена из резервной копии и эта резервная копия включала в себя обязательные сети (required networks) для кластера хоста, то настройте сети, подключив к ним соответствующие сетевые карты хоста.
Если все выглядит как положено и хост имеет статус Включен (Up), удалите файл блокировки, показанный в сообщении выше. Развертывание продолжается.

Выберите используемый тип хранилища:

Для NFS введите версию, полный адрес и путь к хранилищу, а также любые параметры монтирования.

Для Fibre Channel выберите LUN из списка автоматически обнаруженных устройств. Адаптеры шины хоста должны быть настроены и подключены, а на LUN не должно быть никаких данных. Информацию о том, как повторно использовать существующий LUN, см. в разделе Повторное использование LUN в Руководстве пользователя.

Укажите размер диска Менеджера управления.
- Скрипт продолжит работу до тех пор, пока развертывание не будет завершено.
Процесс развертывания изменяет SSH-ключи Менеджера управления. Чтобы клиентские машины смогли обращаться к новому Менеджеру управления без ошибок SSH, удалите запись исходного Менеджера управления из файла .ssh/known_hosts на всех клиентских машинах, которые обращались к исходному Менеджеру управления.

Переустановка хостов

Предварительные условия

Если в кластере включена миграция, то виртуальные машины могут автоматически мигрировать на другой хост в кластере. Поэтому переустанавливайте хост, пока уровень его использования относительно невысок.
Убедитесь, что в кластере достаточно памяти для его хостов для выполнения обслуживания. Если в кластере недостаточно памяти, то миграция виртуальных машин зависнет, а затем завершится сбоем. Прежде чем переводить хост в режим обслуживания, выключите некоторые или все виртуальные машины, чтобы уменьшить использование ресурсов памяти.
Перед выполнением переустановки убедитесь, что кластер содержит более одного хоста. Не пытайтесь переустановить все хосты одновременно. Один хост должен оставаться доступным для выполнения задач Менеджера пула хранения (SPM).

Процедура

Нажмите Ресурсы (Compute) → Хосты (Hosts) и выберите хост.
Нажмите Управление (Management) → Обслуживание (Maintenance) и OK.
Нажмите Установка (Installation) → Переустановить (Reinstall). Откроется окно Установить хост (Install Host).
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
Нажмите OK, чтобы переустановить хост.

hosted-engine --vm-status

Во время восстановления старый домен хранения hosted engine был переименован, но не был удален из новой среды на случай, если восстановление было выполнено с ошибкой. Убедившись, что среда работает нормально, можно удалить старый домен хранения hosted engine.

Удаление домена хранения

В центре данных есть домен хранения, который вы хотите удалить из среды виртуализации.

Процедура

Нажмите Хранилище (Storage) → Домены (Domains).
Переведите домен хранения в режим обслуживания и отключите его:
- Нажмите на имя домена хранения. Откроется подробное представление.
- Откройте вкладку Центр данных (Data Center).
- Нажмите Обслуживание (Maintenance), а затем OK.
- Нажмите Отсоединить (Detach), а затем OK.
Нажмите Удалить (Remove).
При желании установите флажок Форматирование домена, т.е. содержимое хранилища будет потеряно! (Format Domain, i.e. Storage Content will be lost!), чтобы стереть содержимое домена.
Нажмите OK.

Домен хранения будет навсегда удален из среды.

3.2.1.10. Перезапись hosted engine из существующей резервной копии

Если hosted engine доступен, но на нем возникли проблемы (например, повреждение базы данных или ошибка конфигурации), которые трудно откатить, то можно восстановить среду до предшествующего состояния с помощью резервной копии, сделанной до возникновения проблемы, если такая копия имеется.

Восстановление hosted engine до предшествующего состояния включает в себя следующие шаги:

Переключение среды в глобальный режим обслуживания.
Восстановление резервной копии на виртуальной машине с Менеджером управления.
Отключение глобального режима обслуживания.

Дополнительные сведения об опциях engine-backup --mode=restore см. в Разделе 3.2.1. Резервное копирование и восстановление Менеджера управления.

Включение глобального режима обслуживания

Перед выполнением каких-либо задач по настройке или обновлению на виртуальной машине с Менеджером управления переведите среду hosted engine в глобальный режим обслуживания.

Процедура

Авторизуйтесь на одном из узлов с ролью hosted engine и включите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=global
```
Прежде чем продолжить, убедитесь, что среда находится в глобальном режиме обслуживания.
```
hosted-engine --vm-status
```
Должно отобразиться сообщение о том, что кластер находится в глобальном режиме обслуживания.

Восстановление резервной копии с перезаписью существующей установки

С помощью команды engine-backup можно восстановить резервную копию на машину, на которой уже установлен и настроен Менеджер управления. Данный функционал используется, когда вы сделали резервную копию среды, внесли в неё изменения, а затем хотите отменить изменения, восстановив среду из резервной копии.

Изменения, внесённые в среду после создания резервной копии, такие как добавление или удаление хостов, не будут присутствовать в восстановленной среде. Эти изменения потребуется внести повторно.

Процедура

Авторизуйтесь на Менеджере управления.
Удалите файлы конфигурации и очистите базу данных, ассоциированную с Менеджером управления:
```
engine-cleanup
```
С помощью команды engine-cleanup можно очистить только базу данных Менеджера управления; она не сбрасывает базу данных и не удаляет пользователя, владеющего этой базой данных.

Восстановление из полной резервной копии или резервной копии только базы данных. Вам не нужно создавать новую базу данных или указывать учетные данные базы данных, так как пользователь и база данных уже существуют.
- Восстановление из полной резервной копии:
  engine-backup --mode=restore --file=_file_name_ --log=_log_file_name_ --restore-permissions
- Восстановление из резервной копии только базы данных через восстановление файлов конфигурации и резервной копии базы данных:
  engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --restore-permissions

В случае положительного результата на экране появится следующее сообщение:

You should now run engine-setup.

Done.

Переконфигурируйте Менеджер управления:
```
engine-setup
```

Отключение режима глобального обслуживания

Процедура

Авторизуйтесь на виртуальной машине с Менеджером управления и выключите её.
Авторизуйтесь на одном из узлов hosted engine и отключите глобальный режим обслуживания:
```
hosted-engine --set-maintenance --mode=none
```
При выходе из глобального режима обслуживания ovirt-ha-agent запускает виртуальную машину c Менеджером управления, после чего автоматически запускается Менеджер управления. На запуск Менеджера управления может потребоваться до 10 минут.

Убедитесь, что среда работает:

hosted-engine --vm-status

Перечисленная информация включает в себя Статус engine (Engine Status). Значение параметра Статус engine (Engine Status) должно быть:

 { "health": "good", "vm": "up", "detail": "Up"}

Если виртуальная машина все еще загружается и Менеджер управления еще не запустился, значение параметра Статус engine (Engine status) должно быть:

{ "reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

В таком случае подождите несколько минут и попробуйте снова.

Когда среда снова заработает, можно запустить все виртуальные машины, которые были остановлены, и проверить, что ресурсы среды работают по плану.

3.2.2. Перенос Хранилища (DWH) на отдельную машину

В этом разделе описано, как перенести базу данных и службу Хранилища (DWH) с машины с Менеджером управления на отдельную машину. Размещение службы Хранилища (DWH) на отдельной машине снижает нагрузку на каждую отдельную машину и позволяет избежать потенциальных конфликтов, связанным с тем, что ресурсы ЦП и памяти приходится делить с другими процессами.

Доступны следующие варианты миграции:

Можно перенести службу Хранилища (DWH) с машины с Менеджером управления и подключить ее к существующей базе данных Хранилища (DWH) (ovirt_engine_history).
Можно перенести базу данных Хранилища (DWH) с машины с Менеджером управления, а затем перенести службу Хранилища (DWH).

Перенесите базу данных Хранилища (DWH) (ovirt_engine_history) до переноса службы Хранилища (DWH). Используйте engine-backup для создания резервной копии базы данных и ее восстановления на новой машине с базой данных. Дополнительные сведения о engine-backup см. с помощью команды engine-backup --help.

Процедура

Создайте резервную копию базы данных и файлов конфигурации Хранилища (DWH) в Менеджере управления:
```
engine-backup --mode=backup --scope=dwhdb --scope=files --file=_file_name_ --log=_log_file_name_
```
Скопируйте файл резервной копии из Менеджера управления на новую машину.
```
scp _/tmp/file_name_ _root@new.dwh.server.com:/tmp_
```
Установите engine-backup на новой машине:
```
dnf install ovirt-engine-tools-backup
```
Установите серверный пакет:
```
dnf install postgresql-server postgresql-contrib
```
Инициализируйте базу данных, запустите службу и убедитесь, что она стартует при загрузке:
```
su - postgres -c 'initdb'
systemctl enable postgresql
systemctl start postgresql
```
Восстановите базу данных Хранилища (DWH) на новой машине. file _ name – это файл резервной копии, скопированный из Менеджера управления.
```
engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --provision-dwh-db --restore-permissions
```

Теперь база данных Хранилища (DWH) и Менеджер управления размещаются на разных машинах. После успешного восстановления базы данных Хранилища (DWH) система предложит выполнить команду engine-setup. Перед выполнением этой команды перенесите службу Хранилища (DWH).

3.2.2.1. Перенос службы Хранилища (DWH) на отдельную машину

Службу Хранилища (DWH), установленную и настроенную в Менеджере управления, можно перенести на отдельную машину. Размещение службы Хранилища (DWH) на отдельной машине помогает снизить нагрузку на машину с Менеджером управления.

Обратите внимание, что эта процедура переносит только службу Хранилища (DWH).

Информацию о том, как перенести базу данных Хранилища (DWH) (ovirt_engine_history) перед переносом службы Хранилища (DWH), см. в разделе 3.2.2.1. Перенос базы данных Хранилища (DWH) на отдельную машину.

Предварительные условия

На одной машине должны быть установлены и настроены Менеджер управления и Хранилище (DWH).
Чтобы настроить новую машину с Хранилищем (DWH), нужно иметь:
- Пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup-database.conf Менеджера управления.
- Разрешенный доступ с машины с Хранилищем (DWH) к TCP-порту 5432 машины с базой данных Менеджера управления.
- Имя пользователя и пароль для базы данных Хранилища (DWH) из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf Менеджера управления.

Если перенос базы данных ovirt _ engine _ history выполнялся с использованием процедур, описанных в разделе 3.2.2.1. Перенос базы данных Хранилища (DWH) на отдельную машину, то резервная копия включает в себя эти учетные данные, заданные во время настройки базы данных на этой машине.

Для установки этого сценария выполните 4 шага:

Установка новой машины со службой Хранилища (DWH).
Остановка службы Хранилища (DWH) на машине с Менеджером управления.
Настройка новой машины со службой Хранилища (DWH).
Отключение пакета Хранилища (DWH) на машине с Менеджером управления.

Установка новой машины со службой Хранилища (DWH)

Включите репозитории ПО «zVirt Max» и установите пакет настроек Хранилища (DWH) на машину с Red OS:

Убедитесь в актуальности всех установленных пакетов:
```
dnf upgrade --nobest
```
Установите пакет ovirt-engine-dwh-setup:
```
dnf install ovirt-engine-dwh-setup
```
===== Остановка службы Хранилища (DWH) на машине с Менеджером управления

Процедура

Остановите службу Хранилища (DWH):
```
systemctl stop ovirt-engine-dwhd.service
```
Если база данных размещена на удаленной машине, предоставьте доступ вручную, изменив файл postgres.conf. Измените файл /var/lib/pgsql/data/postgresql.conf и скорректируйте строку listen _ addresses, чтобы она выглядела так:
```
listen _ addresses = ' * '
```
Если этой строки нет или она закомментирована, то добавьте ее вручную. Если база данных размещена на машине с Менеджером управления и была настроена во время чистой установки Менеджера управления, то доступ предоставляется по умолчанию.
Перезапустите службу:
```
systemctl restart postgresql
```

Настройка новой машины со службой Хранилища (DWH)

Порядок опций или настроек, описанных в этом разделе, может отличаться в зависимости от вашей среды.

В случае переноса базы данных ovirt_engine_history и службы Хранилища (DWH) на одну и ту же машину выполните перечисленные ниже действия, в противном случае перейдите к следующему шагу.
```
sed -i '/^ENGINE_DB_/d' \
        /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf

sed -i \
     -e 's;^$OVESETUP_ENGINE_CORE/enable=bool$:True;\1:False;' \
     -e '/^OVESETUP_CONFIG\/fqdn/d' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
```
Выполните команду engine-setup, чтобы начать настройку Хранилища (DWH) на машине:
```
engine-setup
```
Нажмите Ввод (Enter), чтобы принять автоматически обнаруженное имя хоста, либо введите альтернативное имя хоста и нажмите Ввод (Enter): Host fully qualified DNS name of this server [_ autodetected host name _] :
Нажмите Ввод (Enter), чтобы автоматически настроить межсетевой экран, либо напечатайте Нет (No) и нажмите Ввод (Enter), чтобы сохранить текущие настройки:
```
Setup can automatically configure the firewall on this system.
Note: automatic configuration of the firewall may overwrite current settings.
Do you want Setup to configure the firewall? (Yes, No) [Yes]:
```
Если будет выбрана автоматическая настройка межсетевого экрана и ни один менеджер межсетевого экрана не активен, то система предложит выбрать предпочтительный менеджер межсетевого экрана из списка поддерживаемых вариантов. Напечатайте имя менеджера межсетевого экрана и нажмите Ввод (Enter). Это применимо, даже если список содержит всего один элемент.

Введите FQDN и пароль для Менеджера управления. Нажмите Ввод (Enter), чтобы принять значения по умолчанию в каждом из остальных полей:

Host fully qualified DNS name of the engine server []: _engine-fqdn_
Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
Please choose one of the following:
1 - Access remote engine server using ssh as root
2 - Perform each action manually, use files to copy content around
(1, 2) [1]:
ssh port on remote engine server [22]:
root password on remote engine server _engine-fqdn_: _password_

Введите FQDN и пароль для машины с базой данных Менеджера управления. Нажмите Ввод (Enter), чтобы принять значения по умолчанию в каждом из остальных полей:
```
Engine database host []: _manager-db-fqdn_
Engine database port [5432]:
Engine database secured connection (Yes, No) [No]:
Engine database name [engine]:
Engine database user [engine]:
Engine database password: _password_
```
Подтвердите настройки, с которыми будет выполняться установка:
```
Please confirm installation settings (btn:[OK], Cancel)  [ btn:[OK] ] :
```

Теперь служба Хранилища (DWH) настроена на удаленной машине. Далее отключите службу Хранилища (DWH) на машине с Менеджером управления.

Отключение службы Хранилища (DWH) на машине с Менеджером управления

Процедура

Перезапустите Менеджер управления на машине с Менеджером управления:
```
service ovirt-engine restart
```

Выполните следующую команду, чтобы изменить файл /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf и установить параметры в значение False:

sed -i \
     -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
     -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

sed -i \
     -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Отключите службу Хранилища (DWH):
```
systemctl disable ovirt-engine-dwhd.service
```
Удалите файлы Хранилища (DWH):
```
rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/* .conf /var/lib/ovirt-engine-dwh/backups/*
```
Теперь служба Хранилища (DWH) и Менеджер управления размещаются на разных машинах.

3.2.3. Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения (Backup Storage Domain)

3.2.3.1. Описание Резервного домена хранения

Резервный домен хранения – это домен, который можно использовать специально для хранения и миграции виртуальных машин и шаблонов виртуальных машин с целью резервного копирования и восстановления в случае аварии, миграции и т.д.

Резервный домен отличается от не резервного тем, что все виртуальные машины в нем находятся в выключенном состоянии. Виртуальная машина не может работать в резервном домене.

Любой домен хранения данных можно задать в качестве резервного домена. Чтобы включить/выключите эту настройку, установите/снимите флажок в диалоговом окне "Управление доменом (Manage Domain)". Эту настройку можно включить только после остановки всех виртуальных машин в этом домене хранения.

Невозможно запустить виртуальную машину, хранящуюся в резервном домене. Менеджер управления блокирует эту и любую другую операцию, которая может сделать резервную копию недействительной. Однако можно запустить виртуальную машину на основе шаблона, хранящегося в резервном домене, если диски этой виртуальной машины не являются частью резервного домена.

Как и в случае с другими типами доменов хранения, резервные домены можно подключать к центру данных и отключать от него. Таким образом, помимо хранения резервных копий, резервные домены можно использовать для переноса виртуальных машин между центрами данных.

Преимущества

Вот несколько причин использовать резервный домен, а не домен экспорта:

В центре данных, может быть, несколько резервных доменов хранения, но лишь один домен экспорта.
Можно выделить резервный домен хранения для резервного копирования и аварийного восстановления.
Можно перенести резервную копию виртуальной машины, шаблона или моментального снимка в резервный домен хранения.
С резервными доменами миграция большого количества виртуальных машин, шаблонов или файлов OVF выполняется значительно быстрее, чем с доменами экспорта.
Резервный домен использует дисковое пространство эффективнее, чем домен экспорта.
Резервные домены поддерживают как файловое хранилище (NFS), так и блочное (Fiber Channel и iSCSI) – в отличие от доменов экспорта, поддерживающих только файловое.
Настройку "резервный" для домена хранения можно динамически включать и выключать с учетом ограничений.

Ограничения

У любой виртуальной машины или шаблона в резервном домене ( _ backup) все диски должны быть в этом же домене.
Все виртуальные машины в домене хранения должны быть выключены, прежде чем его можно будет сделать резервным доменом.
Невозможно запустить виртуальную машину, хранящуюся в резервном домене, потому что это может привести к изменению данных на диске.
Резервный домен не может быть целевым доменом томов памяти (memory volumes), поскольку тома памяти поддерживаются только для активных виртуальных машин.
Предварительный просмотр виртуальной машины в резервном домене невозможен.
Перенос виртуальной машины "на лету" в резервный домен невозможен.
Невозможно задать резервный домен в качестве мастер-домена.
Невозможно задать домен hosted engine в качестве резервного домена.
Не используйте домен хранения по умолчанию в качестве резервного домена.

3.2.3.2. Установка домена хранения данных в качестве резервного домена

Предварительные условия

Все диски, принадлежащие виртуальной машине или шаблону в домене хранения, должны находиться в одном и том же домене.
Все виртуальные машины в домене должны быть выключены.

Процедура

На Портале администрирования нажмите Хранилище (Storage) → Домены (Domains).
Создайте новый домен хранения или выберите существующий домен хранения и нажмите Управление доменом (Manage Domain). Откроется диалоговое окно Управление доменами (Manage Domains).
В блоке Расширенные параметры (Advanced Parameters) установите флажок Резервный (Backup).

Теперь домен стал резервным доменом.

3.2.3.3. Резервное копирование или восстановление виртуальной машины или моментального снимка с использованием резервного домена

Можно выполнить резервное копирование выключенной виртуальной машины или моментального снимка. Затем можно сохранить резервную копию в том же центре данных и восстановиться с нее при необходимости либо перенести ее в другой центр данных.

Процедура: Резервное копирование виртуальной машины

Создайте резервный домен. См. Раздел 3.2.3.2. Установка домена хранения данных в качестве резервного домена.
Создайте новую виртуальную машину на базе виртуальной машины, резервную копию которой вы хотите сделать:
- Чтобы сделать резервную копию моментального снимка, сначала создайте из него виртуальную машину. См. раздел Создание виртуальной машины из шаблона в Руководстве пользователя.
- Чтобы сделать резервную копию виртуальной машины, сначала клонируйте ее. См. раздел Клонирование виртуальной машины в Руководстве пользователя.
Экспортируйте новую виртуальную машину в резервный домен. См. раздел Экспорт виртуальной машины в домен данных в Руководстве пользователя.

Процедура: Восстановление виртуальной машины

Убедитесь, что резервный домен хранения, в котором хранится резервная копия виртуальной машины, подключен к центру данных.
Импортируйте виртуальную машину из резервного домена. См. Импортирование виртуальных машин из домена данных.

Сопутствующая информация

Раздел 2.6.8.2. Импортирование доменов хранения.
Раздел 2.6.8.3. Перенос доменов хранения между центрами данных в одной среде.
Раздел 2.6.8.4. Перенос доменов хранения между центрами данных в разных средах.

3.2.4. Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления

3.2.4.1. API резервного копирования и восстановления

API резервного копирования и восстановления – это набор функций, которые позволяют выполнять полное или пофайловое резервное копирование и восстановление виртуальных машин. API сочетает в себе ряд компонентов ПО «zVirt Max» (таких как создаваемые на лету моментальные снимки и REST API) для создания и использования временных томов, которые можно подключить к виртуальной машине, содержащей ПО резервного копирования, предоставленное независимым поставщиком ПО.

3.2.4.2. Резервное копирование виртуальной машины

Используйте API резервного копирования и восстановления для создания резервной копии виртуальной машины. Эта процедура предполагает, что у вас есть две виртуальные машины: виртуальная машина, с которой нужно сделать резервную копию, и виртуальная машина, на которой установлено ПО для управления резервным копированием.

Процедура

Используя REST API, создайте моментальный снимок виртуальной машины, резервную копию которой нужно сделать:

POST /api/vms/`_{vm:id}_`/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<snapshot>
    <description>BACKUP</description>
</snapshot>

Замените здесь { vm:id} идентификатором виртуальной машины, моментальный снимок которой вы делаете. Этот идентификатор можно посмотреть на вкладке Общие (General) окон Создать виртуальную машину (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine) на Портале администрирования и Пользовательским портале.
При создании моментального снимка виртуальной машины данные ее текущей конфигурации помещаются в атрибут data атрибута configuration блока initialization, расположенного под моментальным снимком.

Невозможно делать моментальные снимки дисков, помеченных как общие или основанных на дисках Прямой LUN.

Получите данные конфигурации виртуальной машины из атрибута data, расположенного под моментальным снимком:

GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1
All-Content: true
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.
Добавьте заголовок All-Content: true, чтобы получить дополнительные данные OVF в ответе. Данные OVF в XML-ответе находятся в элементе конфигурации виртуальной машины < initialization >< configuration >. Позже вы будете использовать эти данные для восстановления виртуальной машины.

Получите идентификатор моментального снимка:

GET /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

Определите соответствующий моментальному снимку идентификатор диска:
```
GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_`/disks HTTP/1.1
Accept: application/xml
Content-type: application/xml
```

Подключите к резервной виртуальной машине моментальный снимок как активный диск, используя корректный тип интерфейса (например, virtio _ scsi):

POST /api/vms/`_{vm:id}_`/diskattachments/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk_attachment>
	<active>true</active>
	<interface>_virtio_scsi_</interface>
	<disk id="_{disk:id}_">
	<snapshot id="_{snapshot:id}_"/>
	</disk>
</disk_attachment>

Замените параметр {vm:id} идентификатором резервной виртуальной машины, а не той виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {disk:id} идентификатором диска.
Замените { snapshot:id} идентификатором моментального снимка.

Используйте ПО резервного копирования на резервной виртуальной машине для резервного копирования данных на моментальный снимок, подключенный как диск.

Отключите моментальный снимок, подключенный как диск, от резервной виртуальной машины:

DELETE /api/vms/`_{vm:id}_`/diskattachments/`_{snapshot:id}_` HTTP/1.1
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором резервной виртуальной машины, а не той виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.

При желании удалите моментальный снимок:

DELETE /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1
Accept: application/xml
Content-type: application/xml

Замените параметр {vm:id} идентификатором виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {snapshot:id} идентификатором моментального снимка.

Вы создали резервную копию состояния виртуальной машины в фиксированный момент времени с помощью ПО резервного копирования, установленного на отдельной виртуальной машине.

3.2.4.3. Восстановление виртуальной машины

Чтобы восстановить виртуальную машину, для которой была создана резервная копия, используйте API резервного копирования и восстановления. Эта процедура предполагает, что у вас есть резервная виртуальная машина, на которой установлено ПО, управлявшее предыдущей резервной копией.

Процедура

На Портале администрирования создайте плавающий диск, на который нужно восстановить ВМ из резервной копии. Подробную информацию о порядке создания плавающего диска см. в Разделе 2.8.6.1. Создание виртуального диска.

Подключите диск к резервной виртуальной машине:

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="_{disk:id}_">
</disk>

Замените параметр {vm:id} на идентификатор (ID) этой резервной виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените параметр {disk:id} на идентификатор диска, который вы получили во время резервного копирования виртуальной машины.

Чтобы восстановить виртуальную машину из резервной копии на диск, используйте программу резервного копирования.

Отключите диск от резервной виртуальной машины:

DELETE /api/vms/`_{vm:id}_`/disks/_{disk:id}_ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <detach>true</detach>
</action>

Замените параметр {vm:id} на идентификатор (ID) этой резервной виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените параметр {disk:id} на идентификатор диска.

Создайте новую виртуальную машину, используя данные конфигурации восстанавливаемой виртуальной машины:

POST /api/vms/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<vm>
    <cluster>
        <name>cluster_name</name>
    </cluster>
    <name>_NAME_</name>
      <initialization>
      <configuration>
  <data>
  <!-- omitting long ovf data -->
  </data>
      <type>ovf</type>
      </configuration>
      </initialization>
    ...
</vm>

Чтобы при создании виртуальной машины переопределить любое из значений в ovf, переопределите элемент до или после элемента initialization.

Подключите диск к новой виртуальной машине:

POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="_{disk:id}_">
</disk>

Замените параметр `{vm:id} `на идентификатор новой виртуальной машины, а не виртуальной машины, моментальный снимок которой вы сделали ранее.
Замените {disk:id} на идентификатор диска.

Вы восстановили виртуальную машину из резервной копии, созданной с помощью API резервного копирования и восстановления.

3.2.5. Резервное копирование и восстановление виртуальных машин с помощью API инкрементного резервного копирования и восстановления

ПО «zVirt Max» предоставляет API инкрементного резервного копирования, который можно использовать для создания полных резервных копий виртуальных дисков форматов QCOW2 или RAW или инкрементных резервных копий виртуальных дисков формата QCOW2 без создания каких-либо временных моментальных снимков.

Резервные копии данных создаются в формате RAW независимо от того, в каком формате созданы резервные копии виртуального диска - QCOW2 или RAW. Можно восстанавливать гостевые данные формата RAW и диски формата RAW или QCOW2. API инкрементного резервного копирования входит в состав ПО «zVirt Max» REST API. Можно создавать резервные копии как работающих, так и неработающих виртуальных машин.

Особенности

Резервное копирование выполняется проще, быстрее и надежнее, чем при использовании API резервного копирования и восстановления. API инкрементного резервного копирования обеспечивает улучшенную интеграцию с приложениями резервного копирования; в него добавлена поддержка резервного копирования и восстановления гостевых данных формата RAW независимо от формата базового диска.

Если некорректная карта битов вызывает сбой резервного копирования, то можно удалить конкретную контрольную точку в цепочке резервного копирования. Запускать полное резервное копирование не нужно.

Ограничения:

Инкрементное резервное копирование можно выполнять только для дисков формата QCOW2, а не RAW. В процессе резервного копирования резервные копии данных сохраняются в формате RAW.
Данные можно восстановить только из резервных копий формата RAW.
Инкрементное восстановление не поддерживает восстановление моментальных снимков, существовавших на момент резервного копирования. При инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в моментальных снимках, существовавших на момент резервного копирования. Это ограничение обычно присутствует в решениях резервного копирования для других систем.
Обычно в решениях резервного копирования при инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в моментальных снимках, существовавших на момент резервного копирования.
Некорректное завершение работы виртуальной машины по любой причине может испортить карты битов на диске, что повредит всю цепочку резервного копирования. Восстановление из инкрементной резервной копии с помощью некорректной карты битов приведет к повреждению данных виртуальной машины.

Некорректную карту битов можно обнаружить только при запуске резервного копирования. Если на диске есть какие-либо поврежденные карты битов, то операция завершится ошибкой.

В таблице описаны конфигурации дисков, поддерживающие инкрементное резервное копирование.

При создании диска с помощью Портала администрирования вы задаете тип хранилища, тип предоставления дискового пространства, а также указываете, включено или отключено инкрементное резервное копирование. На основе этих настроек Менеджер управления определяет формат виртуального диска.

Таблица 71. Поддерживаемые конфигурации дисков для инкрементного резервного копирования
Тип хранилища	Тип предоставления дискового пространства	Когда инкрементное резервное копирование	Виртуальный диск имеет формат
блочное	динамическое	включено	qcow2
блочное	предварительно выделенное	включено	qcow2 (предварительно выделенное)
файловое	динамическое	включено	qcow2
файловое	предварительно выделенное	включено	qcow2 (предварительно выделенное)
блочное	динамическое	отключено	qcow2
блочное	предварительно выделенное	отключено	raw (предварительно выделенное)
файловое	динамическое	отключено	raw (динамически расширяемое)
файловое	предварительно выделенное	отключено	raw (предварительно выделенное)
сеть	Не применимо	отключено	raw
lun	Не применимо	отключено	raw

3.2.5.1. Процесс инкрементного резервного копирования

Для резервного копирования дисков виртуальных машин, для которых уже включено инкрементное резервное копирование, приложение резервного копирования, использующее API инкрементного резервного копирования, должно соблюдать следующую последовательность:

Приложение резервного копирования использует REST API для поиска дисков виртуальной машины, которые нужно добавить в резервную копию. Добавляются только диски формата QCOW2.
Приложение резервного копирования запускает полное резервное копирование или инкрементное резервное копирование. Вызов API указывает идентификатор виртуальной машины, необязательный идентификатор (ID) предыдущей контрольной точки и список дисков для резервного копирования. Если в вызове API не указан идентификатор предыдущей контрольной точки, то начинается полное резервное копирование, охватывающее все данные на указанных дисках, исходя из текущего состояния каждого диска.
Engine подготавливает виртуальную машину к резервному копированию. Во время резервного копирования виртуальная машина может продолжать работать.
Приложение резервного копирования запрашивает у engine статус резервного копирования до тех пор, пока engine не сообщит о готовности начать резервное копирование.
При готовности начать резервное копирование приложение резервного копирования создаст объект 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.
Поиск дисков, для которых включено инкрементное резервное копирование.
Запуск полного резервного копирования.
Запуск инкрементного резервного копирования.
Завершение резервного копирования.
Получение информации о резервной копии.
Получение информации о дисках в резервной копии.
Составление списка всех контрольных точек для виртуальной машины.
Выдача информации по конкретной контрольной точке для виртуальной машины.
Удаление контрольной точки конкретной виртуальной машины.
Загрузка объекта imagetransfer для архивирования резервной копии.
Выгрузка объекта imagetransfer для восстановления из резервной копии.
Составление списка измененных блоков.
Загрузка и выгрузка измененных блоков.

Включение инкрементного резервного копирования на новом виртуальном диске

Включите инкрементное резервное копирование для виртуального диска, чтобы пометить, что он входит в состав инкрементного резервного копирования. При добавлении диска можно включить инкрементное резервное копирование для каждого диска либо с помощью REST API, либо на Портале администрирования. Создавать резервные копии существующих дисков, для которых не включено инкрементное резервное копирование, можно с помощью полного резервного копирования или так, как вы делали раньше.

Менеджер управления может добавить диск в инкрементное резервное копирование, даже если оно не включено на диске, но его можно включить, чтобы отслеживать, на каких дисков оно включено.

Поскольку для инкрементного резервного копирования требуются диски в формате QCOW2, используйте QCOW2 вместо RAW.

Процедура

Добавьте новый виртуальный диск. Дополнительную информацию см. в разделе 2.8.6.1. Создание виртуального диска.
При настройке параметров диска установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).

Включение инкрементного резервного копирования на существующем виртуальном диске формата RAW

Поскольку инкрементное резервное копирование не поддерживается для дисков в формате RAW, для его использования на всех дисках формата RAW поверх должен существовать слой формата QCOW2. При создании моментального снимка создается слой QCOW2, делающий возможным инкрементное резервное копирование на все диски, включенные в моментальный снимок, с точки, в которой создается моментальный снимок.

Если на базовом слое диска используется формат RAW, то удаление последнего моментального снимка и объединение верхнего слоя QCOW2 с базовым слоем преобразует диск в формат RAW, тем самым отключая инкрементное резервное копирование, если оно было установлено. Чтобы снова включить инкрементное резервное копирование, можно создать новый моментальный снимок, включающий в себя этот диск.

Процедура

На Портале администрирования нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Выберите виртуальную машину и откройте вкладку Диски (Disks).
Нажмите Изменить (Edit). Откроется диалоговое окно Изменить диск (Edit Disk).
Установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).

Включение инкрементного резервного копирования

Вы можете использовать запрос по 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>

Поиск дисков, на которых включено инкрементное резервное копирование

Для указанной виртуальной машины можно вывести список дисков, на которых включено инкрементное резервное копирование, отфильтрованных по свойству резервного копирования.

Процедура

Выведите список дисков, подключенных к виртуальной машине. Например, для виртуальной машины с идентификатором 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>
```

Запуск полного резервного копирования

После полного резервного копирования можно использовать полученный идентификатор контрольной точки в качестве начальной точки для следующего инкрементного резервного копирования.

При резервном копировании работающей виртуальной машины процесс создает временный диск в том же домене хранения, в котором находится копируемый диск. Процесс резервного копирования создает этот диск, чтобы сделать возможной запись новых данных на работающую виртуальную машину во время резервного копирования. Этот временный диск можно увидеть на Портале администрирования во время резервного копирования. По завершении резервного копирования он автоматически удаляется.

Запуск полного резервного копирования требует вызова запроса с телом и включает в себя ответ.

Процедура

Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором 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) при следующем инкрементном резервном копировании.

Запуск инкрементного резервного копирования

После завершения полного резервного копирования данного виртуального диска последующие инкрементные резервные копии этого диска будут содержать только изменения, внесенные с момента последнего резервного копирования. Используйте значение идентификатора конечной контрольной точки (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) при следующем инкрементном резервном копировании.

Получение информации о резервной копии

Можно получить информацию о резервной копии, которую можно использовать для запуска нового инкрементного резервного копирования.

Метод 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 службы 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>

Завершение резервного копирования

При завершении резервного копирования оканчивается процесс резервного копирования, разблокируются ресурсы и производится очистка. Используйте служебный метод резервного копирования finalize.

Процедура

Чтобы завершить резервное копирование диска с идентификатором 456 на виртуальной машине с идентификатором 123, отправьте запрос следующего вида:

POST /vms/123/backups/456/finalize

Создание объекта 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 >

Создание объекта 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 >

Составление списка контрольных точек для виртуальной машины

Отправив запрос, можно получить список всех контрольных точек для виртуальной машины вместе с информацией о каждой контрольной точке.

Процедура

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 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>

Выдача информации о конкретной контрольной точке виртуальной машины

Можно получить информацию о конкретной контрольной точке виртуальной машины, отправив запрос.

Процедура

Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором 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>

Удаление контрольной точки

Можно удалить контрольную точку виртуальной машины, отправив запрос Удалить (DELETE). Можно удалить контрольную точку виртуальной машины, независимо от того, работает ли ВМ или нет.

Процедура

Отправьте запрос с указанием виртуальной машины и контрольной точки. Например, укажите виртуальную машину с идентификатором 123 и контрольную точку с идентификатором 456 как показано ниже:

DELETE /vms/123/checkpoints/456/

Использование API imageio для передачи данных резервного копирования

API imagetransfer запускает и останавливает передачу образов. В результате появится URL-адрес передачи.

Используйте API imageio для фактической передачи данных из URL-адреса передачи.

Таблица 72. Таблица Методы API imageio Image, используемые при инкрементном резервном копировании и восстановлении
Запрос API (API request)	Описание	Справочный раздел API imageio Image
OPTIONS /images/ { ticket-id} HTTP/1.1	Выводит параметры сервера, чтобы можно было узнать, какие функции поддерживает сервер.	См. ПАРАМЕТРЫ (OPTIONS)
GET /images/ { ticket-id}/extents	Выводит информацию о содержимом и выделении образа диска или о блоках, которые изменились во время инкрементного резервного копирования. Эта информация называется экстент (extent).	См. ЭКСТЕНТЫ (EXTENTS)
GET /images/ { ticket-id}/extent?context=dirty	Программа, выполняющая передачу образа, должна загрузить изменения из резервной копии. Эти изменения называются ожидающие записи экстенты (dirty extents). Чтобы загрузить изменения, отправьте следующий запрос:	См. ЭКСТЕНТЫ (EXTENTS)→ Примеры (Examples)→ Запрос ожидающих записи экстентов (Request dirty extents)
PUT /images/ { ticket-id}	Приложение резервного копирования создает новый диск или моментальный снимок существующего диска для хранения восстановленных данных.	См. PUT_

3.3. Пользователи и роли

3.3.1. Общая информация о пользователях

В ПО «zVirt Max» есть два типа пользовательских доменов: локальный и внешний. При установке Менеджера управления создаются локальный домен по умолчанию, называемый внутренним (internal) доменом, и пользователь по умолчанию – admin.

Во внутреннем (internal) домене можно создавать дополнительных пользователей с помощью программы ovirt-aaa-jdbc-tool. Учетные записи пользователей, созданные в локальных доменах, называются локальными пользователями.

Кроме того, к ПО «zVirt Max» можно подключить внешние серверы каталогов, такие как Red Hat Directory Server, Active Directory, OpenLDAP (и другие поддерживаемые варианты), и использовать их в качестве внешних доменов. Учетные записи пользователей, созданные во внешних доменах, называются пользователями из каталогов.

И локальным пользователям, и пользователям из каталогов нужно назначить соответствующие роли и разрешения через Портал администрирования, прежде чем они смогут работать в среде. Есть два основных типа ролей пользователей: конечный пользователь и администратор.

Роль конечного пользователя использует виртуальные ресурсы с Пользовательского портала и управляет ими. Роль администратора поддерживает инфраструктуру системы с помощью Портала администрирования. Роли могут назначаться пользователям применительно к отдельным ресурсам, таким как виртуальные машины и хосты, или применительно к иерархическим структурам объектов, таким как кластеры и центры данных.

3.3.1.1. Введение в серверы каталогов

Во время установки Менеджер управления создает пользователя admin во внутреннем (internal) домене. Этот пользователь также называется admin@internal. Эта учетная запись предназначена для использования при первоначальной настройке среды и устранении неполадок. После подключения внешнего сервера каталогов, добавления пользователей из каталогов и назначения им соответствующих ролей и разрешений пользователя admin@internal можно отключить, если он не нужен.

Поддерживаются следующие серверы каталогов:

389ds;
389ds RFC-2307 Schema;
Active Directory;
IBM Security Directory Server;
IBM Security Directory Server RFC-2307 Schema;
FreeIPA;
iDM;
Novell eDirectory RFC-2307 Schema;
OpenLDAP RFC-2307 Schema;
OpenLDAP Standard Schema;
Oracle Unified Directory RFC-2307 Schema;
RFC-2307 Schema (Generic);
Red Hat Directory Server (RHDS);
Red Hat Directory Server (RHDS) RFC-2307 Schema;
iPlanet;
РЕД АДМ.

Невозможно установить Менеджер управления (rhevm) и IdM (ipa-server) на одну систему. IdM несовместим с пакетом mod_ssl, который необходим Менеджеру управления.

Если в качестве сервера каталогов используется Active Directory и для создания шаблонов и виртуальных машин нужно использовать sysprep, то управление доменом необходимо делегировать пользователю c правами администратора ПО «zVirt Max», чтобы тот мог:

Подключить компьютер к домену.
Изменить членство группы.

3.3.2. Настройка внешнего провайдера LDAP

3.3.2.1. Настройка внешнего провайдера LDAP (интерактивная установка)

Расширение ovirt-engine-extension-aaa-ldap позволяет пользователям легко настраивать внешний каталог. Расширение ovirt-engine-extension-aaa-ldap поддерживает множество различных типов серверов LDAP, а для помощи в настройке большинства типов LDAP предоставляется интерактивный скрипт установки.

Если тип сервера LDAP не указан в интерактивном скрипте установки или нужна дополнительная настройка, можно вручную отредактировать файлы конфигурации. Дополнительную информацию см. в Разделе 3.3.3.3. Настройка внешнего провайдера LDAP (ручной метод).

Пример для Active Directory см. в Разделе 3.3.3.2. Подключение Active Directory.

Предварительные условия

Нужно знать доменное имя DNS- или LDAP-сервера.
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM.
Подготовьте хотя бы одну учетную запись (имя и пароль) для выполнения запросов на поиск и вход на LDAP-сервер.

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap-setup
```
Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:
```
ovirt-engine-extension-aaa-ldap-setup
```
Выберите тип LDAP, введя соответствующий номер. Если вы не знаете точно, какая схема у вашего LDAP-сервера, выберите стандартную схему для вашего типа LDAP-сервера. Для Active Directory выполните процедуру, описанную в Разделе 3.3.3.2. Подключение Active Directory.
```
Available LDAP implementations:

1 - 389ds
2 - 389ds RFC-2307 Schema
3 - Active Directory
4 - IBM Security Directory Server
5 - IBM Security Directory Server RFC-2307 Schema
6 - IPA
7 - Novell eDirectory RFC-2307 Schema
8 - OpenLDAP RFC-2307 Schema
9 - OpenLDAP Standard Schema
10 - Oracle Unified Directory RFC-2307 Schema
11 - RFC-2307 Schema (Generic)
12 - RHDS
13 - RHDS RFC-2307 Schema
14 - iPlanet

Please select:
```
Нажмите Ввод (Enter), чтобы принять значение по умолчанию и настроить разрешение доменного имени для имени LDAP-сервера:
```
It is highly recommended to use DNS resolution for LDAP server.
If for some reason you intend to use hosts or plain address disable DNS usage.
Use DNS (Yes, No) [Yes]:
```
Выберите метод политики DNS:
- Вариант 1: DNS-серверы, перечисленные в /etc/resolv.conf, используются для разрешения IP-адреса. Убедитесь, что файл /etc/resolv.conf актуализирован и содержит корректные DNS-серверы.
- Вариант 2: введите FQDN или IP-адрес LDAP-сервера. Чтобы узнать доменное имя, можно использовать команду dig с записью SRV. Запись SRV имеет следующий формат:
  __service._protocol_._domain_name_
  Пример: dig _ldap._tcp.example.com SRV.
- Вариант 3: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика предусматривает балансировку нагрузки между LDAP-серверами. Запросы распределяются между всеми LDAP-серверами по циклическому алгоритму (round-robin).
- Вариант 4: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика определяет первый LDAP-сервер как LDAP-сервер, по умолчанию отвечающий на запросы. Если первый сервер недоступен, запрос будет направлен на следующий LDAP-сервер в списке.
  1 - Single server 2 - DNS domain LDAP SRV record 3 - Round-robin between multiple hosts 4 - Failover between multiple hosts Please select:

Выберите метод безопасного подключения, поддерживаемый LDAP-сервером, и укажите метод получения сертификата Центра сертификации в кодировке PEM:

File позволяет указать полный путь к сертификату.
URL позволяет указать URL-адрес для сертификата.
Inline позволяет вставить содержимое сертификата в терминал.
System позволяет указать местоположение по умолчанию для всех файлов Центра сертификации.

Insecure пропускает проверку сертификата, но соединение по-прежнему шифруется с помощью TLS.

NOTE:
It is highly recommended to use secure protocol to access the LDAP server.
Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol.
Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: _startTLS_
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure):
Please enter the password:

LDAPS расшифровывается как облегченный протокол доступа к каталогам по SSL. Для SSL-подключений выберите вариант ldaps.

Введите отличительное имя (DN) пользователя, формирующего поисковые запросы. Пользователь должен иметь разрешения для просмотра всех пользователей и групп на сервере каталогов. Пользователь, формирующий поисковый запрос, должен быть указан в аннотации LDAP. Если разрешен анонимный поиск, нажмите Ввод (Enter), не вводя ничего.
```
Enter search user DN (for example uid=username,dc=example,dc=com or leave empty for anonymous): `uid=user1,ou=Users,ou=department-1,dc=example,dc=com`
Enter search user password:
```

Введите базовое отличительное имя (DN):

Please enter base DN (dc=example,dc=com) [dc=example,dc=com]: _ou=department-1,dc=example,dc=com

Выберите Да (Yes), если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```
Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано example.com.
```
Please specify profile name that will be visible to users: example.com
```

Чтобы переименовать профиль после того, как домен был настроен, измените атрибут ovirt.engine.aaa.authn.profile.name в файле /etc/ovirt-engine/extensions.d/example.com-authn.properties. Перезапустите службу ovirt-engine, чтобы изменение вступило в силу.

Пользователи должны выбрать профиль из выпадающего списка при первом входе в систему. Информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.

Проверьте работоспособность входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к ПО «zVirt Max». Для запроса на вход введите свои имя пользователя и пароль:

NOTE:
It is highly recommended to test drive the configuration before applying it into engine.
Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.

Please provide credentials to test login flow:
Enter user name:
Enter user password:
[ INFO  ] Executing login sequence...
...
[ INFO  ] Login sequence executed successfully

Убедитесь, что сведения о пользователе верны. Если они неверны, выберите Прервать (Abort):

Please make sure that user details are correct and group membership meets expectations (search for PrincipalRecord and GroupRecord titles).
Abort if output is incorrect.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]:

Рекомендуется вручную проверить функцию поиска. Для поискового запроса выберите Субъект (Principal) для учетных записей пользователей или Группа (Group) для учетных записей групп. Выберите Да (Yes), чтобы Разрешить группы (Resolve Groups), если нужно возвращать информацию об учетной записи группы для учетной записи пользователя. Три файла конфигурации создаются и отображаются на экране.
```
Select test sequence to execute (Done, Abort, Login, Search) [Search]: _Search_
Select entity to search (Principal, Group) [Principal]:
Term to search, trailing '*' is allowed: _testuser1_
Resolve Groups (Yes, No) [No]:
```

Выберите Готово (Done), чтобы завершить настройку:

Select test sequence to execute (Done, Abort, Login, Search) [Abort]: _Done_
[ INFO  ] Stage: Transaction setup
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Package installation
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Transaction commit
[ INFO  ] Stage: Closing up
CONFIGURATION SUMMARY
Profile name is: example.com
The following files were created:
    /etc/ovirt-engine/aaa/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com.properties
    /etc/ovirt-engine/extensions.d/example.com-authn.properties
[ INFO  ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20220104101225-mmneib.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

Перезапустите службу ovirt-engine. Созданный профиль теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы назначить учетным записям пользователей на LDAP-сервере соответствующие роли и разрешения, например, для входа на Пользовательский портал, см. Раздел 3.3.9. Администрирование пользовательских задач с Портала администрирования.

systemctl restart ovirt-engine.service

Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь:/usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

3.3.2.2. Подключение Active Directory

Предварительные условия

Известно имя леса Active Directory. Имя леса также называется именем корневого домена.

Примеры наиболее распространенных конфигураций Active Directory, которые нельзя настроить с помощью инструмента ovirt-engine-extension-aaa-ldap-setup tool, приведены в файле /usr/share/ovirt-engine-extension-aaa-ldap/examples/README.md.

Необходимо либо добавить DNS-сервер, способный разрешать имя леса Active Directory, в файл /etc/resolv.conf в Менеджере управления, либо выписать DNS-серверы Active Directory и ввести их при появлении запроса от интерактивного скрипта настройки.
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM. Дополнительную информацию см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.
Если анонимный поиск не поддерживается, то в Active Directory должен быть доступен пользователь с разрешениями на просмотр всех пользователей и групп, чтобы его можно было использовать в качестве пользователя, формирующего поисковые запросы. Запишите отличительное имя (DN) пользователя, формирующего поисковые запросы. Не используйте пользователя с правами администратора для Active Directory.
Должна существовать хотя бы одна учетная запись (имя и пароль) для выполнения запросов на поиск и вход в Active Directory.
Если развернутый Active Directory охватывает несколько доменов, необходимо учитывать ограничения, описанные в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap-setup
```
Запустите ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:
```
ovirt-engine-extension-aaa-ldap-setup
```

Выберите тип LDAP, введя соответствующий номер. После этого шага вопросы, связанные с LDAP, будут разными для разных типов LDAP.

Available LDAP implementations:
 1 - 389ds
 2 - 389ds RFC-2307 Schema
 3 - Active Directory
 4 - IBM Security Directory Server
 5 - IBM Security Directory Server RFC-2307 Schema
 6 - IPA
 7 - Novell eDirectory RFC-2307 Schema
 8 - OpenLDAP RFC-2307 Schema
 9 - OpenLDAP Standard Schema
10 - Oracle Unified Directory RFC-2307 Schema
11 - RFC-2307 Schema (Generic)
12 - RHDS
13 - RHDS RFC-2307 Schema
14 - iPlanet
Please select: 3

Введите имя леса Active Directory. Если имя леса неразрешимо DNS-сервером Менеджера управления, то скрипт предложит ввести разделенный пробелами список имен DNS-серверов Active Directory.
```
Please enter Active Directory Forest name: ad-example.example.com
[ INFO  ] Resolving Global Catalog SRV record for ad-example.example.com
[ INFO  ] Resolving LDAP SRV record for ad-example.example.com
```

Параметр file позволяет указать полный путь к сертификату.
Параметр URL позволяет указать URL-адрес сертификата.
Параметр inline позволяет вставить содержимое сертификата в терминал.
Параметр system позволяет указать местоположение для всех файлов Центра сертификации.

Параметр insecure позволяет использовать startTLS в небезопасном режиме.

NOTE:
It is highly recommended to use secure protocol to access the LDAP server.
Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol.
Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: startTLS
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure): File
Please enter the password:

Дополнительную информацию о создании сертификата Центра сертификации в кодировке PEM см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Введите отличительное имя (DN) пользователя, формирующего поисковые запросы. Пользователь должен иметь разрешения для просмотра всех пользователей и групп на сервере каталогов. Пользователь, формирующий поисковый запрос, должен быть включен в аннотацию LDAP. Если разрешен анонимный поиск, нажмите Ввод (Enter), не вводя ничего.
```
Enter search user DN (empty for anonymous): cn=user1,ou=Users,dc=test,dc=example,dc=com
Enter search user password:
```
Укажите, следует ли использовать единый вход для виртуальных машин. По умолчанию эта функция включена, но ее нельзя использовать, если включен единый вход на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена.
```
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
```

Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано example.com.

Please specify profile name that will be visible to users: example.com

Пользователи должны выбрать нужный профиль из выпадающего списка при первом входе в систему. Затем информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему.

Проверьте работоспособность поиска и входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к ПО «zVirt Max». Для запроса на вход введите имя учетной записи (account name) и пароль (password). Для поискового запроса выберите Субъект (Principal) для учетных записей пользователей или Группа (Group) для учетных записей групп. Введите Да (Yes), чтобы Разрешить группы (Resolve Groups), если нужно возвращать информацию об учетной записи группы для учетной записи пользователя. Выберите Готово (Done), чтобы завершить настройку. Три файла конфигурации создаются и отображаются на экране.

NOTE:
It is highly recommended to test drive the configuration before applying it into engine.
Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Login
Enter search user name: testuser1
Enter search user password:
[ INFO  ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Search
Select entity to search (Principal, Group) [Principal]:
Term to search, trailing '*' is allowed: testuser1
Resolve Groups (Yes, No) [No]:
[ INFO  ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Done
[ INFO  ] Stage: Transaction setup
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Package installation
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Transaction commit
[ INFO  ] Stage: Closing up
          CONFIGURATION SUMMARY
          Profile name is: example.com
          The following files were created:
              /etc/ovirt-engine/aaa/example.com.properties
              /etc/ovirt-engine/extensions.d/example.com-authz.properties
              /etc/ovirt-engine/extensions.d/example.com-authn.properties
[ INFO  ] Stage: Clean up
          Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20220514064955-1yar9i.log:
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
  Stage: Termination

Созданный профиль теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы назначить учетным записям пользователей на LDAP-сервере соответствующие роли и разрешения, например, для входа на Пользовательский портал, см. Раздел 3.3.9. Администрирование пользовательских задач с Портала администрирования.

Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь: /usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

3.3.2.3. Настройка внешнего провайдера LDAP (ручной метод)

Полностью настраиваемое расширение ovirt-engine-extension-aaa-ldap использует протокол LDAP для доступа к серверам каталогов. Аутентификация Kerberos не требуется, если только вы не хотите включить единый вход на Пользовательский портал или Портал администрирования.

Если интерактивный метод настройки, описанный в предыдущем разделе, не подходит для вашего варианта использования, можно вручную изменить файлы конфигурации, чтобы подключить свой LDAP-сервер. В следующей процедуре используются типовые данные. Конкретные значения зависят от специфики настройки.

Процедура

В Менеджере управления установите пакет расширения LDAP:
```
dnf install ovirt-engine-extension-aaa-ldap
```
Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для активных каталогов (ad) и других типов каталогов (simple). В этом примере используется простой шаблон конфигурации.
```
cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/.
/etc/ovirt-engine
```
Переименуйте файлы конфигурации, чтобы они соотносились с именем профиля, который нужно сделать видимым для пользователей на страницах входа на Портал администрирования и Пользовательский портал:
```
mv /etc/ovirt-engine/aaa/profile1.properties /etc/ovirt-engine/aaa/_example_.properties
mv /etc/ovirt-engine/extensions.d/profile1-authn.properties /etc/ovirt-engine/extensions.d/_example_-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties /etc/ovirt-engine/extensions.d/_example_-authz.properties
```
Измените файл конфигурации свойств LDAP, раскомментировав тип LDAP-сервера и обновив поля домена и паролей:
```
vi /etc/ovirt-engine/aaa/example.properties
```

Пример профиля: раздел LDAP-сервера

# Select one
#
include = <openldap.properties>
#include = <389ds.properties>
#include = <rhds.properties>
#include = <ipa.properties>
#include = <iplanet.properties>
#include = <rfc2307-389ds.properties>
#include = <rfc2307-rhds.properties>
#include = <rfc2307-openldap.properties>
#include = <rfc2307-edir.properties>
#include = <rfc2307-generic.properties>

# Server
#
vars.server = _ldap1.company.com_

# Search user and its password.
#
vars.user = uid=search,cn=users,cn=accounts,dc=_company_,dc=_com_
vars.password = _123456_

pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}

Чтобы использовать протокол TLS или SSL для взаимодействия с LDAP-сервером, получите корневой сертификат Центра сертификации для LDAP-сервера и используйте его для создания открытого файла хранилища ключей. Раскомментируйте следующие строки и укажите полный путь к открытому файлу хранилища ключей и пароль для доступа к файлу.

Дополнительную информацию о создании открытого файла хранилища ключей см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Пример профиля: раздел хранилища ключей

# Create keystore, import certificate chain and uncomment
# if using tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
pool.default.ssl.truststore.password = password

Просмотрите конфигурационный файл аутентификации. Имя профиля, видимое для пользователей на страницах входа на Портал администрирования и Пользовательский портал, определяется посредством ovirt.engine.aaa.authn.profile.name. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.

# vi /etc/ovirt-engine/extensions.d/ example -authn.properties

Пример конфигурационного файла аутентификации

ovirt.engine.extension.name = example -authn
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = example
ovirt.engine.aaa.authn.authz.plugin = example-authz
config.profile.file.1 = ../aaa/example.properties

Просмотрите конфигурационный файл авторизации. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.

vi /etc/ovirt-engine/extensions.d/example  -authz.properties

Пример конфигурационного файла авторизации

ovirt.engine.extension.name = _example_-authz
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = ../aaa/example.properties

Убедитесь, что для профиля конфигурации заданы соответствующие владелец и разрешения:

chown ovirt:ovirt /etc/ovirt-engine/aaa/ _ example _ .properties
chmod 600 /etc/ovirt-engine/aaa/ _ example _ .properties

Перезапустите службу engine:
```
systemctl restart ovirt-engine.service
```

Созданный профиль example теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы предоставить учетным записям пользователей на LDAP-сервере соответствующие разрешения, например, для входа на Пользовательский портал, см. Раздел 3.3.9. Администрирование пользовательских задач с Портала администрирования.

Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь: /usr/share/doc/ovirt-engine-extension-aaa-ldap-version.

3.3.2.4. Удаление внешнего провайдера LDAP

В этой процедуре показано, как удалить настроенного внешнего провайдера LDAP и его пользователей.

Процедура

Удалите файлы конфигурации провайдера LDAP, заменив имя по умолчанию profile1:

rm /etc/ovirt-engine/extensions.d/ _ profile1 _ -authn.properties
rm /etc/ovirt-engine/extensions.d/ _ profile1 _ -authz.properties
rm /etc/ovirt-engine/aaa/ _ profile1 _ .properties

Перезапустите службу ovirt-engine:
```
systemctl restart ovirt-engine
```
На Портале администрирования на ресурсной вкладке Пользователи (Users) выберите пользователей этого провайдера (тех, чьим Провайдером авторизации (Authorization provider) является profile1-authz) и нажмите Удалить (Remove).

3.3.3. Настройка LDAP и Kerberos для единого входа

Единый вход позволяет пользователям входить на Пользовательский портал или Портал администрирования, не вводя пароль повторно. Учетные данные для аутентификации берутся с сервера Kerberos.

Чтобы настроить единый вход на Портал администрирования и Пользовательский портал, нужно настроить два расширения: ovirt-engine-extension-aaa-misc и ovirt-engine-extension-aaa-ldap; а также два модуля Apache: mod_auth_gssapi и mod_session. Можно настроить единый вход и без использования Kerberos, однако это выходит за рамки данной документации.

Если включен единый вход на Пользовательский портал, то единый вход на виртуальные машины невозможен. Если включен единый вход на Пользовательский портал, то Пользовательскому порталу не требуется принимать пароль и поэтому невозможно делегировать пароль для входа на виртуальные машины.

В этом примере предполагается следующее:

Существующий сервер Центра распределения ключей (Key Distribution Center, KDC) использует Kerberos 5 в версии MIT.
У вас есть права администратора на сервере KDC.
Клиент Kerberos установлен на Менеджере управления и машинах пользователей.
Утилита kadmin используется для создания субъектов (principals) службы Kerberos и файлов keytab.

Эта процедура содержит следующие компоненты:

На сервере KDC

Создайте субъекта службы и файл keytab для службы Apache в Менеджере управления.

В Менеджере управления

Установите пакеты расширений аутентификации и авторизации и модуль аутентификации Apache Kerberos.
Настройте файлы расширения.

Настройка Kerberos для службы Apache

На сервере KDC, используя утилиту kadmin, создайте субъекта службы для службы Apache в Менеджере управления. Субъект службы – это идентификатор для ссылки на KDC для службы Apache.
```
kadmin
kadmin> addprinc -randkey _HTTP/fqdn-of-rhevm_@_REALM.COM_
```

Сгенерируйте файл keytab для службы Apache. В файле keytab хранится общий секретный ключ.

kadmin> ktadd -k /tmp/http.keytab _HTTP/fqdn-of-rhevm_@_REALM.COM_
kadmin> quit

Команда engine-backup включает в себя файл /etc/httpd/http.keytab при резервном копировании и восстановлении. Если для файла keytab используется другое имя, не забудьте выполнить его резервное копирование и восстановление.

Скопируйте файл keytab с сервера KDC в Менеджер управления:
```
scp /tmp/http.keytab root@rhevm.example.com:/etc/httpd
```

Настройка единого входа на Пользовательский портал или Портал администрирования

В Менеджере управления убедитесь, что для файла keytab заданы соответствующие владелец и разрешения:
```
chown apache /etc/httpd/http.keytab
chmod 400 /etc/httpd/http.keytab
```
Установите пакет расширения аутентификации, пакет расширения LDAP и модули Apache mod_auth_gssapi и mod_session:
```
dnf install ovirt-engine-extension-aaa-misc ovirt-engine-extension-aaa-ldap mod_auth_gssapi mod_session
```
Скопируйте файл шаблона конфигурации SSO в каталог /etc/ovirt-engine. Файлы шаблонов доступны для Active Directory (ad-sso) и других типов каталогов (simple-sso). В этом примере используется простой шаблон конфигурации SSO.
```
cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple-sso/  ./etc/ovirt-engine
```

Переместите ovirt-sso.conf в каталог конфигурации Apache.

mv /etc/ovirt-engine/aaa/ovirt-sso.conf /etc/httpd/conf.d

Команда engine-backup включает в себя файл /etc/httpd/conf.d/ovirt-sso.conf при резервном копировании и восстановлении. Если для этого файла используется другое имя, не забудьте выполнить его резервное копирование и восстановление.

Просмотрите файл метода аутентификации. Этот файл редактировать не нужно, так как область автоматически извлекается из файла keytab.
```
vi /etc/httpd/conf.d/ovirt-sso.conf
```

Пример файла метода аутентификации

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)|^/ovirt-engine/api>
  <If "req('Authorization') !~ /^(Bearer|Basic)/i">
    RewriteEngine on
    RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
    RewriteRule ^(.*)$ - [L,NS,P,E=REMOTE_USER:%1]
    RequestHeader set X-Remote-User %{REMOTE_USER}s

    AuthType GSSAPI
    AuthName "Kerberos Login"

    # Modify to match installation
    GssapiCredStore keytab:/etc/httpd/http.keytab
    GssapiUseSessions On
    Session On
    SessionCookieName ovirt_gssapi_session path=/private;httponly;secure;

    Require valid-user
    ErrorDocument 401 "<html><meta http-equiv=\"refresh\" content=\"0; url=/ovirt-engine/sso/login-unauthorized\"/><body><a href=\"/ovirt-engine/sso/login-unauthorized\">Here</a></body></html>"
  </If>
</LocationMatch>

Переименуйте файлы конфигурации, чтобы они соотносились с именем профиля, который нужно сделать видимым для пользователей на страницах входа на Портал администрирования и Пользовательский портал:

mv /etc/ovirt-engine/aaa/profile1.properties /etc/ovirt-engine/aaa/example.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-authn.properties /etc/ovirt-engine/extensions.d/example-http-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-mapping.properties /etc/ovirt-engine/extensions.d/example-http-mapping.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties /etc/ovirt-engine/extensions.d/example-authz.properties

Измените файл конфигурации свойств LDAP, раскомментировав тип LDAP-сервера и обновив поля домена и паролей:
```
vi /etc/ovirt-engine/aaa/example.properties
```

Пример профиля: раздел LDAP-сервера

# Select one
include = <openldap.properties>
#include = <389ds.properties>
#include = <rhds.properties>
#include = <ipa.properties>
#include = <iplanet.properties>
#include = <rfc2307-389ds.properties>
#include = <rfc2307-rhds.properties>
#include = <rfc2307-openldap.properties>
#include = <rfc2307-edir.properties>
#include = <rfc2307-generic.properties>

# Server
#
vars.server = _ldap1.company.com_

# Search user and its password.
#
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com
vars.password = _123456_

pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}

Дополнительную информацию о создании открытого файлаnхранилища ключей см. в Разделе D.2. Настройка шифрованной связи между Менеджером управления и LDAP-сервером.

Пример профиля: раздел хранилища ключей

# Create keystore, import certificate chain and uncomment
# if using ssl/tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = _/full/path/to/myrootca.jks_
pool.default.ssl.truststore.password = password

vi /etc/ovirt-engine/extensions.d/example-http-authn.properties

Пример конфигурационного файла аутентификации

ovirt.engine.extension.name = example-http-authn
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.http.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = example-http
ovirt.engine.aaa.authn.authz.plugin = example-authz
ovirt.engine.aaa.authn.mapping.plugin = example-http-mapping
config.artifact.name = HEADER
config.artifact.arg = X-Remote-User

vi /etc/ovirt-engine/extensions.d/example -authz.properties

Пример конфигурационного файла авторизации

ovirt.engine.extension.name = example-authz
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = ../aaa/example.properties

Просмотрите конфигурационный файл сопоставления аутентификации. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Имя расширения профиля конфигурации должно соотноситься со значением ovirt.engine.aaa.authn.mapping.plugin в конфигурационном файле аутентификации. Все поля можно оставить в значениях по умолчанию.

vi /etc/ovirt-engine/extensions.d/example-http-mapping.properties

Пример конфигурационного файла сопоставления аутентификации.

ovirt.engine.extension.name = example-http-mapping
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.mapping.MappingExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Mapping
config.mapAuthRecord.type = regex
config.mapAuthRecord.regex.mustMatch = true
config.mapAuthRecord.regex.pattern = ^(?<user>.*?)((\\\\(?<at>@)(?<suffix>.*?)@.*)|(?<realm>@.*))$
config.mapAuthRecord.regex.replacement = ${user}${at}${suffix}

Убедитесь, что для файлов конфигурации заданы соответствующие владельцы и разрешения:

chown ovirt:ovirt /etc/ovirt-engine/aaa/example_properties
chown ovirt:ovirt /etc/ovirt-engine/extensions.d/example-http-authn.properties
chown ovirt:ovirt /etc/ovirt-engine/extensions.d/example-http-mapping.properties
chown ovirt:ovirt /etc/ovirt-engine/extensions.d/_example_-authz.properties
chmod 600 /etc/ovirt-engine/aaa/example.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-authn.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-mapping.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-authz.properties

Перезапустите службу Apache и службу ovirt-engine:
```
systemctl restart httpd.service
systemctl restart ovirt-engine.service
```

3.3.4. Установка и настройка единого входа от Red Hat (Red Hat SSO)

Чтобы использовать единый вход от Red Hat в качестве метода авторизации, необходимо:

Установить единый вход от Red Hat.
Настроить сопоставитель групп LDAP.
Настроить Apache на Менеджере управления.
Настроить учетные данные провайдера OVN.

Если настроен единый вход от Red Hat, предыдущие входы LDAP не будут работать, поскольку одновременно может использоваться только один протокол авторизации.

3.3.5. Установка единого входа от Red Hat

Вы можете установить единый вход Red Hat, загрузив zip-файл и распаковав его, или используя RPM-файл.

Следуйте инструкциям по установке в документе Red Hat SSO Installation

Подготовьте следующую информацию:

Путь/местонахождение сервера Open ID Connect.
Канал подписки на корректные репозитории.
Корректные учетные данные для авторизации в системе подписки Red Hat.

3.3.6. Конфигурирование инструмента сопоставления групп LDAP

Процедура

Добавьте в инструмент сопоставления групп LDAP следующую информацию:
- Имя (Name): ldapgroups.
- Тип инструмента сопоставления (Mapper Type): group-ldap-mapper.
- DN групп LDAP (LDAP Groups DN): ou=groups,dc=example,dc=com.
- Классы объектов группы (Group Object Classes): groupofuniquenames (адаптируйте этот класс в соответствии с настройками сервера LDAP).
- Атрибут членства LDAP (Membership LDAP Attribute): uniquemember (адаптируйте этот класс в соответствии с настройками сервера LDAP).
Нажмите Сохранить (Save).
Нажмите Синхронизировать группы LDAP с KeyCloak (Sync LDAP Groups to KeyCloak).
Внизу страницы Провайдер федерации пользователей (User Federation Provider) нажмите Синхронизировать всех пользователей (Synchronize all users).
На вкладке Клиенты (Clients), в разделе Добавить клиента (Add Client), добавьте ovirt-engine в качестве Идентификатора клиента (Client ID) и введите URL-адрес engine в качестве Корневого URL-адреса (Root URL).
Измените Протокол клиента (Client Protocol) на openid-connect, а Тип доступа (Access Type) на конфиденциальный (confidential).
На вкладке Клиенты (Clients), в разделе Ovirt-engine → Расширенные настройки (Advanced Settings), увеличьте значение параметра Срок действия токена доступа (Access Token Lifespan).
Добавьте https://rhvm.example.com:443/ * в качестве правильного URI переадресации.
Генерируется секрет клиента, который можно просмотреть на вкладке Учетные данные (Credentials).
На вкладке Клиенты (Clients), в разделе Создать протокол инструмента сопоставления (Create Mapper Protocol), создайте инструмент сопоставления со следующими настройками:
- Имя (Name): группы.
- Тип инструмента сопоставления (Mapper Type): Членство в группе.
- Имя токена для запроса (Token Claim Name): группы.
- Полный путь к группе: Включено (ON).
- Добавить в токен идентификации (Add to ID token): Включено (ON).
- Добавить в токен доступа (Add to access token): Включено (ON).
- Добавить в информацию о пользователе (Add to userinfo): Включено (ON).
Добавьте Встроенный в протокол инструмент сопоставления (Builtin Protocol Mapper) для имени пользователя (username).
Создайте области, необходимые для ovirt-engine, ovirt-app-api, ovirt-app-admin и ovirt-ext=auth:sequence-priority=~.
Используйте области, созданные в предыдущем шаге, для настройки дополнительных областей клиента для клиента ovirt-engine.

Конфигурирование Apache в Менеджере управления

Включите модуль mod_auth_openidc.
```
dnf module enable mod_auth_openidc:2.3 -y
```
Настройте Apache в Менеджере управления.
```
dnf install mod_auth_openidc
```

Создайте новый файл конфигурации httpd ovirt-openidc.conf в /etc/httpd/conf.d/ со следующим содержимым:

LoadModule auth_openidc_module modules/mod_auth_openidc.so

OIDCProviderMetadataURL https://SSO.example.com/auth/realms/master/.well-known/openid-configuration
OIDCSSLValidateServer Off

OIDCClientID ovirt-engine
OIDCClientSecret <client_SSO _generated_key>
OIDCRedirectURI https://rhvm.example.com/ovirt-engine/callback
OIDCDefaultURL https://rhvm.example.com/ovirt-engine/login?scope=ovirt-app-admin+ovirt-app-portal+ovirt-ext%3Dauth%3Asequence-priority%3D%7E

# maps the prefered_username claim to the REMOTE_USER environment variable:

OIDCRemoteUserClaim <preferred_username>
OIDCCryptoPassphrase <random1234>

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)|^/ovirt-engine/callback>
    <If "req('Authorization') !~ /^(Bearer|Basic)/i">

      Require valid-user
      AuthType openid-connect

      ErrorDocument 401 "<html><meta http-equiv=\"refresh\" content=\"0; url=/ovirt-engine/sso/login-unauthorized\"/><body><a href=\"/ovirt-engine/sso/login-unauthorized\">Here</a></body></html>"
    </If>
</LocationMatch>

OIDCOAuthIntrospectionEndpoint https://SSO.example.com/auth/realms/master/protocol/openid-connect/token/introspect
OIDCOAuthSSLValidateServer    Off
OIDCOAuthIntrospectionEndpointParams token_type_hint=access_token
OIDCOAuthClientID ovirt-engine
OIDCOAuthClientSecret <client_SSO _generated_key>
OIDCOAuthRemoteUserClaim sub

<LocationMatch ^/ovirt-engine/(api$|api/)>
   AuthType oauth20
   Require valid-user
</LocationMatch>

Для сохранения изменения конфигурации, перезапустите httpd и ovirt-engine:
```
systemctl restart httpd

systemctl restart ovirt-engine
```

Создайте файл openidc-authn.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-authn
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.http.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = openidchttp
ovirt.engine.aaa.authn.authz.plugin = openidc-authz
ovirt.engine.aaa.authn.mapping.plugin = openidc-http-mapping
config.artifact.name = HEADER
config.artifact.arg = OIDC_CLAIM_preferred_username

Создайте файл openidc-authn.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-http-mapping
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.mapping.MappingExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Mapping
config.mapAuthRecord.type = regex
config.mapAuthRecord.regex.mustMatch = false
config.mapAuthRecord.regex.pattern = ^(?<user>.*?)((\\\\(?<at>@)(?<suffix>.*?)@.*)|(?<realm>@.*))$
config.mapAuthRecord.regex.replacement = ${user}${at}${suffix}

Создайте файл openidc-authz.properties в /etc/ovirt-engine/extensions.d/ со следующим содержимым:

ovirt.engine.extension.name = openidc-authz
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.http.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.artifact.name.arg = OIDC_CLAIM_preferred_username
config.artifact.groups.arg = OIDC_CLAIM_groups

Создайте файл 99-enable-external-auth.conf в /etc/ovirt-engine/engine.conf.d/ со следующим содержимым:

ENGINE_SSO_ENABLE_EXTERNAL_SSO=true
ENGINE_SSO_EXTERNAL_SSO_LOGOUT_URI="${ENGINE_URI}/callback"
EXTERNAL_OIDC_USER_INFO_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/userinfo
EXTERNAL_OIDC_TOKEN_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/token
EXTERNAL_OIDC_LOGOUT_END_POINT=https://SSO.example.com/auth/realms/master/protocol/openid-connect/logout
EXTERNAL_OIDC_CLIENT_ID=ovirt-engine
EXTERNAL_OIDC_CLIENT_SECRET="<client_SSO _generated_key>"
EXTERNAL_OIDC_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
EXTERNAL_OIDC_HTTPS_PKI_TRUST_STORE_PASSWORD=""
EXTERNAL_OIDC_SSL_VERIFY_CHAIN=false
EXTERNAL_OIDC_SSL_VERIFY_HOST=false

Конфигурирование OVN

При конфигурировании ovirt-ovn-provider в Менеджере управления, необходимо сконфигурировать учетные данные провайдера OVN.

Процедура

Создайте файл 20-setup-ovirt-provider-ovn.conf в /etc/ovirt-provider-ovn/conf.d/ со следующим содержимым, где user1 относится к группе LDAP ovirt-administrator, а openidchttp - это профиль, настроенный под aaa-ldap-misc.
```
[OVIRT]
ovirt-admin-user-name=user1@openidchttp
```
Перезапустите ovirt-provider-ovn:
```
systemctl restart ovirt-provider-ovn
```
Авторизуйтесь на Портале администрирования, нажмите Управление (Administration) → Провайдеры (Providers), выберите ovirt-provider-ovn и нажмите Изменить (Edit), чтобы обновить пароль провайдера OVN.

3.3.7. Авторизация пользователя

3.3.7.1. Модель авторизации пользователей

ПО «zVirt Max» использует средства управления авторизацией, основанные на сочетании трех компонентов:

Пользователь, выполняющий действие.
Тип выполняемого действия.
Объект, над которым выполняется действие.

3.3.7.2. Действия пользователей

Для успешного выполнения действия пользователь должен иметь соответствующее разрешение в отношении объекта, над которым он собирается произвести действие. Каждый тип действия имеет соответствующее разрешение.

Некоторые действия выполняются над несколькими объектами. К примеру, копирование шаблона в другой домен хранения затронет как шаблон, так и домен хранения, являющийся приемником. Пользователь, выполняющий действие, должен иметь соответствующие разрешения в отношении всех объектов, которые затрагивает действие.

3.3.8. Администрирование пользовательских задач с Портала администрирования

3.3.8.1. Добавление пользователей и назначение разрешений Пользовательского портала

Прежде чем добавить пользователей и назначить им роли и разрешения, таких пользователей нужно создать. Роли и разрешения, назначенные во время этой процедуры, позволяют пользователю авторизоваться на Пользовательском портале и начать создавать виртуальные машины. Процедура применяется к учетным записям групп.

Процедура

В верхней панели нажмите Управление (Administration) → Настройка (Configure). Откроется окно Настройка (Configure).
Нажмите Системные разрешения (System Permissions).
Нажмите Добавить (Add). Откроется окно Добавить системные разрешения пользователю (Add System Permission to User).
Выберите профиль в разделе Поиск (Search). Профиль – это домен, в котором вы хотите искать. Введите имя или часть имени в текстовое поле и нажмите Искать (GO). Либо нажмите Искать (GO), чтобы просмотреть список всех пользователей и групп.
Установите нужные флажки, чтобы выбрать необходимых пользователей и группы.
Выберите соответствующую роль для назначения в разделе Роль для связи (Role to Assign). Роль UserRole предоставляет учетной записи пользователя разрешение авторизоваться на Пользовательском портале.
Нажмите OK.

Авторизуйтесь на Пользовательском портале, чтобы убедиться, что у учетной записи пользователя есть разрешения на авторизацию.

3.3.8.2. Просмотр информации о пользователях

Процедура

Нажмите Управление (Administration) → Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Нажмите имя пользователя. Откроется подробное представление, при этом на вкладке Общие (General) обычно отображается общая информация, такая как имя домена, адрес электронной почты и статус пользователя.
Другие вкладки позволяют просматривать информацию о группах, разрешениях, квотах и событиях для соответствующего пользователя.

Например, для просмотра групп, которым принадлежит пользователь, откройте вкладку Группы из каталогов (Directory Groups).

3.3.8.3. Просмотр пользовательских разрешений в отношении ресурсов

Пользователям можно назначать разрешения на определенные ресурсы или иерархически структурированные группы ресурсов. По каждому ресурсу можно просматривать списки назначенных пользователей и их разрешения.

Процедура

Найдите и нажмите на имя ресурса. Откроется подробное представление.
Откройте вкладку Разрешения (Permissions), чтобы вывести список назначенных пользователей с информацией о роли каждого из них и унаследованных разрешениях для выбранного ресурса.

3.3.8.4. Удаление пользователей

Если учетная запись пользователя больше не нужна, удалите ее из ПО «zVirt Max».

Процедура

Нажмите Управление (Administration) → Пользователи (Users), чтобы отобразить список всех авторизованных пользователей.
Выберите пользователя для удаления. Убедитесь в том, что у него не запущена какая-либо виртуальная машина.
Нажмите Удалить (Remove), затем нажмите OK.

Пользователь удаляется из ПО «zVirt Max», но не из внешнего каталога.

3.3.8.5. Просмотр авторизованных пользователей

Можно просматривать пользователей, которые находятся в системе в настоящий момент, а также время сеанса и другую информацию.

Нажмите Управление (Administration) → Сеансы активных пользователей (Active User Sessions), чтобы просмотреть Идентификатор БД сеанса (Session DB ID), Имя пользователя (User Name), Провайдера авторизации (Authorization provider), Идентификатор пользователя (User id), IP-адрес источника (Source IP), Время начала сеанса (Session Start Time) и Время последней активности в сеансе (Session Last Active Time) для каждого авторизованного пользователя.

3.3.8.6. Завершение сеанса пользователя

Можно завершить сеанс пользователя, который в данный момент находится в системе.

Завершение сеанса пользователя

Нажмите Управление (Administration) → Сеансы активных пользователей (Active User Sessions).
Выберите сеанс пользователя, который нужно завершить.
Нажмите Завершить сеанс (Terminate Session).
Нажмите OK.

3.3.9. Администрирование пользовательских задач через командную строку

Для управления учетными записями пользователей на внутреннем домене можно использовать инструмент ovirt-aaa-jdbc-tool. Изменения, вносимые с помощью этого инструмента, сразу вступают в силу без необходимости перезагрузки службы ovirt-engine. Для просмотра полного списка параметров для пользователей выполните ovirt-aaa-jdbc-tool user --help.

Типичные примеры представлены в настоящем разделе.

Требуется авторизация на машине с Менеджером управления.

3.3.9.1. Создание нового пользователя

Можно создать новую учетную запись пользователя. При желании командой --attribute можно вывести сведения об учетной записи. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool user add --help.

ovirt-aaa-jdbc-tool user add _test1_ --attribute=firstName=John --attribute=lastName=Doe

adding user test1...
user added successfully

Можно добавить только что созданного пользователя на Портале администрирования и назначить ему соответствующие роли и разрешения. Для получения дополнительной информации см. Раздел 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.

3.3.9.2. Установка пароля пользователя

Можно создать пароль. Нужно задать значение для --password-valid-to, иначе срок действия пароля будет по умолчанию установлен как истекающий прямо сейчас. Дата указывается в формате гггг-ММ-дд ЧЧ:мм:ссX (yyyy-MM-dd HH:mm:ssX). В этом примере -0800 обозначает GMT минус 8 часов. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool user password-reset --help.

# ovirt-aaa-jdbc-tool user add test1 --attribute=firstName=John --attribute=lastName=Doe
adding user test1...
user added successfully

По умолчанию политика паролей для учетных записей пользователей на внутреннем домене имеет следующие ограничения:

Минимум 6 знаков.
При изменении пароля нельзя снова использовать три предыдущих пароля.

Для получения дополнительной информации о политике паролей и других настройках по умолчанию выполните ovirt-aaa-jdbc-tool settings show.

После обновления пароля администратора изменения должны быть вручную распространены на ovirt-provider-ovn. В противном случае пользователь с правами администратора будет заблокирован, так как Менеджер управления продолжит использовать старый пароль для синхронизации сетей из ovirt-provider-ovn. Чтобы распространить новый пароль на ovirt-provider-ovn, сделайте следующее:

На Портале администрирования нажмите Управление (Administration) → Провайдеры (Providers).
Выберите ovirt-provider-ovn.
Нажмите Изменить (Edit) и введите новый пароль в поле Пароль (Password).
Нажмите Тестировать (Test), чтобы проверить, проходит ли успешно аутентификация с предоставленными учетными данными.
После успешной проверки аутентификации нажмите ОК.

3.3.9.3. Настройка допустимого периода неактивности пользователя

Можно настроить допустимый период неактивности пользователя:

engine-config --set UserSessionTimeOutInterval= integer(укажите число)

3.3.9.4. Предварительное шифрование пароля пользователя

Можно создать предварительно зашифрованный пароль пользователя, используя скрипт ovirt-engine-crypto-tool. Эта опция полезна при добавлении пользователей и паролей в базу данных с помощью скрипта.

Пароли хранятся в базе данных Менеджера управления в зашифрованном виде. Скрипт ovirt-engine-crypto-tool используется, так как все пароли должны быть зашифрованы одним и тем же алгоритмом.

Если пароль предварительно зашифрован, то невозможно выполнить проверку действительности пароля. Пароль будет принят, даже если он не соответствует требованиям политики проверки паролей.

Выполните следующую команду:
```
/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode
```
Скрипт запросит ввод пароля.

Либо с помощью параметра --password=file:file можно зашифровать один пароль, который отображается как первая строка файла. Такой параметр полезен при автоматизации. В следующем примере file - это текстовый файл, содержащий один пароль для шифрования:
```
/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode --password=file:file(укажите путь до файла)
```
Установите новый пароль с помощью скрипта ovirt-aaa-jdbc-tool, используя параметр --encrypted:
```
ovirt-aaa-jdbc-tool user password-reset test1 --password-valid-to="2025-08-01 12:00:00-0800" --encrypted
```
Введите и подтвердите зашифрованный пароль:
```
Password:
Reenter password:
updating user test1...
user updated successfully
```

3.3.9.5. Просмотр информации о пользователях

Можно посмотреть подробные сведения об учетной записи пользователя:

ovirt-aaa-jdbc-tool user show test1

В результате выполнения этой команды отображается больше сведений, чем на экране Управление (Administration) → Пользователи (Users) на Портале администрирования.

3.3.9.6. Изменение информации о пользователе

Информацию о пользователе (например, адрес электронной почты) можно обновить:

ovirt-aaa-jdbc-tool user edit test1 --attribute=email=jdoe@example.com

3.3.9.7. Удаление пользователя

Учетную запись пользователя можно удалить:

ovirt-aaa-jdbc-tool user delete test1

Удалите пользователя с Портала администрирования. Для получения дополнительной информации см. Раздел 3.3.9.4. Удаление пользователей.

3.3.9.8. Отключение внутреннего пользователя с правами администратора

Можно отключить пользователей на локальных доменах, в том числе пользователя admin@internal, созданного в процессе выполнения engine-setup. Убедитесь, что в среде есть хотя бы один пользователь со всеми административными разрешениями, прежде чем отключать пользователя admin по умолчанию.

Процедура

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Убедитесь, что в среду добавлен другой пользователь с ролью SuperUser. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.
Отключите пользователя admin по умолчанию:
```
ovirt-aaa-jdbc-tool user edit `admin` --flag=+disabled
```

Чтобы подключить отключенного пользователя, выполните команду ovirt-aaa-jdbc-tool user edit username --flag=-disabled.

3.3.9.9. Управление группами

С помощью инструмента ovirt-aaa-jdbc-tool можно управлять учетными записями групп во внутреннем домене. Управление учетными записями групп и пользователей происходит похожим образом. Для просмотра полного списка параметров для групп выполните ovirt-aaa-jdbc-tool group --help.

Типичные примеры представлены в настоящем разделе.

Создание группы

Далее показано, как создавать учетную запись группы, добавлять пользователей в группу и просматривать подробные сведения о группе.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте новую группу:
```
 ovirt-aaa-jdbc-tool group add group1
```
Добавьте пользователей в группу. Пользователи должны быть уже созданы.
```
ovirt-aaa-jdbc-tool group-manage useradd group1 --user=test1
```
Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help.
Посмотреть подробные сведения об учетной записи группы:
```
ovirt-aaa-jdbc-tool group show group1
```
Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.

Создание вложенных групп

Далее показано, как создавать группы внутри групп.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Создайте первую группу:
```
ovirt-aaa-jdbc-tool group add group1
```
Создайте вторую группу:
```
ovirt-aaa-jdbc-tool group add  group1-1
```
Добавьте вторую группу в первую группу:
```
ovirt-aaa-jdbc-tool group-manage groupadd group1 --group=group1-1
```
Добавьте первую группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Более подробные сведения см. в Разделе 3.3.9.1. Добавление пользователей и назначение разрешений Пользовательского портала.

3.3.9.10. Опрашивание пользователей и групп

Модуль запросов (query) позволяет запрашивать информацию о пользователях и группах. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool query --help.

Вывод списка с информацией по всем учетным записям пользователей или групп

Далее показано, как вывести список с информацией по всем учетным записям.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Выведите список с информацией обо всех учетных записях.
- Данные по всем учетным записям пользователей:
  ovirt-aaa-jdbc-tool query --what=user
- Данные по всем учетным записям групп:
  ovirt-aaa-jdbc-tool query --what=group

Вывод списка по отфильтрованным данных учетных записей

Далее показано, как использовать фильтры при выводе списка информации по учетным записям.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Отфильтруйте данные учетной записи с помощью параметра --pattern.
- Выведите список данных учетных записей пользователей с именами, начинающимися со знака j.
  ovirt-aaa-jdbc-tool query --what=user --pattern="name= j*"
- Выведите список групп, у которых указан атрибут департамента маркетинг (marketing):
  ovirt-aaa-jdbc-tool query --what=group --pattern="department=marketing"

3.3.9.11. Управление настройками учетной записи

Чтобы изменить настройки учетной записи по умолчанию, используйте модуль ovirt-aaa-jdbc-tool settings.

Обновление настроек учетной записи

Далее показано, как обновить настройки учетной записи по умолчанию.

Авторизуйтесь на той машине, на которой установлен Менеджер управления.
Чтобы увидеть все доступные настройки, выполните команду:
```
ovirt-aaa-jdbc-tool settings show
```

Измените необходимые настройки:

В этом примере заданная по умолчанию длительность сеанса после авторизации изменена на 60 минут для всех учетных записей пользователей. Значение по умолчанию – 10 080 минут.
```
ovirt-aaa-jdbc-tool settings set --name=MAX_LOGIN_MINUTES --value=60
```

В этом примере изменено количество неудачных попыток входа в систему, которые может предпринять пользователь, прежде чем его учетная запись будет заблокирована. Значение по умолчанию - 5.

ovirt-aaa-jdbc-tool settings set --name=MAX_FAILURES_SINCE_SUCCESS --value=3

Чтобы разблокировать заблокированную учетную запись пользователя, выполните команду ovirt-aaa-jdbc-tool user unlock <имя пользователя>.

3.3.10. Конфигурирование дополнительных локальных доменов

Помимо внутреннего (internal) домена по умолчанию, также можно создавать дополнительные локальные домены. Это можно сделать с помощью расширения ovirt-engine-extension-aaa-jdbc, чтобы создавать несколько доменов без подключения внешних серверов каталогов, хотя такой вариант использования редко встречается в корпоративных средах.

Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений ПО «zVirt Max» и должны быть обновлены вручную при каждом новом релизе. Подробные сведения о создании дополнительных локальных доменов и о том, как обновлять домены, см. в файле README, расположенном в каталоге /usr/share/doc/ovirt-engine-extension-aaa-jdbc-<version>/README.admin.

3.4. Квоты и политика SLA

3.4.1. Введение в квоты

Квота – это инструмент ограничения ресурсов, предоставляемый с ПО «zVirt Max». Квоту можно рассматривать как слой ограничений поверх слоя ограничений, установленных разрешениями пользователя.

Квота – это объект центра данных.

Квота позволяет администраторам ПО «zVirt Max» ограничивать доступ пользователей к памяти, ЦП и хранилищу. Квота определяет ресурсы памяти и хранилища, которые администратор может назначить пользователям. В результате пользователи могут использовать только назначенные им ресурсы. Когда ресурсы по квоте исчерпаны, ПО «zVirt Max» не разрешает дальнейшие действия пользователей.

Существует два вида квот:

Таблица 73. Два вида квот
Тип квоты	Определение
Квота на ресурсы среды выполнения (Run-time Quota)	Эта квота ограничивает потребление ресурсов среды выполнения (например, ЦП и память).
Квота хранения (Storage Quota)	Эта квота ограничивает объем доступного хранилища.

У квоты, как и у SELinux, может быть три режима:

Таблица 74. Режимы квот
Режим квотирования	Описание
Принудительный (Enforced)	В этом режиме действует квота, установленная в режиме Аудита, которая ограничивает ресурсы для группы или пользователя, на которых распространяется квота.
Аудит (Audit)	В этом режиме регистрируются нарушения квот без блокировки пользователей, и он может использоваться для проверки квот. В режиме Аудита можно увеличить или уменьшить объем квоты на ресурсы среды выполнения и объем квоты хранения, доступный пользователям, на которых распространяется квота.
Выключенный (Disabled)	Этот режим отключает ограничения на ресурсы среды выполнения и ресурсы хранения, заданные квотой.

Когда пользователь пытается запустить виртуальную машину, характеристики виртуальной машины сравниваются с допустимыми значениями выделенных ресурсов хранения и выделенных ресурсов среды выполнения, установленными в соответствующей квоте.

Если запуск виртуальной машины приводит к тому, что совокупные ресурсы всех запущенных виртуальных машин, на которые распространяется квота, превышают допустимое значение, определенное квотой, то Менеджер управления отклонит запуск виртуальной машины.

Когда пользователь создает новый диск, запрашиваемый размер диска добавляется к суммарному используемому дисковому пространству всех остальных дисков, на которые распространяется квота. Если с новым диском общее суммарно используемое дисковое пространство превысит квоту, то создать диск не получится.

Квота позволяет совместно использовать ресурсы одного оборудования. Можно использовать жесткие и мягкие пороговые значения. Администраторы могут использовать квоту для установки пороговых значений по ресурсам. Для пользователя эти пороговые значения выглядят как 100% использование определенного ресурса. Для предотвращения сбоев в случае, когда заказчик внезапно превышает пороговое значение, в интерфейсе предусмотрен объем, на который можно без последствий кратковременно превысить пороговое значение. При превышении пороговых значений заказчику отправляется предупреждение.

Квота накладывает ограничения на работу виртуальных машин. Если ограничения игнорировать, то есть риск, что в какой-то момент вы не сможете использовать свои виртуальные машины и виртуальные диски.

Когда действует принудительный режим квотирования, виртуальные машины и диски, которым не назначены квоты, использовать нельзя.

Чтобы можно было включить виртуальную машину, ей должна быть назначена квота.

Чтобы можно было создать моментальный снимок виртуальной машины, диску, ассоциированному с виртуальной машиной, должна быть назначена квота.

При создании шаблона из виртуальной машины будет предложено выбрать квоту, которую будет потреблять шаблон. Это позволяет установить для шаблона (и всех будущих машин, созданных на основе шаблона) квоту, отличную от квоты виртуальной машины и диска, на основе которых создан шаблон.

3.4.2. Общая квота и индивидуально установленная квота

Пользователи с разрешениями Суперпользователя (SuperUser) могут создавать квоты для отдельных пользователей или квоты для групп.

Групповые квоты могут быть установлены для пользователей Active Directory. Если группе из десяти пользователей предоставлена квота в 1 ТБ хранилища, а один из десяти пользователей заполнит весь терабайт, то вся группа превысит квоту, и ни один из десяти пользователей не сможет использовать хранилище, ассоциированное с их группой.

Квота отдельного пользователя устанавливается только для него одного. Как только отдельный пользователь израсходует всю свою квоту на ресурсы среды выполнения или на ресурсы хранения, то он превысит квоту и больше не сможет использовать хранилище, ассоциированное с его квотой.

3.4.3. Учет квот

Когда потребителю или ресурсу назначена квота, каждое действие этого потребителя или на этом ресурсе, связанное с хранилищем, виртуальным ЦП или памятью, приводит к потреблению или высвобождению ресурсов, заложенных в квоту.

Поскольку квота действует как верхняя граница, ограничивающая доступ пользователя к ресурсам, расчеты квоты могут отличаться от фактического текущего использования пользователем. Квота рассчитывается для максимально возможного роста, а не для текущего использования.

Пример учета

Пользователь запускает виртуальную машину с 1 виртуальным ЦП и 1024 МБ памяти. Это действие потребляет 1 виртуальный ЦП и 1024 МБ из квоты, назначенной этому пользователю. После остановки виртуальной машины 1 виртуальный ЦП и 1024 МБ оперативной памяти высвобождаются и возвращаются обратно в квоту, назначенную этому пользователю.

Потребление квоты на ресурсы среды выполнения учитывается только во время фактического времени работы программ потребителя.

Пользователь создает виртуальный диск объемом 10 ГБ с динамическим выделением пространства. Фактическое использование диска может показать, что на самом деле используется только 3 ГБ этого диска. Однако квота потребления составит 10 ГБ, т.е. максимальный объем этого диска с учетом возможного роста.

3.4.4. Включение и изменение режима квотирования в центре данных

Эта процедура позволяет включить или изменить режим квотирования в центре данных. Необходимо сначала выбрать режим квотирования, а потом уже задавать квоты. Чтобы выполнить эту процедуру, необходимо авторизоваться на Портале администрирования.

Используйте режим Аудит (Audit) для проверки квоты, чтобы убедиться, что она работает в соответствии с вашими ожиданиями. Чтобы создать или изменить квоту, не обязательно использовать режим Аудит (Audit).

Процедура

Нажмите Ресурсы (Compute) → Центры данных (Data Centers) и выберите центр данных.
Нажмите Изменить (Edit).
В выпадающем списке Режим квотирования (Quota Mode) измените режим квотирования на Принудительный (Enforced).
Нажмите OK.

Если во время проверки задать режим квотирования Аудит (Audit), то необходимо будет изменить его на Принудительный (Enforced), чтобы настройки квот вступили в силу.

3.4.5. Создание новой политики квотирования

Вы включили режим квотирования Аудит (Audit) или Принудительный (Enforcing). Теперь необходимо задать политику квотирования для управления использованием ресурсов в центре данных.

Процедура

Нажмите Управление (Administration) → Квота (Quota).
Нажмите Добавить (Add).
Заполните поля Имя (Name) и Описание (Description).
Выберите Центр данных (Data Center).
В разделе Память и ЦП (Memory & CPU) используйте зеленый бегунок, чтобы задать Пороговое значение в кластере (Cluster Threshold).
В разделе Память и ЦП (Memory & CPU) используйте синий бегунок, чтобы задать Допустимое превышение в кластере (Cluster Grace).
Кнопкой-переключателем выберите Все кластеры (All Clusters) или Указанные кластеры (Specific Clusters). Если вы выбрали Указанные кластеры (Specific Clusters), то отметьте флажками кластеры, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
- В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле МБ (MB).
- В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).
- Нажмите OK в окне Изменить квоту (Edit Quota).
В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).
В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).
Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Определенные домены хранения (Specific Storage Domains). Если вы выбрали Определенные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
- В поле Квота хранения (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле ГБ (GB).
- Нажмите OK в окне Изменить квоту (Edit Quota).
Нажмите OK в окне Создать квоту (New Quota).

3.4.6. Описание настроек пороговых значений квоты

Таблица 75. Пороговые значения квот и допустимые превышения
Параметр	Определение
Пороговое значение в кластере	Объем ресурсов кластера, доступных каждому центру данных.
Допустимое превышение в кластере	Объем ресурсов кластера, доступный центру данных после достижения порогового значения в кластере, установленного для этого центра данных.
Пороговое значение для хранилища	Объем ресурсов хранилища, доступных каждому центру данных.
Допустимое превышение для хранилища	Объем ресурсов хранилища, доступный центру данных после достижения порогового значения хранилища, установленного для этого центра данных.

Если квота установлена на 100 ГБ с допустимым превышением в 20%, то потребителям заблокируют доступ к ресурсам хранилища после того, как они заполнят 120 ГБ хранилища. Если для той же квоты установлено

Пороговое значение 70%, то потребители получат предупреждение, когда заполнят больше 70 ГБ хранилища (но при этом они смогут использовать хранилище до тех пор, пока не заполнят 120 ГБ хранилища).

Пороговое значение и Допустимое превышение задаются в привязке к квоте. Пороговое значение можно рассматривать как мягкое ограничение, в результате превышения которого будет выдано предупреждение. Допустимое превышение можно рассматривать как жесткое ограничение, превышение которого делает невозможным дальнейшее потребление ресурсов хранилища.

3.4.7. Назначение квоты объекту

Назначение квоты виртуальной машине

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines) и выберите виртуальную машину.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую виртуальная машина будет потреблять.
Нажмите OK.

Назначение квоты диску

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Нажмите на имя виртуальной машины. Откроется подробное представление.
Откройте вкладку Диски (Disks) и выберите диск, который собираетесь ассоциировать с квотой.
Нажмите Изменить (Edit).
Из выпадающего списка Квота (Quota) выберите квоту, которую диск будет потреблять.
Нажмите OK.

Чтобы виртуальная машина работала, квоту необходимо выбрать для всех объектов, ассоциированных с виртуальной машиной. Если квота для объектов, ассоциированных с виртуальной машиной, не выбрана, то виртуальная машина не будет работать. В этой ситуации Менеджер управления выдает универсальное сообщение об ошибке, поэтому будет проблематично определить, вызвана ли ошибка тем, что вы не ассоциировали квоту со всеми объектами, ассоциированными с виртуальной машиной. Невозможно сделать моментальные снимки виртуальных машин, которым не назначена квота. Невозможно создать шаблоны виртуальных машин, виртуальным дискам которых не назначены квоты.

3.4.8. Использование квоты для ограничения ресурсов, доступных пользователю

Далее показано, как использовать квоты для ограничения ресурсов, к которым пользователь имеет доступ.

Процедура

Нажмите Управление (Administration) → Квота (Quota).
Нажмите на имя целевой квоты. Откроется подробное представление.
Откройте вкладку Потребители (Consumers).
Нажмите Добавить (Add).
В поле Поиск (Search) введите имя пользователя, которого хотите ассоциировать с квотой.
Нажмите Искать (GO).
Поставьте флажок рядом с именем пользователя.
Нажмите OK.

Вскоре пользователь появится на вкладке Потребители (Consumers) в подобном представлении.

3.4.9. Изменение квот

Далее показано, как изменять существующие квоты.

Процедура

Нажмите Управление (Administration) → Квота (Quota) и выберите квоту.
Нажмите Изменить (Edit).
Измените поля согласно потребностям.
Нажмите OK.

3.4.10. Удаление квот

Далее показано, как удалять квоты.

Процедура

Нажмите Управление (Administration) → Квота (Quota) и выберите квоту.
Нажмите Удалить (Remove).
Нажмите OK.

3.4.11. Принудительное применение политики SLA

Далее показано, как задать SLA для функций ЦП

Процедура

Нажмите Ресурсы (Compute) → Виртуальные машины (Virtual Machines).
Нажмите Создать (New) или выберите виртуальную машину и нажмите Изменить (Edit).
Откройте вкладку Выделение ресурсов (Resource Allocation).
Укажите Общие ЦП (CPU Shares). Возможные варианты: Низкая (Low), Средняя (Medium), Высокая (High), Настраиваемый (Custom) и Выключенная (Disabled). Виртуальные машины c настройкой Высокая (High) получают в два раза больше долей, чем с настройкой Средняя (Medium), а виртуальные машины с настройкой Средняя (Medium) получают в два раза больше долей, чем виртуальные машины с настройкой Низкая (Low). Настройка Выключенная (Disabled) даёт VDSM указание использовать старый алгоритм для распределения долей; как правило, при таких условиях количество распределяемых долей равно 1020.

Вы настроили политику, которая теперь будет регулировать потребление ЦП пользователями.

3.5. Уведомления о событиях

3.5.1. Настройка уведомлений о событиях на Портале администрирования

Менеджер управления может отправлять уведомления определенным пользователям по электронной почте при наступлении определенных событий в среде, которой управляет Менеджер управления. Чтобы использовать эту функцию, необходимо настроить агент передачи почты для доставки сообщений. Через Портал администрирования можно настроить только уведомления по электронной почте. Ловушки SNMP должны быть настроены на машине с Менеджером управления.

Процедура

Убедитесь, что у вас есть доступ к почтовому серверу, который может принимать автоматические сообщения от Менеджера управления и доставлять их по списку рассылки.
Нажмите Управление (Administration) → Пользователи (Users) и выберите пользователя.
Нажмите на Имя пользователя (User Name), чтобы открыть подробное представление.
На вкладке Уведомление о событиях (Event Notifier) нажмите Управление событиями (Manage Events).
Нажмите на кнопку Развернуть все (Expand All) или специальные кнопки расширения, чтобы просмотреть события.
Поставьте необходимые флажки.

Укажите адрес электронной почты в поле Получатель почты (Mail Recipient).

Адрес электронной почты может быть указан как адрес электронной почты для текстовых сообщений (например, 1234567890@carrierdomainname.com) или как групповой адрес электронной почты, в который входят как адреса электронной почты, так и адреса электронной почты для текстовых сообщений.

Нажмите OK.

На машине с Менеджером управления скопируйте ovirt-engine-notifier.conf в новый файл с именем 90-email-notify.conf:
```
cp /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf /etc/ovirt-engine/notifier/notifier.conf.d/90-email-notify.conf
```
Измените 90-email-notify.conf и удалите всё, кроме раздела EMAIL Notifications.

Введите корректные переменные электронной почты, как в примере ниже. Этот файл переопределяет значения в оригинальном файле ovirt-engine-notifier.conf.

#---------------------#
# EMAIL Notifications #
#---------------------#

# The SMTP mail server address. Required.
MAIL_SERVER=myemailserver.example.com

# The SMTP port (usually 25 for plain SMTP, 465 for SMTP with SSL, 587 for SMTP with TLS)
MAIL_PORT=25

# Required if SSL or TLS enabled to authenticate the user. Used also to specify 'from' user address if mail server
# supports, when MAIL_FROM is not set. Address is in RFC822 format
MAIL_USER=

# Required to authenticate the user if mail server requires authentication or if SSL or TLS is enabled
SENSITIVE_KEYS="${SENSITIVE_KEYS},MAIL_PASSWORD"
MAIL_PASSWORD=

# Indicates type of encryption (none, ssl or tls) should be used to communicate with mail server.
MAIL_SMTP_ENCRYPTION=none

# If set to true, sends a message in HTML format.
HTML_MESSAGE_FORMAT=false

# Specifies 'from' address on sent mail in RFC822 format, if supported by mail server.
MAIL_FROM=rhevm2017@example.com

# Specifies 'reply-to' address on sent mail in RFC822 format.
MAIL_REPLY_TO=

# Interval to send smtp messages per # of IDLE_INTERVAL
MAIL_SEND_INTERVAL=1

# Amount of times to attempt sending an email before failing.
MAIL_RETRIES=4

Дополнительные параметры см. в файле /etc/ovirt-engine/notifier/notifier.conf.d/README.

Включите и перезапустите сервис ovirt-engine-notifier, чтобы внесенные изменения вступили в силу:
```
systemctl daemon-reload
systemctl enable ovirt-engine-notifier.service
systemctl restart ovirt-engine-notifier.service
```

Теперь указанный пользователь будет получать сообщения по электронной почте о событиях в ПО «zVirt Max». Выбранные события отображаются для этого пользователя на вкладке Уведомление о событиях (Event Notifier).

3.5.2. Отмена уведомлений о событиях на Портале администрирования

Пользователь настроил ряд ненужных уведомлений по электронной почте и хочет их отменить.

Процедура

Нажмите Управление (Administration) → Пользователи (Users).
Нажмите на Имя пользователя (User Name). Откроется подробное представление.
Откройте вкладку Уведомление о событиях (Event Notifier), чтобы увидеть список событий, о которых пользователь получает уведомления по электронной почте.
Нажмите Управление событиями (Manage Events).
Нажмите кнопку Развернуть все (Expand All) или специальные кнопки расширения, чтобы просмотреть события.
Снимите необходимые флажки, чтобы удалить уведомления для этого события.
Нажмите OK.

3.5.3. Параметры уведомлений о событиях в ovirt-engine-notifier.conf

Файл конфигурации службы уведомлений о событиях находится в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf.

Таблица 76. Переменные 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.5.4. Настройка Менеджера управления на отправку ловушек SNMP

Настройте Менеджер управления на отправку ловушек SNMP одному или нескольким внешним менеджерам SNMP. Ловушки SNMP содержат информацию о системных событиях; они используются для мониторинга ПО «zVirt Max». Количество и тип ловушек, отправляемых менеджеру SNMP, можно задать в Менеджере управления.

ПО «zVirt Max» поддерживает SNMP версий 2 и 3. SNMP версии 3 поддерживает следующие уровни безопасности:

NoAuthNoPriv

Ловушки SNMP отправляются без какой-либо авторизации или конфиденциальности.
AuthNoPriv

Ловушки SNMP отправляются с авторизацией по паролю, но без конфиденциальности.
AuthPriv

Ловушки SNMP отправляются с авторизацией по паролю и с конфиденциальностью.

Предварительные условия

Один или несколько внешних менеджеров SNMP настроены на получение ловушек.
IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. При желании задайте порт, через который Менеджер управления получает уведомления о ловушках. По умолчанию: UDP-порт 162.
SNMP Community (только для SNMP версии 2). Несколько менеджеров SNMP могут принадлежать одному сообществу. Системы управления и агенты могут взаимодействовать, только если они находятся в одном сообществе. Сообщество по умолчанию – public.
Идентификатор объекта-ловушки для оповещений. OID, который Менеджер управления предоставляет по умолчанию – 1.3.6.1.4.1.2312.13.1.1. Когда этот OID задан, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления.
Имя пользователя SNMP, для SNMP версии 3, уровни безопасности 1, 2 и 3.
Парольная фраза SNMP, для SNMP версии 3, уровни безопасности 2 и 3.
Парольная фраза обеспечения конфиденциальности SNMP, для SNMP версии 3, уровень безопасности 3.

Менеджер управления предоставляет следующие информационные базы управления (MIB): /usr/share/doc/ovirt-engine/mibs/OVIRT-MIB.txt и /usr/share/doc/ovirt-engine/mibs/REDHAT-MIB.txt. Прежде чем продолжать, загрузите MIB в менеджер SNMP.

Значения параметров конфигурации SNMP по умолчанию имеются в Менеджере управления в файле конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. Значения, приведенные в следующей процедуре, основаны на значениях по умолчанию или взятых для примера значениях, представленных в этом файле. Не изменяйте этот файл напрямую, так как системные изменения, такие как обновления, могут аннулировать любые внесенные в этот файл изменения. Вместо этого скопируйте этот файл в /etc/ovirt-engine/notifier/notifier.conf.d/ < integer > -snmp.conf, где < integer > – это число, указывающее приоритет, с которым должен выполняться этот файл.

Процедура

В Менеджере управления создайте файл конфигурации SNMP с именем < integer > -snmp.conf, где < integer > – это целое число, указывающее порядок обработки файлов. Например:

vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

Укажите менеджера(ов) SNMP, SNMP Community (только для SNMP версии 2) и OID в формате, приведенном в этом примере:
```
SNMP_MANAGERS="_manager1.example.com_ _manager2.example.com:162_"
SNMP_COMMUNITY=public
SNMP_OID=1.3.6.1.4.1.2312.13.1.1
```
Укажите, какую версию SNMP следует использовать: 2 (по умолчанию) или 3:
```
SNMP_VERSION=3
```
Укажите значение для параметра SNMP_ENGINE_ID.
```
Например:
`SNMP _ ENGINE _ ID="80:00:00:00:01:02:05:05"`
```
В случае SNMP версии 3 укажите уровень безопасности для ловушек SNMP:

Уровень безопасности 1, ловушки NoAuthNoPriv:
```
SNMP_USERNAME=NoAuthNoPriv
SNMP_SECURITY_LEVEL=1
```
Уровень безопасности 2, ловушки AuthNoPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass.
```
SNMP_USERNAME=ovirtengine
SNMP_AUTH_PROTOCOL=MD5
SNMP_AUTH_PASSPHRASE=authpass
SNMP_SECURITY_LEVEL=2
```
Уровень безопасности 3, ловушки AuthPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass и парольная фраза для обеспечения конфиденциальности по SNMP privpass. Например:
```
SNMP_USERNAME=ovirtengine
SNMP_AUTH_PROTOCOL=MD5
SNMP_AUTH_PASSPHRASE=authpass
SNMP_PRIVACY_PROTOCOL=AES128
SNMP_PRIVACY_PASSPHRASE=privpass
SNMP_SECURITY_LEVEL=3
```
Определите, какие события следует отправлять менеджеру SNMP:

Примеры событий SNMP

Отправлять все события на SNMP-профиль, заданный по умолчанию:

FILTER="include:*(snmp:) ${FILTER}"

Отправлять все события со степенью серьезности ОШИБКА (ERROR) или ОПОВЕЩЕНИЕ (ALERT) на SNMP-профиль, заданный по умолчанию:

FILTER="include:*:ERROR(snmp:) ${FILTER}"
FILTER="include:*:ALERT(snmp:) ${FILTER}"

Отправлять события для VDC_START на указанный адрес электронной почты:

FILTER="include: VDC_START(snmp:mail@example.com)${FILTER}"

Отправлять события для всего, кроме VDC_START, на SNMP-профиль, заданный по умолчанию:

FILTER="exclude:VDC_START include:*(snmp:)${ FILTER}"

Это фильтр по умолчанию, определенный в ovirt-engine-notifier.conf; если не выключить этот фильтр или не применить переопределяющие его фильтры, то никакие уведомления не будут отсылаться:

FILTER="exclude: * "

VDC _ START – это пример сообщений журнала аудита. Полный список сообщений журнала аудита содержится в файле /usr/share/doc/ovirt-engine/AuditLogMessages.properties. Либо отфильтруйте результаты в менеджере SNMP.

Сохраните файл.
Запустите службу ovirt-engine-notifier и убедитесь, что она запускается при загрузке:
```
systemctl start ovirt-engine-notifier.service
systemctl enable ovirt-engine-notifier.service
```
Проверьте менеджер SNMP, чтобы убедиться в получении ловушек.

Для работы службы уведомлений необходимо чтобы параметры SNMP_MANAGERS, MAIL_SERVER были должным образом определены в файле /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf либо в переопределяющем файле.

Пример файла конфигурации SNMP

В этом примере файла конфигурации за основу взяты настройки в ovirt-engine-notifier.conf. Выделенный файл конфигурации SNMP (такой, как этот) переопределяет настройки в ovirt-engine-notifier.conf.

Скопируйте настройки SNMP по умолчанию из файла конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf в /etc/ovirt-engine/notifier/notifier.conf.d/ <integer> -snmp.conf, где <integer> – число, указывающее приоритет, с которым должен выполняться файл. В этом файле есть комментарии по всем настройкам.

/etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.conf

SNMP_MANAGERS="manager1.example.com manager2.example.com:162" (1)
SNMP_COMMUNITY=public (2)
SNMP_OID=1.3.6.1.4.1.2312.13.1.1 (3)
FILTER="include:*(snmp:)" (4)
SNMP_VERSION=3 (5)
SNMP_ENGINE_ID="80:00:00:00:01:02:05:05" (6)
SNMP_USERNAME=<username> (7)
SNMP_AUTH_PROTOCOL=MD5 (8)
SNMP_AUTH_PASSPHRASE=<authpass> (9)
SNMP_PRIVACY_PROTOCOL=AES128 (10)
SNMP_PRIVACY_PASSPHRASE=<privpass> (11)
SNMP_SECURITY_LEVEL=3 (12)

1	IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, `manager1.example.com` `manager2.example.com:164`
2	(только SNMP версии 2) строка по умолчанию для SNMP Community.
3	Идентификатор объекта-ловушки SNMP для исходящих уведомлений. `iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) redhat(2312) ovirt(13) engine(1) notifier(1)`
4	Алгоритм, используемый для определения триггеров и получателей уведомлений SNMP.
5	Версия SNMP. Поддерживаются ловушки SNMP версий 2 и 3. `2` = SNMPv2, `3` = SNMPv3.
6	(только SNMP версии 3) Идентификатор engine, используемый для ловушек SNMP.
7	(только SNMP версии 3) Имя пользователя, используемое для ловушек SNMP.
8	(только SNMP версии 3) Протокол авторизации SNMP. Поддерживаемые значения – `MD5` и `SHA`. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `2` (AUTH_NOPRIV) или `3` (AUTH_PRIV).
9	(только SNMP версии 3) Парольная фраза для авторизации по SNMP. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `2` (AUTH_NOPRIV) или `3` (AUTH_PRIV).
10	(только SNMP версии 3) Протокол обеспечения конфиденциальности SNMP. Поддерживаемые значения – `AES128`, `AES192` и `AES256`. Имейте в иду, что протоколы AES192 и AES256 не заданы в RFC3826, поэтому перед их включением убедитесь, что ваш SNMP-сервер поддерживает их. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `3` (AUTH_PRIV).
11	(только SNMP версии 3) Парольная фраза обеспечения конфиденциальности SNMP. Требуется, когда параметр `SNMP_SECURITY_LEVEL` установлен в значение `3` (AUTH_PRIV).
12	(только SNMP версии 3) Уровень безопасности SNMP. `1` = NOAUTH_NOPRIV, `2` = AUTH_NOPRIV, `3` = AUTH_PRIV.

3.6. Утилиты

3.6.1. Инструмент переименования oVirt Engine

3.6.1.1. Инструмент переименования oVirt Engine

Когда команда engine-setup выполняется в чистой среде, она генерирует ряд сертификатов и ключей, которые используют FQDN Менеджера управления, сообщенное во время установки. Если FQDN Менеджера управления впоследствии потребуется изменить (например, из-за переноса машины с Менеджером управления в другой домен), то записи об FQDN должны быть обновлены, чтобы отразить новое имя. Команда ovirt-engine-rename автоматизирует эту задачу.

Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления в следующих местах:

/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
/etc/ovirt-engine/isouploader.conf.d/10-engine-setup.conf
/etc/ovirt-engine/logcollector.conf.d/10-engine-setup.conf
/etc/pki/ovirt-engine/cert.conf
/etc/pki/ovirt-engine/cert.template
/etc/pki/ovirt-engine/certs/apache.cer
/etc/pki/ovirt-engine/keys/apache.key.nopass
/etc/pki/ovirt-engine/keys/apache.p12

В процессе обновления прежний FQDN должен разрешаться с помощью DNS.

Если в процессе работы ovirt-engine-rename завершается с ошибкой:

[ ERROR ] Hostname is not valid: <OLD FQDN> did not resolve into an IP address

необходимо добавить прежний FQDN в файл /etc/hosts.

Команда ovirt-engine-rename не обновляет SSL-сертификаты для таких сервисов, как imageio-proxy или websocket-proxy. Сертификаты необходимо обновить вручную после выполнения ovirt-engine-rename.

После выполнения процедуры смены FQDN менеджера управления не удаляйте старое имя хоста из файла /etc/hosts, так как оно необходимо для корректной работы внутренних служб менеджера управления.

3.6.1.2. Синтаксис команды переименования oVirt Engine

Базовый синтаксис команды ovirt-engine-rename:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

Команда также принимает следующие параметры:

--newname= [ new name ]

Позволяет указать новое FQDN для Менеджера управления без взаимодействия с пользователем.
--log= [ file ]

Позволяет указать путь и имя файла, в который должны быть записаны журналы операции переименования.
--config= [ file ]

Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования.
--config-append= [ file ]

Позволяет указать путь и имя файла конфигурации для подключения к операции переименования. Этот параметр можно использовать для указания пути и имени существующего файла ответов для автоматизации операции переименования.
--generate-answer= [ file ]

Позволяет указать путь и имя файла, в котором записаны ответы и значения, измененные командой ovirt-engine-rename.

3.6.1.3. Переименование Менеджера управления с помощью инструмента переименования oVirt Engine

Можно использовать команду ovirt-engine-rename для обновления записей об FQDN Менеджера управления.

Инструмент проверяет, предоставляет ли Менеджер управления локальный домен ISO или домен хранения данных. Если да то, прежде чем продолжить операцию, инструмент предлагает пользователю извлечь, выключить или перевести в режим обслуживания любую виртуальную машину или домен хранения, подключенный к хранилищу. Это гарантирует, что виртуальные машины не потеряют связь со своими виртуальными дисками, а домены хранения ISO не потеряют связь во время процесса переименования.

Процедура

Подготовьте все DNS и другие относящиеся к делу записи для нового FQDN.
Обновите конфигурацию DHCP-сервера, если DHCP используется.
Обновите имя хоста в Менеджере управления.

Выполните следующую команду:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename

При появлении запроса нажмите Ввод (Enter), чтобы остановить службу engine:
```
During execution engine service will be stopped (btn:[OK], Cancel)
 [ btn:[OK] ] :
```
При появлении запроса введите новое FQDN для Менеджера управления:
```
New fully qualified server name: new_engine_fqdn
```
Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления.

Для hosted engine выполните следующие дополнительные шаги:

Выполните следующую команду на каждом существующем узле с ролью hosted engine:
```
hosted-engine --set-shared-config fqdn new_engine_fqdn   --type=he_local
```
Эта команда изменяет FQDN в локальной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf, имеющейся на каждом узле с ролью hosted engine.
Выполните следующую команду на одном из узлов с ролью hosted engine:
```
hosted-engine --set-shared-config fqdn_new_engine_fqdn  --type=he_shared
```
Эта команда изменяет FQDN в мастер-копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf в общем домене хранения.

Теперь все новые и существующие узлы с ролью hosted engine используют новое FQDN.

3.6.2. Инструмент настройки Engine

3.6.2.1. Инструмент настройки Engine

Инструмент настройки engine – это утилита командной строки для настройки глобальных параметров ПО «zVirt Max». Инструмент взаимодействует со списком сопоставлений "ключ-значение", которые хранятся в базе данных engine, и позволяет извлекать и задавать значения отдельных ключей, а также извлекать список всех доступных ключей и значений конфигурации. Кроме того, для каждого уровня конфигурации в ПО «zVirt Max» могут храниться разные значения.

3.6.2.2. Синтаксис команды engine-config

Можно запустить инструмент настройки engine с машины, на которой установлен Менеджер управления. Для получения подробной информации об использовании распечатайте вывод справки для команды:

engine-config --help

Распространенные задачи:

Перечислить доступные ключи конфигураци
```
engine-config --list
```
Перечислить доступные значения конфигурации
```
engine-config --all
```
Извлечь значение ключа конфигурации
```
engine-config --get  KEY_NAME
```
Вместо KEY_NAME укажите имя нужного ключа, чтобы извлечь значение для заданной версии ключа. С помощью параметра --cver укажите версию конфигурации, для которой нужно извлечь значение. Если версия не указана, будут возвращены значения для всех существующих версий.
Задать значение ключа конфигурации
```
engine-config --set  KEY_NAME =KEY_VALUE --cver=VERSION
```
Вместо KEY_NAME укажите имя конкретного ключа, значение которого нужно задать, а вместо KEY_VALUE – значение, которое нужно задать. В средах, где имеется несколько версий конфигурации, необходимо указать VERSION.
Перезапустите службу ovirt-engine, чтобы загрузить изменения.
```
systemctl restart ovirt-engine.service
```

3.6.3. Инструмент USB Filter Editor

3.6.3.1. Установка инструмента USB Filter Editor

USB Filter Editor – это инструмент Windows, используемый для настройки файла политик usbfilter.txt. Правила политики, определенные в этом файле, разрешают или запрещают конкретным USB-устройствам автоматический сквозной доступ с клиентских машин на виртуальные машины, управляемые с помощью Менеджера управления. Файл политики находится в Менеджере управления здесь: /etc/ovirt-engine/usbfilter.txt Изменения, внесенные в политики фильтров USB, не вступят в силу, пока не будет перезапущена служба ovirt-engine на Менеджере управления.

На машине Windows извлеките установщик .msi из файла .zip и запустите установщик .msi.
Следуйте инструкциям мастера установки. Если не указано иное, то USB Filter Editor будет установлен по умолчанию в папку C: \ Program Files \ RedHat \ USB Filter Editor или C: \ Program Files(x86) \ RedHat \ USB Filter Editor в зависимости от версии Windows.
На рабочем столе будет создан ярлык USB Filter Editor.

Для импорта и экспорта политик фильтров из Менеджера управления используйте клиент Secure Copy (SCP). Инструмент Secure Copy для машин Windows называется WinSCP (http://winscp.net).

Используемая по умолчанию политика в отношении USB-устройств предоставляет виртуальным машинам базовый доступ к USB-устройствам. Чтобы разрешить использование дополнительных USB-устройств, обновите политику.

3.6.3.2. Интерфейс инструмента USB Filter Editor

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе.

Интерфейс инструмента Red Hat USB Filter Editor отобразит Класс (Class), Вендора (Vendor), Продукт (Product), Редакцию (Revision) и Действие (Action) для каждого USB-устройства. Для разрешенных USB-устройств в столбце Действие (Action) установлено значение Разрешить (Allow), для запрещенных – Блокировать (Block).

Таблица 77. Поля инструмента USB Editor
Имя	Описание
Класс (Class)	Тип USB-устройства (например, принтеры, контроллеры накопителей).
Вендор (Vendor)	Производитель выбранного типа устройства.
Продукт (Product)	Конкретная модель USB-устройства.
Редакция (Revision)	Редакция продукта.
Действие (Action)	Разрешить или блокировать конкретное устройство.

Правила политики в отношении USB-устройств обрабатываются в том порядке, в котором они перечислены. Кнопками Вверх (Up) и Вниз (Down) правила можно перемещать по списку. Универсальное правило Блокировать (Block) должно оставаться в самом низу списка, чтобы гарантировать, что будут запрещены все USB-устройства, если только они прямо не разрешены в инструменте USB Filter Editor.

3.6.3.3. Добавление политики в отношении USB

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Добавить (Add).
С помощью флажков Класс USB (USB Class), Идентификатор вендора (Vendor ID), Идентификатор продукта (Product ID) и Редакция (Revision) и списков укажите устройство.
Нажмите кнопку Разрешить (Allow), чтобы разрешить виртуальным машинам использовать USB-устройство, либо нажмите кнопку Блокировать (Block), чтобы запретить виртуальным машинам доступ к USB-устройству.
Нажмите OK, чтобы добавить выбранное правило фильтра в список, и закройте окно.

Пример. Добавление устройства

Ниже приводится пример того, как добавить Класс USB Smartcard, устройство EP-1427X-2 Ethernet Adapter производителя Acer Communications & Multimedia в список разрешенных устройств.

add usb acer

Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Политика в отношении USB добавлена в USB Filter Editor. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

Дополнительные ресурсы

Экспортирование политики в отношении USB

3.6.3.4. Удаление политики в отношении USB

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Выберите политику, которую нужно удалить.
Нажмите Удалить (Remove). Появится сообщение с предложением подтвердить удаление политики.
Нажмите Да (Yes), чтобы подтвердить удаление политики.
Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Политика в отношении USB удалена из USB Filter Editor. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

3.6.3.5. Поиск политик в отношении USB-устройств

Выполните поиск подключенных USB-устройств, чтобы разрешить или заблокировать их в инструменте USB Filter Editor.

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Поиск (Search). В окне Подключенные USB-устройства (Attached USB Devices) отображается список всех подключенных устройств.
Выберите устройство и нажмите Разрешить (Allow) или Блокировать (Block) соответственно. Дважды щелкните по выбранному устройству, чтобы закрыть окно. Правило политики для устройства добавлено в список.
Кнопками Вверх (Up) и Вниз (Down) измените положение нового правила политики в списке.
Нажмите Файл (File) → Сохранить (Save), чтобы сохранить изменения.

Поиск подключенных USB-устройств выполнен. Чтобы политики фильтров USB вступили в силу, их нужно экспортировать в Менеджер управления.

3.6.3.6. Экспортирование политики в отношении USB

Чтобы обновленная политика в отношении USB-устройств вступила в силу, внесенные в нее изменения нужно экспортировать и выгрузить в Менеджер управления. Выгрузите политику и перезапустите службу ovirt-engine.

Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.

Процедура

Нажмите Экспортировать (Export). Откроется окно Сохранить как (Save As).
Сохраните файл под именем usbfilter.txt.
Используя клиент Secure Copy (такой как WinSCP), выгрузите файл usbfilter.txt на сервер, где запущен Менеджер управления. Файл нужно поместить в следующий каталог на сервере: /etc/ovirt-engine/
Авторизовавшись в качестве root-пользователя на сервере с Менеджером управления, перезапустите службу ovirt-engine.
```
systemctl restart ovirt-engine.service
```

3.6.3.7. Импортирование политики в отношении USB

Чтобы изменить существующую политику в отношении USB-устройств, ее нужно сначала загрузить и импортировать в USB Filter Editor.

Процедура

Используя клиент Secure Copy (такой как WinSCP), загрузите файл usbfilter.txt с сервера, где запущен Менеджер управления. Файл находится в следующем каталоге на сервере: /etc/ovirt-engine/
Дважды щелкните по ярлыку USB Filter Editor на рабочем столе. Откроется редактор.
Нажмите Импортировать (Import). Откроется окно Открыть (Open).
Откройте файл usbfilter.txt, загруженный с сервера.

3.6.4. Инструмент Engine Vacuum

3.6.4.1. Инструмент Engine Vacuum

Инструмент Engine Vacuum поддерживает базы данных, обновляя таблицы, удаляя неиспользуемые строки и тем самым позволяя повторно использовать дисковое пространство.

Команда Engine Vacuum – engine-vacuum. Необходимо авторизоваться в системе как root-пользователь и ввести учетные данные администратора для ПО «zVirt Max».

Как альтернативный вариант, можно запустить инструмент Engine Vacuum командой engine-setup, чтобы задать свои параметры для существующей инсталляции:

engine-setup

...

 [  INFO  ]  Stage: Environment customization

...

Perform full vacuum on the engine database engine@localhost?

This operation may take a while depending on this setup health and the

configuration of the db vacuum process.

(Yes, No)  [ No ] :

Опция Да (Yes) запускает инструмент Engine Vacuum в режиме полной очистки.

3.6.4.2. Режимы работы Engine Vacuum

Инструмент Engine Vacuum имеет два режима работы:

Стандартная очистка
- Рекомендуется проводить стандартную очистку часто.
- Стандартная очистка удаляет неиспользуемые версии строк в таблицах и индексах и помечает пространство как доступное для повторного использования в будущем. Для часто обновляемых таблиц очистку следует проводить регулярно. Однако функция стандартной очистки не возвращает пространство операционной системе.
- Стандартная очистка без указания параметров обрабатывает каждую таблицу в текущей базе данных.
Полная очистка
- Полную очистку рекомендуется проводить не регулярно, а тогда, когда нужно вернуть операционной системе значительную часть пространства из объема, занимаемого таблицей.
- Полная очистка сжимает таблицы путем записи новой копии файла таблицы без неиспользуемого места, тем самым позволяя операционной системе вернуть пространство. Полная очистка может занять много времени.
- Полная очистка требует дополнительного места на диске для новой копии таблицы, пока операция не завершится и старая копия не будет удалена. Поскольку полная очистка требует полной блокировки таблицы, ее нельзя запускать одновременно с другими операциями, касающимися использования таблицы.

3.6.4.3. Синтаксис команды engine-vacuum

Базовый синтаксис команды engine-vacuum:

engine-vacuum

engine-vacuum  _option_

Запуск команды engine-vacuum без параметров выполняет стандартную очистку.

Команду engine-vacuum можно уточнить с помощью ряда параметров.

Общие параметры
- -h --help
  
  Выводит информацию о том, как использовать команду engine-vacuum.
- -a
  
  Запускает стандартную очистку, анализирует базу данных и обновляет статистику оптимизатора.
- -A
  
  Анализирует базу данных и обновляет статистику оптимизатора, не выполняя очистку.
- -f
  
  Запускает полную очистку.
- -v
  
  Задает режим детализации консольного вывода.
- -t table_name
  
  Выполняет очистку конкретной таблицы или таблиц.
  engine-vacuum -f -v -t vm_dynamic -t vds_dynamic

3.6.5. Инструмент сопоставления VDSM с именем сети

3.6.5.1. Сопоставление имен VDSM с именами логических сетей

Если имя логической сети длиннее 15 знаков или содержит знаки, отличные от ASCII, то система автоматически сгенерирует имя имя-идентификатор для использования на хосте (vdsm_name), состоящее из букв on и первых 13 знаков уникального идентификатора сети, например, ona1b2c3d4e5f6g.

Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имен логических сетей и их автоматически сгенерированных имен сетей, используйте инструмент сопоставления VDSM с именами сетей, расположенный в /usr/share/ovirt-engine/bin/.

Процедура

При первом запуске инструмента определите переменную среды PASSWORD, которая представляет собой пароль пользователя базы данных с доступом на чтение к базе данных Менеджера управления. Например, запустите:
```
export PASSWORD=DatabaseUserPassword
```
Запустите инструмент сопоставления VDSM с именем сети:
```
vdsm_to_network_name_map --user USER
```
где USER – пользователь базы данных с доступом на чтение к базе данных Менеджера управления, чей пароль назначен для переменной среды PASSWORD.

Инструмент отображает список имен логических сетей, сопоставленных с их эквивалентными идентификаторами, используемыми на хостах.

Дополнительные флажки

Можно запустить инструмент со следующими параметрами:

--host – имя хоста / IP-адрес сервера баз данных. Значение по умолчанию – localhost.
--port – номер порта сервера баз данных. Значение по умолчанию – 5432.
--database – имя базы данных. Значение по умолчанию – engine, представляющий собой базу данных Менеджера управления.
--secure – разрешает безопасное подключение к базе данных. По умолчанию инструмент запускается без безопасного подключения.

4. Сбор сведений о среде

4.1. Мониторинг и наблюдение

В этой главе рассмотрен ряд способов мониторинга и получения метрик и журналов из системы ПО «zVirt Max». К таким способам относятся:

Использование Хранилища (DWH)
Отправка метрик в удаленный экземпляр Elasticsearch

4.1.1. Использование Хранилища (DWH)

Данные от Менеджера управления собираются каждую минуту и агрегируются каждый час и каждые сутки. Данные сохраняются в соответствии с настройкой охвата (scale), заданной в конфигурации Хранилища (DWH) во время выполнения команды engine-setup (Базовый (Basic) или Полный (Full) охват):

Базовый (Basic) (по умолчанию) – включает в выборку данные за 24 часа, почасовые данные за 1 месяц, а посуточные данные не сохраняет.
Полный (Full) (рекомендуется) – включает в выборку данные за 24 часа, почасовые данные за 2 месяца и посуточные данные за 5 лет.

Полный охват может потребовать переноса Хранилища (DWH) на отдельную виртуальную машину.

4.1.2. Отправка метрик и журналов в удаленный экземпляр Elasticsearch

Рокитсофт не является владельцем и не поддерживает Elasticsearch. Чтобы развернуть эту опцию, необходимо иметь опыт настройки и обслуживания Elasticsearch.

Можно настроить Менеджер управления и хосты для отправки данных метрик и журналов в существующий экземпляр Elasticsearch.

Для этого запустите роль Ansible, которая настраивает collectd и rsyslog на Менеджере управления и все хосты на сбор метрик engine.log, vdsm.log и collectd, и отправьте их в экземпляр Elasticsearch.

4.1.2.1. Установка collectd и rsyslog

Разверните службы collectd и rsyslog на хостах, чтобы собирать журналы и метрики.

Эту процедуру не нужно повторять для новых хостов. Менеджер управления автоматически настраивает каждый новый добавляемый хост на отправку данных в Elasticsearch во время развертывания хоста.

Процедура

Авторизуйтесь на машине с Менеджером управления, используя SSH.
Скопируйте /etc/ovirt-engine-metrics/config.yml.example , чтобы создать /etc/ovirt-engine-metrics/config.yml.d/config.yml:
```
cp /etc/ovirt-engine-metrics/config.yml.example /etc/ovirt-engine-metrics/config.yml.d/config.yml
```
Измените параметры ovirt_env_name и elasticsearch_host в файле config.yml и сохраните файл. К файлу можно добавить следующие дополнительные параметры:
```
use_omelasticsearch _cert: false

rsyslog_elasticsearch_usehttps_metrics: !!str off

rsyslog_elasticsearch_usehttps_logs: !!str off
```
- Если используются сертификаты, установите параметр use_omelasticsearch_cert в значение true.
- Чтобы отключить журналы или метрики, используйте параметры:
  rsyslog _ elasticsearch _ usehttps _ metrics и/или rsyslog _ elasticsearch _ usehttps _ logs.

Разверните collectd и rsyslog на хостах:

/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh

Скрипт configure_ovirt_machines_for_metrics.sh запускает роль Ansible, которая включает в себя linux-system-roles, и использует её для развертывания и конфигурирования службы rsyslog на хосте. Rsyslog собирает метрики из службы collectd и отправляет их в Elasticsearch.

4.1.2.2. Схема журналирования и анализ журналов

Для интерактивного исследования данных, собранных из ПО «zVirt Max», используйте страницу Обнаружить (Discover). Каждый собранный набор результатов называется документом (document).

Сбор документов выполняется из следующих файлов журналов:

engine.log – содержит все отказы пользовательского интерфейса oVirt Engine, события поиска в Active Directory, проблемы баз данных и другие события.
vdsm.log – файл журнала для VDSM, агента Менеджера управления на хостах виртуализации, содержащий события, связанные с хостами.

Таблица 78. Доступны следующие поля:
Параметр	Описание
_ id	Уникальный идентификатор документа
_ index	Идентификатор индекса, которому принадлежит документ. Индекс с префиксом project.ovirt-logs является единственным, который имеет отношение к странице Обнаружить (Discover).
hostname	Для engine.log это имя хоста Менеджера управления. Для vdsm.log это имя хоста.
level	Уровень критичности записи в журнале: TRACE, DEBUG, INFO, WARN, ERROR, FATAL.
message	Тело сообщения, содержащегося в документе.
ovirt.class	Имя Java-класса, сгенерировавшего этот журнал.
ovirt.correlationid	Только для engine.log. Этот идентификатор используется для соотнесения нескольких частей одной задачи, выполняемой Менеджером управления.
ovirt.thread	Имя потока Java, внутри которого была создана запись в журнале.
tag	Заранее определенные наборы метаданных, которые можно использовать для фильтрации данных.
@timestamp	[ время ] (Troubleshooting#information-is-missing-from-kibana) создания записи.
_ score	—
_ type	—
ipaddr4	IP-адрес машины.
ovirt.cluster _ name	Только для vdsm.log. Имя кластера, которому принадлежит хост.
ovirt.engine _ fqdn	FQDN Менеджера управления.
ovirt.module _ lineno	Файл и номер строки в файле, которая запустила команду, определенную в ovirt.class.

4.1.3. Файлы журналов

4.1.3.1. Файлы журналов установки Менеджера управления

Таблица 79. Установка
Файл журнала	Описание
*/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.1.3.2. Файлы журнала Менеджера управления

Таблица 80. Обслуживание
Файл журнала	Описание
/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.1.3.3. Файлы журналов SPICE

Файлы журналов SPICE могут помочь при устранении проблем с подключениями SPICE. Для запуска отладки SPICE измените уровень журнала на отладку (debugging). Затем определите местонахождение журнала.

И клиенты, используемые для доступа к гостевым машинам, и сами гостевые машины имеют файлы журналов SPICE. Если клиент SPICE был запущен с использованием собственного клиента, для которого загружен файл console.vv, то для клиентских журналов используйте команду remote-viewer, чтобы включить отладку и сгенерировать вывод журнала.

4.1.3.4. Журналы SPICE для серверов SPICE гипервизора

Таблица 81. Журналы SPICE для серверов SPICE гипервизора
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала
Сервер SPICE хоста/гипервизора	/var/log/libvirt/qemu/(guest _ name).log	Выполните команду export SPICE _ DEBUG _ LEVEL=5 на хосте/гипервизоре до запуска гостевой машины. Парсинг этой переменной выполняет QEMU, и в случае запуска для всей системы будет напечатана отладочная информация обо всех виртуальных машинах в системе. Эту команду нужно запускать на каждом хосте в кластере. Эта команда работает только на уровне хоста/гипервизора, а не кластера.

4.1.3.5. Журналы SPICE для гостевых машин

Таблица 82. Журналы spice-vdagent для гостевых машин
Тип журнала	Местонахождение журнала	Чтобы изменить уровень журнала:
Гостевая машина Windows	C: \ Windows \ Temp \ vdagent.log C: \ Windows \ Temp \ vdservice.log	Не применимо
Гостевая машина Red Hat Enterprise 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.1.3.6. Журналы SPICE для клиентов SPICE, запущенных с использованием файлов console.vv

Для клиентских машин Linux:

Включите отладку SPICE, выполнив команду remote-viewer с параметром --spice-debug. После появления запроса введите URL-адрес для`подключения, например, spice://virtual_machine_IP:port.
```
remote-viewer --spice-debug
```
Чтобы запустить клиент SPICE с параметром отладки и передать ему файл c расширением .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.1.4. Файлы журналов хоста

Таблица 83. Файлы журналов хоста
Файл журнала	Описание
/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 или хоста RHEL 5 Xen, включая информацию об ошибках импорта. UUID – это UUID импортированной виртуальной машины, а Date – дата и время начала импортирования.
/var/log/vdsm/supervdsm.log	Регистрирует в журнале задачи VDSM, которые выполнялись с разрешениями суперпользователя.
/var/log/vdsm/upgrade.log	VDSM использует этот файл журнала во время обновлений хостов для регистрации изменений конфигурации.
/var/log/vdsm/mom.log	Регистрирует действия менеджера избыточного выделения памяти VDSM.

4.1.5. Настройка журналирования на уровень отладки для служб ПО «zVirt Max»

Журналы следующих служб ПО «zVirt Max» можно настроить на уровень отладки, изменив файл sysconfig каждой службы.

Таблица 84. Службы ПО «zVirt Max» и пути к файлам 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.1.6. Основные файлы конфигурации для служб ПО «zVirt Max»

В дополнение к файлу sysconfig, у каждой из этих служб ПО «zVirt Max» есть еще один файл конфигурации, который используется чаще.

Таблица 85. Службы ПО «zVirt Max» и файлы конфигурации
Служба	Путь к файлу 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.1.7. Настройка сервера журналирования хостов

Хосты генерируют и обновляют файлы журналов, записывая свои действия и проблемы. Централизованный сбор этих файлов журналов упрощает отладку.

Эту процедуру следует применять на централизованном сервере журналов. Можно использовать отдельный сервер журналирования, а можно применить эту процедуру, чтобы включить журналирование на хостах в Менеджере управления.

Процедура

Проверьте, разрешает ли межсетевой экран трафик через порт UDP 514 и открыт ли он для трафика службы syslog:
```
firewall-cmd --query-service=syslog
```
Если будет выведено нет (no), разрешите трафик через порт UDP 514, как показано ниже:
```
firewall-cmd --add-service=syslog --permanent
firewall-cmd --reload
```

Создайте на сервере syslog новый файл .conf (например, /etc/rsyslog.d/from_remote.conf) и добавьте следующие строки:

template(name="DynFile" type="string"
string="/var/log/%HOSTNAME%/%PROGRAMNAME%.log")

RuleSet(name="RemoteMachine") {  action(type="omfile"
dynaFile="DynFile") }

Module(load="imudp")

Input(type="imudp" port="514" ruleset="RemoteMachine")

Перезапустите службу rsyslog:
```
systemctl restart rsyslog.service
```
Авторизуйтесь на гипервизоре и в файл /etc/rsyslog.conf добавьте следующую строку:
```
 * .info;mail.none;authpriv.none;cron.none @ < syslog-FQDN > :514
```
Перезапустите службу rsyslog на гипервизоре.
```
systemctl restart rsyslog.service
```
Теперь централизованный сервер журналов настроен на получение и хранение сообщений (messages) и безопасных (secure) журналов с хостов виртуализации.

4.1.8. Включение SyslogHandler для передачи журналов Менеджера управления на удаленный сервер syslog

Данная реализация позволяет передавать записи журналов из engine.log и server.log на сервер syslog.

Настройка реализации SyslogHandler

Создайте файл конфигурации 90-syslog.conf в каталоге /etc/ovirt-engine/engine.conf.d и включите в него следующее содержимое:

SYSLOG _ HANDLER _ ENABLED=true SYSLOG _ HANDLER _ SERVER _ HOSTNAME=localhost SYSLOG _ HANDLER _ FACILITY=USER _ LEVEL
Установите и настройте rsyslog.
```
dnf install rsyslog
```
Настройте SELinux, чтобы разрешить трафик rsyslog.
```
semanage port -a -t syslogd_port -p udp 514
```
Создайте файл конфигурации /etc/rsyslog.d/rhvm.conf и добавьте следующее содержимое:
```
user. */var/log/jboss.log

module(load="imudp") # needs to be done just once

input(type="imudp" port="514")
```
Перезапустите службу rsyslog.
```
systemctl restart rsyslog.service
```
Если межсетевой экран включен и активен, выполните следующую команду, чтобы добавить необходимые правила для открытия портов rsyslog в Firewalld:
```
firewall-cmd --permanent --add-port=514/udp
firewall-cmd --reload
```
Перезапустите Менеджер управления.
```
systemctl restart ovirt-engine
```

Сервер syslog теперь может получать и хранить файлы engine.log.

4.1.9. Отчет о событиях безопасности

ПО zVirt Max предоставляет возможность собирать информацию, о различных событиях системы. Каждое событие имеет свой тип, критичность, описание, ассоциированный с ним обьект, например, хост или хранилище.

В отдельную группу с точки зрения критичности выделяют события безопасности, которые в свою очередь подразделяются на уровни:

Critical
Debug
Emergency
Fatal
High
Low
Meduim

Подробное описание уровней критичности представлено в таблице.

Таблица 86. Описание уровней критичности
Уровень	Описание
Critical	Критические ошибки системы виртуализации, которые необходимоу срочно устранить, могут приводит к отказу функционирование каких-либо компонент.
Debug	Выполнение отладки и тестирования компонент системы виртуализации, могут требовать выполнения определенных действий, например в случае неудачного входа в систему требуется проверить данные пользователя или обратиться к администратору.
Emergency	Аварийная ситуация или события требующие срочного исправления параметров и настроек системы виртуализации.
Fatal	Фатальные ошибки компонент системы виртуализации, приводящие к выходу из строя или свидетельствующие об отказе системы или его компонент.
High	События, связанные с изменением параметров и разрешений системы виртуализации, могут приводить к неправильному функционированию компонент. Например, возникают при повышении прав пользователей или изменении ролей.
Low	Уведомления о функцинировании отдельных компонент и рекомендации использовать определенные инструменты. Например если недоступно или не настроено полное резервное копирование, рекомендуется использовать engine-backup.
Meduim	События, связанные с изменением параметров и разрешений системы виртуализации, требующие выполнить определенные действия для улучшения функционирования системы. Например возникают после проверки обновлений или при необходимости установить недостающие пакеты.

Для получения отчетов о событии безопасности ПО zVirt Max использует API, что позволяет обращаются к отчетам через стандартный протокол передачи гипертекста (HTTP).

доступ к отчетам безопасности имеет пользователь типа «Администратор» с ролью «Администратор безопасности средства виртуализации (SecurityAdministratorVirtualizationTools)».

Для получения доступа необходимо в адресной строке браузера ввести значение следующего типа:

протокол:// FQDN_сервера c менеджером управления/security-report

Например: http:// zvirtvm.rockitsoft.local/security-report

Далее необходимо авторизоваться на портале и выбрать уровень события безопасности для получения отчета. После выбора уровня критичности события о безопасности, список событий соотвествующего уровня отобразиться на странице и его можно экспортировать в виде таблицы в формате .сsv.

В результате будет загружена таблица со следующей структурой, описание которой представлено в таблице.

Таблица 87. Описание структуры отчета в формате .csv
Индекс (Index)	Код (Code)	Автор (Author)	Время (Time)	Описание (Description)
Числовой индекс данного события. Индексы событий всегда возрастают, поэтому события с более высокими индексами гарантированно будут старше, чем события с меньшими индексами.	Предопределенный числовой индекс события описывающий событие созданное каким либо компонентом архитектуры.	Имя пользователя	Временная метка в формате: часы:минуты чч.мм.гггг	Текстовое описание произошедшего события.

Для отправки метрик и журналов за день на почту используется скрипт security-backup.sh. Данный скрипт анализирует содержимое базы данных событий audit_log, выбирает события безопасности и перессылает их в формате .csv на почту согласно указанным параметрам SMTP-сервера в файле send _ report.py.

4.2. Настройка передачи событий аудита на внешний syslog-сервер

4.2.1. Создание политики SELinux для доступа к файлам аудита

В системах с включенным и работающим в режиме enforcing модулем SELinux доступ демона syslog (например, rsyslogd) к файлам аудита /var/log/audit/audit.log по умолчанию запрещен. Это ограничение препятствует пересылке событий аудита на внешний сервер.

Для решения проблемы необходимо создать и установить модуль, реализующий минимальную политику, разрешающую только чтение необходимых файлов и каталогов. На сервере с SELinux в рабочей директории выполните следующие действия:

Создайте файл с исходным кодом модуля политики, определяющей правила доступа:

cat > zvirt-syslogd.te << __EOF__
module zvirt-syslogd 1.0;

require {
        type syslogd_t;
        type auditd_log_t;
        class dir { add_name getattr open read search };
        class file { getattr ioctl open read };
}

#============= syslogd_t ==============
allow syslogd_t auditd_log_t:dir { getattr open read search };
allow syslogd_t auditd_log_t:file { getattr ioctl open read };
__EOF__

Политика явно разрешает только операции чтения (read, getattr, open), что соответствует принципу минимальных привилегий.

Выполните компиляцию модуля:

checkmodule -M -m -o zvirt-syslogd.mod zvirt-syslogd.te

Убедитесь, что файл zvirt-syslogd.mod создан и имеет ненулевой размер:
```
ls -la zvirt-syslogd.mod
```

Создайте пакет модуля:

semodule_package -o zvirt-syslogd.pp -m zvirt-syslogd.mod

Установите модуль в системе:
```
semodule -i zvirt-syslogd.pp
```
Убедитесь, что модуль появился в списке. Он должен отображаться в выводе команды:
```
semodule -l | grep zvirt-syslogd
```
Перезапустите службу rsyslog для применения новых правил доступа SELinux:
```
systemctl restart rsyslog.service
```

4.2.2. Удаление политики SELinux для доступа к файлам аудита

Для удаления созданной политики выполните следующую команду:

semodule -r zvirt-syslogd

5. Безопасная настройка

Настройка ПО «zVirt Max» согласно требований к идентификации и аутентификации субъектов и объектов доступа (мера защиты ИАФ.1), к управлению идентификаторами (мера защиты ИАФ.3), к управлению средствами аутентификации (мера защиты ИАФ.4), к защите обратной связи при вводе аутентификационной информации (мера защиты ИАФ.5, мера защиты ИАФ.7), к управлению (заведение и уничтожение) учетных записей пользователей (мера защиты УПД.1), к реализации необходимых методов управления доступом, чтения и правил разграничения доступа (мера защиты УПД.2), к реализации ограничения числа параллельных сеансов доступа для каждой учетной записи (мера защиты УПД.9, в том числе в части усилений 2 и 3), к реализации блокирования сеанса доступа в ПО «zVirt Max» после установленного времени блокировки (мера защиты УПД.10, в том числе в части усилений 1б и 2) выполняются согласно пунктам 1.1.1. Роли и 3.3. Пользователи и роли Руководства администратора.

Настройка ПО «zVirt Max» согласно требованиям к определению состава и содержания информации о событиях безопасности, подлежащих регистрации (мера защиты РСБ.2) выполняются согласно пунктам 1.3.19. Поиск событий, 3.5. Уведомления о событиях и 4.1. Мониторинг и наблюдение Руководства администратора.

Настройка ПО «zVirt Max» согласно требованиям к сбору и записи информации о событиях безопасности (мера защиты РСБ.3) выполняются согласно пункту 4.1. Мониторинг и наблюдение Руководства администратора.

Настройка ПО «zVirt Max» согласно требованиям к идентификации иаутентификации субъектов доступа и объектов доступа в виртуальной инфраструктуре (мера защиты ЗСВ.1, в том числе в части усиления 1) выполняются согласно пунктам 1.1.6. Роли, 3.3. Пользователи и роли, Приложение D. zVirt Max и шифрованная связь Руководства администратора.

Настройка ПО «zVirt Max» согласно требованиям к управлению доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре (мера защиты ЗСВ.2, в том числе в части усилений 1 и 2) выполняются согласно пунктам 1.1.1. Роли и 3.3. Пользователи и роли Руководства администратора.

Настройка ПО «zVirt Max» согласно требований к регистрации событий безопасности в виртуальной инфраструктуре (мера защиты ЗСВ.3, в том числе в части усилений 1, 2 и 3) выполняются согласно пунктам 1.3.19.

Поиск событий, 3.5. Уведомления о событиях и 4.1. Мониторинг и наблюдение Руководства администратора.

Настройка ПО «zVirt Max» согласно требований к управлению потоками информации между компонентами виртуальной инфраструктуры (мера защиты ЗСВ.4, в том числе в части усилений 1 и 2) выполняются согласно пунктам 2.4.1.2. Создание новой логической сети в центре данных или кластере и 2.9.2.7. Добавление Open Virtual Network (OVN) в качестве внешнего провайдера сети Руководства администратора.

Настройка ПО «zVirt Max» согласно требований к управлению перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных (мера защиты ЗСВ.6, в том числе в части усилений 1, 2 и 5) выполняются согласно пунктам 2.6.6.2. Добавление хранилища iSCSI, 2.6.6.6. Добавление хранилища FCP, 2.6.9.4. Изменение доменов хранения, 2.6.9.14. Установка флажка "Сброс после удаления (Discard After Delete)" для домена хранения Руководства администратора и пунктов 5.3. Виртуальные диски, 6.7. Моментальные снимки, 6.12. Миграция виртуальных машин между хостами, 7. Шаблоны Руководства пользователя.

Настройка ПО «zVirt Max» согласно требованиям к резервному копированию данных в виртуальной инфраструктуре (мера защиты ЗСВ.8, в том числе в части усилений 1, 2 и 3) выполняются согласно пункту 3.2. Резервные копии и миграция Руководства администратора.

Настройка ПО «zVirt Max» согласно требованиям к разбиению виртуальной инфраструктуры на сегменты (мера защиты ЗСВ.10, в том числе в части усилений 1 и 2) выполняются согласно пункту 2.4. Логические сети Руководства администратора.

Приложение A: VDSM и хуки

A.1. VDSM

Менеджер управления использует службу VDSM для управления хостами. Служба VDSM управляет и ведет мониторинг хранилища, памяти и сетевых ресурсов хоста. Кроме того, она координирует создание виртуальных машин, сбор статистики, сбор журналов и другие задачи по администрированию хостов.

VDSM работает как сервис на каждом хосте под управлением Менеджера управления и отвечает на XML-RPC запросы от клиентов. Менеджер управления функционирует как клиент VDSM.

A.2. Хуки VDSM

Службу VDSM можно расширить с помощью хуков. Хуки – это скрипты, выполняемые на хосте при наступлении ключевых событий. При наступлении предусмотренного события служба VDSM запускает любые исполняемые скрипты хуков в /usr/libexec/vdsm/hooks/nn_event-name/ на хосте в порядке, определяемом их буквенно-цифровыми идентификаторами. Как правило, каждому скрипту хука присвоено двузначное число, которое стоит в начале имени файла, чтобы четко указать, в каком порядке будут выполняться скрипты. Скрипты хуков можно писать на любом языке программирования, но данном приложении представлены примеры на Python.

Обратите внимание, что выполняются все скрипты, заданные на хосте для события. Если требуется, чтобы один конкретный хук выполнялся только для определенного подмножества виртуальных машин, работающих на хосте, то убедитесь, что скрипт хука отвечает этому требованию, а для этого надо использовать Пользовательские свойства (Custom Properties), ассоциированные с этой виртуальной машиной.

Хуки VDSM могут мешать работе ПО «zVirt Max». Ошибка в хуке 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

A.5. Предусмотренные события VDSM

Таблица 88. Предусмотренные события 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 см. на веб-сайте http://libvirt.org/formatdomain.html.

Идентификатор UUID виртуальной машины можно логически вывести из XML-представления домена, а также получить из переменной среды vmId.

A.8. Установка пользовательских свойств

Пользовательские свойства, принятые Менеджером управления, и соответственно передаваемые пользовательским хукам, можно задать с помощью команды engine-config. Выполните команду от имени root-пользователя на том хосте, на котором установлен Менеджер управления.

Ключи конфигурации UserDefinedVMProperties и CustomDeviceProperties применяются для хранения имен поддерживаемых пользовательских свойств. Регулярные выражения, задающие допустимые значения для каждого именованного пользовательского свойства, тоже содержатся в этих ключах конфигурации.

Пользовательские свойства отделяются друг от друга точкой с запятой.

Обратите внимание, что при настройке ключа конфигурации все уже содержащиеся в нем значения будут перезаписаны. При комбинировании новых и уже существующих пользовательских свойств необходимо добавить все пользовательские свойства, которые в команде задавали значение ключа.

После обновления ключа конфигурации необходимо перезапустить службу ovirt-engine, чтобы новые значения вступили в силу.

Пример. Свойства виртуальной машины: установка пользовательского свойства смарт-карта (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 ] {plus}$ version: 4.4
```
Поскольку пользовательское свойство память (memory) уже задано в ключе конфигурации UserDefinedVMProperties, новое пользовательское свойство должно быть добавлено к нему. Дополнительное пользовательское свойство смарт-карта (smartcard) добавляется к значению ключа конфигурации. Новое пользовательское свойство может принимать значения true или false.
```
engine-config -s UserDefinedVMProperties='memory=^ [ 0-9 ] {plus}$;smartcard=^(true | false)$'
--cver=4.4
```

Убедитесь, что пользовательские свойства, заданные ключом конфигурации UserDefinedVMProperties, были обновлены корректно.

engine-config -g UserDefinedVMProperties

UserDefinedVMProperties: version: 4.3

UserDefinedVMProperties: version: 4.4

UserDefinedVMProperties :
memory=^ [ 0-9 ] {plus}$;smartcard=^(true | false)$ version: 4.4

В конце требуется перезапустить службу ovirt-engine, чтобы изменения конфигурации вступили в силу.
```
systemctl restart ovirt-engine.service
```

Пример. Свойства устройств: установка пользовательского свойства интерфейс (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) предоставляет возможность выбирать из списка заданных пользовательских свойств. После выбора ключа пользовательского свойства появится дополнительное поле, в котором можно задать значение этого ключа. Нажимая + и -, добавляйте или удаляйте пары ключ/значение.

A.10. Оценка пользовательских свойств на виртуальных машинах в хуке VDSM

Каждый набор ключей в поле Пользовательские свойства (Custom Properties) для виртуальной машины добавляется как переменная среды при вызове скриптов хука. Хотя регулярные выражения, используемые для проверки поля Пользовательские свойства (Custom Properties) дают некоторую защиту, необходимо убедиться, что скрипты также проверяют вводимые данные на соответствие ожиданиям.

Пример.Оценка пользовательских свойств

Далее в коротком примере на языке 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.10.1. Использование модуля хукинга VDSM

VDSM поставляется с модулем хукинга Python, в котором предоставлены вспомогательные функции для скриптов хука VDSM. Этот модуль предоставляется в качестве примера и касается только хуков VDSM, написанных на Python.

Модуль хукинга поддерживает чтение XML-представления libvirt виртуальной машины в объект DOM. Затем скрипты хуков могут использовать встроенную в Python библиотеку xml.dom для работы с объектом.

Измененный объект можно затем сохранить обратно в XML-представление libvirt с помощью модуля хукинга.

Модуль хукинга предоставляет следующие функции для поддержки разработки хуков:

Таблица 89. Функции модуля хукинга
Имя	Аргумент	Описание
`tobool`	строка	Конвертирует строку "true" или "false" в логическое значение
`read_domxml`	-	Считывает XML-представление libvirt виртуальной машины в объект DOM
`write_domxml`	объект DOM	Записывает XML-представление libvirt виртуальной машины из объекта DOM

A.11. Выполнение хуков VDSM

Скрипты before_vm_start могут изменить XML-представление домена, чтобы изменить определение настроек VDSM виртуальной машины до того, как оно достигнет libvirt. При этом необходимо проявлять осторожность.

Скрипты хуков способны нарушить работу VDSM, а дефектные скрипты могут привести к сбоям ПО «zVirt Max». В частности, никогда не изменяйте идентификатор UUID домена и не пытайтесь удалить устройство из домена без достаточных знаний и опыта.

Оба скрипта хуков before_vdsm_start и after_vdsm_stop выполняются от имени root-пользователя. Остальные скрипты хуков, для которых требуется root-доступ в систему, должны быть записаны, чтобы использовать команду sudo для повышения привилегий. Для этого необходимо обновить /etc/sudoers, чтобы позволить пользователю vdsm использовать команду sudo без повторного введения пароля. Это необходимо, т.к. скрипты хуков выполняются не в интерактивном режиме.

Пример.Конфигурирование команды 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.12. Коды возврата хука VDSM

Скрипты хуков должны возвращать один из кодов возврата, как показано в таблице Коды возврата хуков. Код возврата определяет, будут ли дальнейшие скрипты хуков обрабатываться VDSM.

Таблица 90. Коды возврата хука
Код	Описание
0	Скрипт хука успешно выполнен
1	Скрипт хука завершился сбоем, необходимо обработать другие хуки
2	Скрипт хука завершился сбоем, другие хуки не обрабатывать
> 2	Зарезервировано

A.13. Примеры хуков VDSM

Примеры скриптов хуков, представленные в этом разделе, необязательно поддерживаются. Убедитесь, что абсолютно все скрипты хуков, установленные в системе, независимо от источника, тщательно протестированы для работы в вашей среде.

Пример.Настройка узлов NUMA

Цель:

Этот скрипт хука позволяет настраивать выделение памяти на хосте NUMA на основании пользовательского свойства numaset. Если пользовательское свойство не задано, то ничего не произойдет.

Строка конфигурирования:

numaset=^(interleave | strict | preferred): [\ ^ ] ? \ d{plus}(- \ d{plus})?(, [\ ^ ] ? \ d{plus}(- \  {plus})?) * $

Используемое регулярное выражение позволяет пользовательскому свойству 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

Таблица 91. Параметры 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 Max»

C.1. Общие сведения о плагинах пользовательского интерфейса ПО «zVirt Max»

ПО «zVirt Max» поддерживает плагины, предоставляющие нестандартные функции. Это упрощает использование Портала администрирования для интеграции с другими системами. Каждый плагин интерфейса представляет собой набор расширений пользовательского интерфейса, которые могут упаковываться и распространяться для использования с ПО «zVirt Max».

Плагины пользовательского интерфейса ПО «zVirt Max» интегрируются с Порталом администрирования прямо на клиенте с помощью языка программирования JavaScript. Плагины вызываются Порталом администрирования и выполняются в среде выполнения JavaScript в веб-браузере. Плагины пользовательского интерфейса могут использовать язык JavaScript и его библиотеки.

Если во время выполнения наступают какие-либо ключевые события, Портал администрирования вызывает отдельные плагины с помощью функций обработчика событий, обеспечивающих связь между Порталом администрирования и плагином. Хотя Портал администрирования поддерживает несколько функций обработчика событий, плагин декларирует только те функции, который представляют интерес с точки зрения его реализации.

Каждый плагин должен зарегистрировать соответствующие функции обработчика событий в ходе начальной загрузки, прежде чем плагин будет использоваться Порталом администрирования.

Чтобы облегчить взаимодействие между плагином и Порталом администрирования, в результате которого запускается расширение пользовательского интерфейса, Портал администрирования предоставляет API плагина как глобальный (верхнеуровневый) объект pluginApi JavaScript, который могут использовать отдельные плагины. Каждый плагин получает отдельный экземпляр pluginApi, что позволяет Порталу администрирования управлять вызовом API-функций каждого плагина на протяжении его жизненного цикла.

C.2. Жизненный цикл плагина пользовательского интерфейса ПО «zVirt Max»

Основной жизненный цикл плагина пользовательского интерфейса делится на три стадии:

Обнаружение плагина.
Загрузка плагина.
Начальный запуск плагина.

C.2.1. Обнаружение плагина пользовательского интерфейса ПО «zVirt Max»

Создание дескрипторов плагинов – первый шаг процесса обнаружения плагинов. Дескрипторы плагинов содержат важные метаданные плагинов и необязательные конфигурации по умолчанию для конкретных плагинов.

В рамках обработки запросов к 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 Max»

После обнаружения плагина и встраивания его данных в HTML-страницу Портала администрирования Портал администрирования пытается загрузить плагин при запуске приложения (если только он не настроен так, чтобы не загружаться при запуске приложения).

Для каждого обнаруженного плагина Портал администрирования создает элемент HTML iframe, используемый для загрузки его хост-страницы. Хост-страница плагина необходима для инициации процесса начального запуска плагина, и этот процесс начального запуска используется для оценки кода плагина в контексте плагина элемента iframe. Инфраструктура плагинов пользовательского интерфейса поддерживает обслуживание ресурсных файлов плагина (таких как хост-страница плагина) из локальной файловой системы. Хост-страница плагина загружается в элемент iframe, и код плагина подвергается оценке. После оценки кода плагина он связывается с Порталом администрирования посредством API плагина.

C.2.3. Начальный запуск плагина пользовательского интерфейса ПО «zVirt Max»

Типовой процесс начального запуска состоит из следующих шагов:

Процесс начального запуска плагина

Получить экземпляр 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. Файлы, относящиеся к плагинам пользовательского интерфейса, и пути к этим файлам

Таблица 92. Файлы, относящиеся к плагинам пользовательского интерфейса, и пути к этим файлам
Файл	Путь	Примечания
Файлы дескрипторов плагинов (метаданные)	/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! успешно реализован, то при авторизации на Портале администрирования вы увидите этот экран:

Рисунок 14. Успешная реализация плагина Hello World!

Приложение D: ПО «zVirt Max» и шифрованная связь

D.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 Max» необходимо выполнить все шаги этой процедуры.

Замена сертификата Менеджера управления, выданного Центром Сертификации Apache

Если используется служба hosted engine, переведите среду в глобальный режим обслуживания.
```
hosted-engine --set-maintenance --mode=global
```
Дополнительную информацию см. в Разделе 3.1.1. Обслуживание 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-трафика.

D.1.1. Настройка шифрованной связи между Менеджером управления и 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, см. раздел 3.3.3. Настройка внешнего провайдера LDAP. Чтобы продолжить настройку LDAP и Kerberos для единого входа, см. раздел 3.3.4. Настройка LDAP и Kerberos для единого входа.

Приложение E: Прокси-серверы

E.1. SPICE-прокси

E.1.1. Общие сведения о SPICE-прокси

SPICE-прокси – это инструмент, используемый для подключения клиентов SPICE к виртуальным машинам, когда клиенты SPICE находятся вне сети, соединяющей гипервизоры. Настройка SPICE-прокси заключается в установке Squid на машину и настройке межсетевого экрана на пропускание прокси-трафика. Включение SPICE-прокси заключается в использовании engine-config в Менеджере управления для установки ключа SpiceProxyDefault в значение, состоящее из имени и порта прокси-сервера. Выключение SPICE-прокси заключается в использовании engine-config в Менеджере управления для удаления значения, в которое был установлен ключ SpiceProxyDefault.

SPICE-прокси можно использовать только в сочетании с автономным клиентом SPICE и нельзя использовать для подключения к виртуальным машинам с помощью noVNC.

E.1.2. Настройка машины со SPICE-прокси

В этой процедуре описано, как настроить машину в качестве SPICE-прокси. SPICE-прокси позволяет подключаться к сети zVirt Max извне. В этой процедуре используется 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 Max извне этой сети активируйте SPICE-прокси.

E.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 Max через SPICE-прокси.

E.1.4. Выключение SPICE-прокси

Далее описано, как выключить (деактивироваать) SPICE-прокси.

Порядок действий:

Авторизуйтесь в Менеджере управления:
```
$ ssh root@_[IP of {engine-name}]_
```
Чтобы очистить SPICE-прокси, запустите следующую команду:
```
engine-config -s SpiceProxyDefault=""
```
Перезапустите Менеджер управления:
```
systemctl restart ovirt-engine.service
```

Теперь SPICE-прокси деактивирован (выключен). Больше нельзя подключиться к сети zVirt Max через SPICE-прокси.

E.2. Squid-прокси

E.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).

E.3. Websocket-прокси

E.3.1. Общие сведения о Websocket-прокси

Websocket-прокси позволяет пользователям подключаться к виртуальным машинам через консоль noVNC.

Websocket-прокси можно установить и настроить на машине с Менеджером управления во время первоначальной настройки (см. Настройка Менеджера управления).

Приложение F: Адаптация оформления (брендинг)

F.1. Адаптация оформления (брендинг)

F.1.1. Адаптация оформления Менеджера управления

Разные аспекты Менеджера управления можно настроить на свой вкус, например, значки и текст во всплывающих окнах, а также ссылки на странице приветствия. Это позволяет точечно адаптировать внешний вид Менеджера управления и довести его до того состояния, в котором он в итоге будет представлен администраторам и пользователям.

Файлы, необходимые для кастомизации Менеджера управления, находятся в каталоге /etc/ovirt-engine/branding/ в системе, на которой установлен Менеджер управления. Эти файлы включают в себя набор файлов каскадных таблиц стилей для оформления различных аспектов графического интерфейса пользователя и набор файлов свойств, которые содержат сообщения и ссылки, включенные в различные компоненты Менеджера управления.

Чтобы адаптировать компонент, измените файл этого компонента и сохраните изменения. В следующий раз, когда вы откроете или обновите этот компонент, изменения будут видны.

F.1.2. Экран авторизации

На Портале администрирования и Пользовательском портале используется один и тот же экран авторизации. На экране авторизации можно настроить следующие элементы:

границу
основное изображение сверху слева
основное изображение сверху справа
основной текст

Классы для экрана авторизации находятся в common.css.

F.1.3. Экран Портала администрирования

Экран Портала администрирования – это главный экран, который отображается при авторизации на Портале администрирования. На экране Портала администрирования можно настроить следующие элементы:

логотип
фоновое изображение слева
фоновое изображение по центру
фоновое изображение справа
текст справа от логотипа

Классы для экрана Портала администрирования находятся в web_admin.css.

F.1.4. Экран Пользовательского портала

Экран Пользовательского портала отображается при авторизации на Пользовательском портале. На экране Пользовательского портала можно настроить следующие элементы:

логотип
фоновое изображение по центру
фоновое изображение справа
границу вокруг основной сетки
текст над плашкой Авторизовавшийся пользователь (Logged in user)

Классы для экрана Пользовательского портала находятся в user_portal.css.

F.1.5. Всплывающие окна

Всплывающие окна – это все окна в Менеджере управления, в которых можно создавать, изменять или обновлять такие сущности как хосты или виртуальные машины. Во всплывающих окнах можно настроить следующие элементы:

границу
основное изображение сверху слева
основное изображение сверху в центре (повторяющееся)

Классы для всплывающих окон находятся в common.css.

F.1.6. Вкладки

Во многих всплывающих окнах на Портале администрирования есть вкладки. Во вкладках можно настроить следующие элементы:

Активный
Неактивный

Классы для вкладок находятся в common.css и user_portal.css.

F.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, пользовательский баннер сообщений необходимо восстановить и проверить вручную.

F.1.8. Страница "Страница не найдена"

Страница "Страница не найдена" – это страница, которая отображается при открытии ссылки на страницу, которую невозможно найти в Менеджере управления. На странице "Страница не найдена" можно настроить следующие элементы:

заголовок страницы
основное изображение сверху (слева, в центре и справа)
сообщение об ошибке
ссылка переадресации и сообщение, привязанное к этой ссылке

Классы для страницы "Страница не найдена" находятся в welcome_style.css.

Приложение G: Системные учетные записи

G.1. Учетные записи пользователей Менеджера управления

При установке ПО «zVirt Max» создается ряд учетных записей системных пользователей для поддержки ПО «zVirt Max». Каждый системный пользователь имеет идентификатор пользователя, присваиваемый по умолчанию (UID). Создаются следующие учетные записи системных пользователей:

Пользователь vdsm (UID 36). Требуется для инструментов поддержки, которые монтируют домены хранения NFS и обращаются к ним.
Пользователь ovirt (UID 108). Владелец экземпляра Wildfly ovirt-engine.
Пользователь ovirt-vmconsole (UID 498). Требуется для гостевой консоли, подключаемой по последовательному интерфейсу

G.2. Группы Менеджера управления

При установке ПО «zVirt Max» создается ряд групп системных пользователей для поддержки ПО «zVirt Max». Каждая группа системных пользователей имеет идентификатор группы, присваиваемый по умолчанию (GID). Создаются следующие группы системных пользователей:

Группа kvm (GID 36). Члены группы:
- Пользователь vdsm.
Группа ovirt (GID 108). Члены группы:
- Пользователь ovirt.
Группа ovirt-vmconsole (GID 498). Члены группы:
- Пользователь ovirt-vmconsole.

G.3. Учетные записи хоста виртуализации

При установке пакетов vdsm и qemu-kvm на хосте виртуализации создается ряд учетных записей системных пользователей. Каждый системный пользователь имеет идентификатор пользователя, присваиваемый по умолчанию (UID). Создаются следующие учетные записи системных пользователей:

Пользователь vdsm (UID 36).
Пользователь qemu (UID 107).
Пользователь sanlock (UID 179).
Пользователь ovirt-vmconsole (UID 498).

Присваиваемые идентификаторы пользователей (UID) и идентификаторы групп (GID) могут варьироваться от системы к системе. За пользователем vdsm зарезервирован UID 36, а за группой kvm зарезервирован GID 36.

Если UID 36 или GID 36 уже используется другой учетной записью в системе, то при установке пакетов vdsm и qemu-kvm-rhev возникнет конфликт.

G.4. Группы хостов виртуализации

При установке пакетов vdsm и qemu-kvm на хосте виртуализации создается ряд групп системных пользователей. Каждая группа системных пользователей имеет идентификатор группы, присваиваемый по умолчанию (GID). Создаются следующие группы системных пользователей:

Группа kvm (GID 36). Члены группы:
- Пользователь qemu.
- Пользователь sanlock.
Группа qemu (GID 107). Члены группы:
- Пользователь vdsm.
- Пользователь sanlock.
Группа ovirt-vmconsole (GID 498). Члены группы:
- Пользователь ovirt-vmconsole.

Если UID 36 или GID 36 уже используется другой учетной записью в системе, то при установке пакетов vdsm и qemu-kvm-rhev возникнет конфликт.

G.5. Системные роли

В таблице описаны дополнительные роли в соотвествии с требованиями по безопасности информации к средствам виртуализации ФСТЭК России в ПО «zVirt Max».

Таблица 93. Роли безопасности
Роль	Тип	Права
VirtualMachineDeveloper	User	Настройка системы, настройка прав на вход в систему,создание виртуальных машин, изменение конфигурации виртуальных машин, настройка дисков и предоставление доступа к ним.
SecurityAdministratorVirtualizationTools	Admin	Доступ на чтение к журналу событий безопасности средства виртуализации; формирование отчетов с учетом заданных критериев отбора, выгрузка(экспорт) данных из журнала событий безопасности.
VirtualizationToolAdministrator	Admin	Создание и управление учетными записями пользователей; назначение прав доступа пользователям к виртуальным машинам; создание, удаление и изменение виртуального оборудование; изменение конфигурации виртуального оборудования; управление доступом виртуальных машин к физическому и виртуальному оборудованию; управление квотами доступа виртуальных машин к физическому и виртуальному оборудованию; управление перемещением виртуальных машин; удаление,запуск и остановка виртуальных машин; создание снимков состояния виртуальных машин, включающих файл конфигурации виртуальной машины, образа виртуальной машины и образа памяти виртуальной машины.
VirtualMachineAdministrator	User	Доступ пользователя средства виртуализации к виртуальной машине посредством интерфейса средства виртуализации.

Параметры ролей пользователей можно посмотреть в вкладке Управление → Настройка → Роли. В данном пункте меню роли сгруппированы по типу, роли администраторов или роли пользователей.

Просмотр параметров ролей

system roles

Параметры отдельной роли можно посмотреть в пункте Изменить роль.

Параметры роли

role parametr