Меню

Ovirt установка и настройка



Установка Ovirt в режиме Hosted Engine

В данной статье рассматривается развертывание среды виртуализации Ovirt 4.1 с хранилищем, реализованным на базе NFS.

Содержание

Системные требования к оборудованию [ править ]

  • ЦПУ, поддерживающий виртуализацию. Минимум 2 ядра.
  • ОЗУ минимум 8 Гб.
  • Свободное дисковое проcтранство на одном из разделов минимум 60 Гб.

Системные требования к ПО [ править ]

  • Чистая установка ОС AlterOS 7.5
  • Подготовленные FQDN имена для хоста и виртуальной машины, выполняющей роль Engine. В нашем случае host.alter.os и engine.alter.os соответственно.
  • Записи в зонах прямого и обратного просмотра для этих имен на DNS сервере.

Подготовка [ править ]

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

Проверяем наличие поддержки со стороны процессора:

Если команда ничего не вернет, на ПК отсутствует поддержка виртуализации или она отключена в настройках БИОС. Сам KVM поставить на такой ПК можно, но при попытке ввести команду управления гипервизором мы получим ошибку «WARNING KVM acceleration not available, using ‘qemu’». В таком случае необходимо перезагрузить ПК, войти в БИОС, найти поддержку технологии виртуализации (Intel VT или AMD-V) и включить ее.

Устанавливаем в систему репозиторий Ovirt 4.1:

Проверяем доступность необходимых репозиториев:

Видим, что репозитории ovirt-4.1-centos-gluster38/x86_64 и ovirt-centos-ovirt41/x86_64 недоступны (у них в столбце Состояние указан 0):

Для продолжения установки необходимо в файле /etc/yum.repos.d/ovirt-4.1-dependencies.repo разделы для недоступных репозиториев привести к виду:

Жирным шрифтом выделены измененные символы. Еще раз проверяем доступность репозиториев. Теперь все репозитории долны быть доступны:

Устанавливаем пакет ovirt-hosted-engine-setup:

Устанавливаем пакет ovirt-engine-appliance (может занять продолжительное время):

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

Буква “N” или “0” означает, что вложенная виртуализация выключена. Чтобы ее включить нужно выгрузить модуль и загрузить его с параметром kvm_intel.nested=1. Выгружаем модуль и загружаем с нужным параметром:

Проверяем включение вложенной виртуализации:

При постоянном использовании следует данные параметры ввести в автозагрузку, для этого приводим файл /etc/rc.local к виду:

И т.к. в AlterOS-7.5 этот файл по умолчанию не является исполняемым, то нам необходимо его сделать таковым:

Приводим файл /etc/hosts к виду:

Здесь host.alter.os — имя ПК, на котором выполняются данные действия. engine.alter.os — имя будущей виртуальной машины, выполняющей роль engine. IP адреса и имена указаны в качестве примера. В вашем случае они, скорее всего, будут другими. Так же, эти данные должны четко соостветствовать записям в зонах прямого и обратного просмотра на DNS сервере.

Приводим файл /etc/sysconfig/network к виду:

Приводим файл сетевого интерфейса, к которому подключен сетевой кабель, /etc/sysconfig/network-scripts/ifcfg-enp1s0 (в вашем случае он может иметь другое имя)к виду:

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

Перезапускаем службу сети:

Добавляем группу kvm и в ней пользователя vdsm:

Устанавливаем службу NFS:

Создаем каталоги для NFS хранилища. Данные каталоги должны находиться на разделе, имеющем минимум 60 Гб свободного пространства. В данном случае это раздел /home:

Добавляем сведения об этих каталогах в файл /etc/exports. Вносим в него строки:

Перезагружаем службу NFS:

Задаем владельца и группу для созданных каталогов:

Задаем необходимые разрешения для созданных каталогов:

Развертывание [ править ]

На все вопросы отвечаем значениями по умолчанию (жмем Enter), кроме следующих:

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

Доступ на веб-интерфейс для управления Ovirt осуществляется в данном случае по ссылке https://engine.alter.os/ovirt-engine. (Этот адрес предварительно добавляем в исключения браузера). В качества имени пользователя используем admin, в качества пароля — пароль заданный на стадии развертывания.

Если по какой-то причине процесс развертывания завершился с ошибкой, то возобновить его можно только после выполнения скрипта /usr/share/ovirt-hosted-engine-setup/scripts/ovirt-hosted-engine-cleanup и очистки каталога /home/vdsm/data.

Источник

oVirt часть 3. Установка

oVirt. все статьи цикла

Для того что бы попробовать все возможности oVirt, необходимы минимум три сервера, один для управления (Engine), и он же в качестве общего хранилища для оставшихся двух гипервизоров (Nodes). При чем для гипервизоров необходима поддержка аппаратной виртуализации для работы KVM.
Те, кому приходилось работать с VMware vSphere, возможно подумают, что первым делом можно установить гипервизор, а затем на нем же развернуть Engine в качестве ВМ. До не давнего времени oVirt не поддерживала такой сценарий и Engine требовал отдельного сервера или ВМ вне oVirt.
Начиная с версии 3.4 развертывание Engine в ВМ на одном из гипервизоров стало возможным. Этот трюк именуется как Hosted Engine и довольно не тривиален. В рамках этой статьи будет рассматриваться классическая модель с отдельно стоящим сервером управления.

Примечание: Очень важно что бы на обслуживающем DNS-сервере существовали записи (как прямые так и обратные) для всех используемых в инфраструктуре серверов!

Установка сервера управления (oVirt Engine)

Минимально рекомендуемые параметры сервера выглядят так: 2хCPU\4Gb RAM\25 HDD\1Gbs Ethernet. В рамках тестирования можно обойтись в половину меньшим.
В качестве ОС подойдут Fedora 19 или CentOS 6.5. Я использую вторую, поэтому рассказ будет строиться на ее примере.

Первым делом необходимо подключить нужные репозитории.

Следом репозиторий oVirt:

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

Теперь можно выполнить полное обновление системы если это еще не сделано, а можно просто приступить к установке Engine:

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

Первичная настройка

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

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

Читайте также:  Настройка экспозиции с внешней вспышкой

Default storage type (NFS, FC, ISCSI, POSIXFS) [NFS]:

Если общего хранилища у вас нет то вариант по умолчанию (NFS) наиболее простой и удобный.

Когда все данные будут введены и процесс конфигурирования завершится, в разделе SUMMARY, среди прочего будут указанны адреса входа в веб-консоль:

Установка вычислительных узлов (oVirt Nodes)

Системные требования здесь простые: чем больше и мощнее — тем лучше. Ведь от объема ресурсов на прямую зависит количество и производительность ВМ. В качестве ОС все те же Fedora 19 и CentOS 6.5.

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

Источник

Установка oVirt

Большая часть наших статей в «Точке Росы» была посвящена нашим десктопным системам. Однако в последнее время мы более активно стараемся развивать и серверное направление. В связи с чем в августе нами была обучена группа специалистов одного очень известного и уважаемого системного интегратора.

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

И мы были рады, когда один из наших слушателей, Черятников Виталий, написал цикл статей «Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6» ([1], [2], [3], [4]).

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

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

Содержание

Установка системы управления виртуализацией Ovirt 3.5 в доменной среде IPA на базе ROSA Enterprise Server 6.6

В рамках работ по одному проекту столкнулся с интересной вещью под названием Ovirt 3.5.3 — это некий аналог Virtual Machine Manager, но на мой взгляд он ближе по идеологии к vSphere, так как реализует механизмы failover и cluster на уровне продукта управления виртуализацией, а не ОС гипервизора (как HYPER-V Failover Cluster).

Базировалось всё на отечественной ROSA Enterprise Linux Server 6.6 (RELS 6.6, кстати, RELS очень интересен тем, что в основе лежит Red Hat).

Опыт интересен тем, что даёт некий аналог тяжелым решениям VMWare и Microsoft в рамках импортозамещения. Ниже я коротко расскажу о установке продукта Ovirt в среде RELS с реализацией механизма аутентификации и авторизации на базе IPA, но хочу оговориться, что для меня данная реализация проекта на *nix — скорее экзотика, чем каждодневная реальность, ибо Microsoft — наше всё, посему заранее прошу прощения за огрехи, если таковые допущу.

Коротко о выборе

Во-первых почему IPA:

  • по информации от архитектора RELS, с которым мы работали, IPA — это основное направление для Red Hat Community в части аутентификации и авторизации. То есть продукт можно использовать в длительном периоде времени с расчётом на поддержку. Мне, как человеку, привыкшего работать с Active Directory понравился предлагаемый функционал и интерфейс (конечно везде есть отличия, но всё же);
  • IPA — полноценное продуктивное решение с очень неплохим уровнем документированности; Лично я, для прояснения многих аспектов использовал официальную документацию Red Hat
  • IPA позволяет использовать динамический DNS сервер и формировать SSO окружение клиент-сервер — легко;
  • Это рекомендованное решение для интеграции с Ovirt 3.5;
  • А, и конечно, фраза, которую любят говорить *nix’оводы: оно уже входит в дистрибутив RELS и поддерживается командой ROSA.

Во-вторых, выбор платформы реализации серверной инфраструктуры:

  • Выбор производился между сертифицированными ФСТЭК отечественными ОС (для справки, существуют: МСВС Линукс, Astra Linux — крайне закрытые платформы, на мой субъективный взгляд; ALT Linux — известен многим и достаточно неплох);
  • RELS понравился дружелюбием к системам в окружающем мире при интеграции;
  • Активная жизненная позиция команды разработчиков :), в частности Константина Калмыкова;
  • RELS использует KVM для виртуализации.

В-третьих, управление виртуализацией, и да, опять — Ovirt 3.5 входит в состав ROSA Linux и так же, как и сам RELS, поддерживается командой разработчиков.

Установка IPA

Выполняем обновление пакетов

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

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

если столкнётесь с Warning на скриншоте ниже — не обращайте внимания (насколько я понял — стандартное предупреждение).

Затем установим сам IPA сервер:

После установки пакетов я проверяю содержимое /etc/hosts (это необходимое условие для работы IPA сервера).

В моем случае это выглядит так:

Перед установкой IPA сервера убедитесь, что hostname сервера у Вас задано строчными буквами, см. скриншот ниже — иначе система ругается.

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

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

Затем откройте браузер и соединитесь с узлом, на котором развернут IPA сервер по HTTP или HTTPS. Теперь можно работать со службой каталогов.

Как видите, DNS сервер в IPA самостоятельно и корректно делает записи типа SRV (аналогично А, PTR).

Добавляем рядовой сервер в домен:

ПРИМЕЧАНИЕ! Поскольку данный пример делался на стенде с одним сервером IPA строка не имела значения — я предпочёл настроить на конкретный сервер; однако для обеспечения failover клиента ipa на резервный сервер службы, в случае выхода из строя мастер-сервера службы каталогов, требуется другая конфигурация (о чём говорит сообщение на скриншоте).

После добавления рядового сервера в домен, командой ниже, необходимые записи так же появились в службе каталога. На скриншоте выше см. IPv4 10.5.102.168 и FQDN в зоне прямого просмотра ovi01.rosa.demo

Читайте также:  Настройка вайфая для игр

Установка Ovirt 3.5

Перед развёртыванием Ovirt на сервере RELS 6.6 запустите

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

После выполните команду настройки и пройдите все пункты мастера #engine-setup

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

Подтверждаем и ожидаем окончания установки

Интеграция Ovirt 3.5 с IPA Server

Теперь необходимо выполнить команду интеграции Ovirt 3.5 со службой каталога IPA.

ПРИМЕЧАНИЕ! Данная версия Ovirt имеет только одного локального пользователя — admin (создание других локальных пользователей не предусмотрено).

Всех остальных пользователей она получает из службы каталога (кстати есть возможность интеграции и с Microsoft Active Directory — расскажу о нюансах в другой статье цикла).

В ситуации по-умолчанию Вы получите ошибку ниже:

Дело в том, что, по-умолчанию, OVirt 3.5 требует значение равное 1 параметра minssf сервера IPA, собственно сервер IPA, после установки, имеет значение параметра равное 0.

Останавливаем службу IPA

Меняем это значение на сервере IPA в файле /etc/dirsrv/slapd-ROSA-DEMO/dse.ldif и перезапускаем службы, используя команду

После этого повторяем попытку интеграции.

Как Вы видите, на предыдущем скриншоте, повторная попытка добавления прошла вполне успешно и нам надо будет перезапустить службу ovirt-engine. Далее выполняем вход в систему с учётной записью администратора Ovirt имеет достаточно развитую внутреннюю RBAC модель, а так же возможность создания новых ролей.

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

Вводим учётные данные пользователя, который входит в группу [mailto: virtualization_admins@rosa.demo virtualization_admins@rosa.demo]

Добро пожаловать на портал само-обслуживания пользователя Ovirt, с правами по-умолчанию для роли UserRole.

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

Отказоустойчивая виртуализация на базе Ovirt 3.5

Рассмотрим вопрос построения отказоустойчивой виртуализации на базе Ovirt 3.5, рассмотрим основные механизмы отработки отказа узла кластера.

Многие из нас знакомы с понятием High Availability в разрезе Microsoft Failover Cluster Services или VMWare HA — в Ovirt данный механизм так же существует.

Думаю, он понимаем достаточно легко, так же как и балансировка виртуальных машин, в зависимости от нагрузки (DRS в терминах VMWare и Dynamic Optimization в терминах Microsoft), существуют и Affinity Groups. Детально с реализацией механизмов можно ознакомиться в Admin Guide продукта, поэтому мы не будем детально обсуждать этот вопрос.

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

Fencing [1] Данный термин используется в отношении физических узлов виртуализации с поддержкой удалённого управления; Soft fencing over SSH для сервиса агента VDSM; Sanlock Fencing с использованием общего хранилища.

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

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

Возьмем на себя смелость немного уточнить изложенный ниже материал.

Для развертывания отказоустойчивого кластера oVirt использует ПО низкоуровневой поддержки оборудования (ipmitool). При установке хоста и добавлении его в кластер, система виртуализации сообщает о необходимости установить и настроить IPMI или его аналог.

При этом, нами отмечен забавный баг, а именно:

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

По этому мы рекомендуем:

— либо настраивайте управление питанием ПОСЛЕ добавления узла в кластер, а во время добавления узла в кластер от настройки Power Management откажитесь вовсе.

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

— либо перед добавлением узла в кластер, самостоятельно произведите установку ipmitool (yum install ipmitool) и произведите загрузку необходимых модулей (modprobe ipmi_devintf и modprobe ipmi_si).

После этого спокойно устанавливаете ПО хоста, и добавляйте его в кластер. И тогда на конечном этапе добавления нового хоста в кластер, сработает настройка IPMI и его проверка кнопочкой «Test».

Конец примечания редактора

Host High Availability или Fencing

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

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

  • Power Management и управление энергосбережением (аналог Power Optimization в SCVMM 2012);
  • Динамического распределения нагрузки в кластере (DRS в терминах VMWare или PROTips и Dynamic Optimization в терминах Microsoft);
  • Политики высокой доступности виртуальных машин (Microsoft High Available VMs или vSphere HA).

apc APC MasterSwitch network power switch. Not for use with APC 5.x power switch devices. apc_snmp Use with APC 5.x power switch devices. bladecenter IBM Bladecentre Remote Supervisor Adapter. cisco_ucs Cisco Unified Computing System. drac5 Dell Remote Access Controller for Dell computers. drac7 Dell Remote Access Controller for Dell computers. eps ePowerSwitch 8M+ network power switch. hpblade HP BladeSystem. ilo, ilo2, ilo3, ilo4 HP Integrated Lights-Out. ipmilan Intelligent Platform Management Interface and Sun Integrated Lights Out Management devices. rsa IBM Remote Supervisor Adaptor. rsb Fujitsu-Siemens RSB management interface. wti WTI Network PowerSwitch.

Это налагает определённые ограничения на выбор аппаратной платформы виртуализации.

oVirt использует механизм Fencing для поддержки узлов кластера в активном работающем состоянии. Узел кластера, который находится в статусе Non Responsive отличается от узла в статусе Non Operational тем, что узел со статусом Non Operational доступен для oVirt по сети управления, но к примеру имеет неверную конфигурацию логических сетей.

Читайте также:  Настройка mortal kombat xbox 360

Если сбойный узел кластера не вернулся к статусу активный, после команды перезагрузки, то он остаётся в положении Non-Responsive до устранения проблемы.

Все операции управления питанием выполняются через проксирующий узел, в отличии от операций, которые выполняются напрямую oVirt. Требуется минимум 2 узла в кластере для поддержки функционала fencing и работающего Power Management.

Soft-Fencing Hosts

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

В этом случае, перезагрузка VDSM агента может решить проблему. В oVirt 3.3 появился дополнительный механизм, называемый Soft-Fencing. Идея в том, что сервер управления oVirt будет пытаться перезагрузить агент VDSM узла кластера, подключившись по SSH. Данную операцию будет выполнять внешний fencing-агент, если он сконфигурирован.

Эта операция так же требует наличие прокси-узла в датацентре.

Запуск процедуры Soft-Fencing происходит по тайм-ауту соединения между сервером управления и хостом виртуализации.

Работает это следующим образом:

  • При первом сетевом сбое устанавливается статус «Connecting».
  • oVirt предпринимает 3 попытки подключения к VDSM для получения статуса и ожидает ответ интервал времени, который определяется загрузкой узла. Формула следующая:

ПРИМЕЧАНИЕ! The Storage Pool Manager или SPM — это роль, которая выдаётся oVirt конкретному узлу в Datacenter для управления хранилищами. SPM контролирует доступ к хранилищам, координируя метаданные для Storage Domains. Это включает операции: создания, удаления, манипулирования виртуальными дисками, снапшотами и шаблонами, выделением хранилищ SAN и отвечает за целостность данных.

  • Для того, чтобы дать VDSM максимальное кол-во времени на ответ, oVirt выбирает самое длинное значение, полученное с помощью формулы, приведённой выше.
  • Если узел не ответил за отведённое время вызывается процедура vdsm restart по SSH
  • Если vdsm restart не привёл к установлению соединения между узлом и сервером управления oVirt, то узел переходит в состояние Non Responsive.
  • Далее, если сконфигурировано управления питанием управление будет передано внешнему fencing-агенту.

ПРИМЕЧАНИЕ! Soft-fencing over SSH может быть выполнено на узле, которые не имеет функционала Power Management.

Sanlock Fencing

Данный механизм — Sanlock Daemon, включен в продукт с Ovirt 3.1 для получение хостами аренды области с данными на общем хранилище. Sanlock Fencing использует возможности shared storage (NFS, Glusterfs, FCP и т. д.) и эффективен в тех случаях, когда хост стал недоступен через обычные средства коммуникации: Power Management или сетевые интерфейсы. В этом случае узел-прокси пошлет команду на демон недоступного узла, а тот отправит узел кластера в перезагрузку.

Основной проблемой данного механизма является то, что при сбое аппаратного обеспечения, потере электропитания или kernel panics, недоступности общего хранилища, узел перестаёт обновлять свою аренду. Так как мы не имеет данных о состоянии узла, мы предполагаем, что узел может начать писать на СХД в любой момент. Как следствие, мы не можем перезапустить узел используя sanlock, чтобы предотвратить запись в одни и те же области СХД, получив потерю данных. Нам потребуется в ручную перезагрузить узел.

Интеграция oVirt 3.5 с Microsoft Active Directory

Рассмотрим процедуру интеграции oVirt 3.5 c Microsoft Active Directory.

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

  • Необходимо обеспечить возможность разрешения DNS имён (A, PTR, SRV записей) сервером oVirt 3.5 и контроллером домена;
  • Сервер oVirt и контроллер домена должны иметь одинаковое время (так как используется Kerberos);
  • необходимо выполнить предварительные требования для сервисной учётной записи oVirt;

Разрешение имён

У меня в лаборатории существуют два отдельных домена DNS: ROSA.DEMO на BIND и TARGET.COM на MS-DNS. Для разрешения имён я настроил Conditional Forwarding и Stub-zone на BIND (не совсем рекомендованный способ, но было интересно);

ПРИМЕЧAНИЕ! При настройке лаборатории я не придерживался какого-то формального Best Practice по Linux (лучше ограничивать доступ к внутренним DNS серверам доверенными сетями).

Узлы должны успешно разрешать помимо А-записей:

  • pointer record (PTR) for the directory server’s reverse look-up address.
  • service record (SRV) for LDAP over TCP port 389
  • service record (SRV) for Kerberos over TCP port 88
  • service record (SRV) for Kerberos over UDP port 88

Требование к синхронизации времени

Вопрос легко решаются с помощью централизованного NTP сервера. От себя добавлю, что первые попытки интеграции провалились по причине разницы во времени и часового пояса. Необходимо обращать внимание:

  • на формат данных времени и часового пояса;
  • часовой пояс;
  • функционал автоматической смены летнего/зимнего времени (может добавить +\- 1 час к текущему времени) .

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

ПРИМЕЧАНИЕ! Кстати, мой стенд, в виртуальной его части (3 сервера RELS с ролями BIND, IPA, OVIRT и 1 контроллер домена на MS Windows Server) собран полностью на Hyper-V 2012 R2, плюс несколько физических серверов под RELS 6.6

Требования к сервисной учётной записи следующие:

  • Read Access to Directory Services
  • Join a computer to the domain
  • Modify the membership of a group

Интеграция

Собственно, сабж. выполняем интеграцию с помощью команды engine-manage-domains add, как на скриншоте ниже.

Затем перезапускаем сервис ovirt-engine.

Собственно, результат смотрим ниже.

Ошибка Ovirt 3.5 при подключении iso образа в виртуальной машины ACTION_TYPE_FAILED_INVALID_CDROM_DISK_FORMAT

Натолкнулся на фичу oVirt 3.5, о которой производитель успешно молчит. При попытке смонтировать в виртуальную машину диск ISO, к примеру со следующим названием SW_DVD9_SQL_Svr_Standard_Edtn_2012w_SP2_64Bit_English_-2_MLF_X19-75010.ISO получаем следующую ошибку:

md5sum показывала полное совпадение хэшей, ну и размер образов совпадал.

Дело в том, что oVirt 3.5 не понимает расширение файла iso, если оно написано заглавными буквами. После переименования образа командой mv, файл-образ успешно был подключен к виртуальной машины.

Источник

Adblock
detector