ovirt spm что это
При попытке выполнить форсированную передачу роли SPM в веб-консоли oVirt…
…возникала ошибка вида “Failed to force select KOM-M11 as the SPM due to a failure to stop the current SPM.”
В логе engine.log на сервере oVirt Engine в этот момент фиксировалось следующее сообщение:
Как я понял, в данной ситуации проблема передачи SPM заключается в невозможности остановить SPM на текущем хосте из-за заданий VDSM, имеющих статус завершённых, но не вычищенных из очереди заданий.
Перейдём в консоль хоста, на котором на данный момент выполняется роль SPM и посмотрим задания VDSM
Как видно, в списке заданий есть одно задание. Посмотрим его статус.
Как было отмечено ранее, по сути информация фигурирующая в сообщении об ошибке отсылает нас в корневую причину проблем, находящуюся в LVM-группе. Однако интересно в контексте нашей вторичной проблемы с невозможностью передачи SPM другое – то, что задача VDSM на хосте фактически имеет статус finished/cleanSuccess, но при этом не исчезает из списка заданий VDSM.
Решить эту проблему мы можем, самостоятельно очистив “залипшее” задание командой следующего вида:
После этого снова проверим список заданий VDSM и убедимся в том, что теперь он пуст.
После этого повторная попытка передачи роли SPM между хостами должна произойти успешно.
oVirt за 2 часа. Часть 4. Базовые операции
Сегодня мы рассмотрим ряд базовых операций, которые регулярно потребуется выполнять администратору среды виртуализации. Статья — продолжение серии по oVirt: часть 1, часть 2 и часть 3:
Содержание
Статьи
При входе в oVirt Вы увидите 2 портала:
Вверху окна каждой коллекции объектов oVirt есть мощное окно поиска, с контекстными подсказками.
Как пример, выбор проблемных хостов в панели управления на самом деле вызывает фильтр:
Создание ВМ и шаблона
Думаю, простую ВМ Вы создали уже во 2-й части, сейчас познакомимся с другими сущностями oVirt, непосредственно относящимся к виртуальным машинам — сами виртуальные машины, шаблоны и пулы.
Шаблон — это копия машины (обычно заранее подготовленная), предназначенная для создания идентичных машин (клонирования). Шаблон может иметь версию, это удобно, т.к. не надо делать новый отдельный шаблон после каждого обновления эталонной машины. Подробнее в документации.
Пул — группа одинаковых машин, порожденных из одного шаблона. Удобно для VDI (virtual desktop infrastructure), когда десяткам или сотням пользователей нужно предоставить идентичное рабочее окружение и делается это буквально в мгновения. Подробнее о пулах — в документации.
Рис. 1 — Импорт образа Fedora 32.
Отмечаем «Импортировать как шаблон» (3, Import as Template), даем шаблону имя (4). Настоятельно рекомендуется диску дать понятное имя (5, Disk Alias).
За прогрессом задач удобно наблюдать в разделе Tasks (Задачи).
Рис. 2 — Прогресс выполнения задач в oVirt.
После успешной загрузки шаблон добавится в список.
Рис. 3 — Шаблоны.
На базе загруженного шаблона создаем пул:
Рис. 4 — Создание пула.
Основные значки ВМ:
Миграция ВМ (live migration)
Миграция состояния включенной машины выполняется просто — правый клик по машине или группе машин. Процедура похожа на аналогичную vMotion в vSphere.
Рис. 5 — Запуск миграции.
Миграция хранилища (storage migration)
Примечание: в силу внутренней организации для миграции хранилища шаблона и пула есть ограничения. Знакомство со storage migration лучше выполнить на отдельной машине, вне пула.
Копирование дисков выполняется в этих же меню, как и ручная загрузка/выгрузка.
Переименование ВМ и диска
Изменить имя машины или шаблона очень просто — Edit и вписать новое имя. Переименование пула требует удаления его машин и пересоздания, т.к. на его основе порождаются ВМ с соответствующими именами и конфигурацией.
В разделе речь идет об обновлении, которое update (минорное), а не upgrade (мажорное), когда меняется номер версии (это более сложная процедура и не входит в ежедневные задачи).
Обновление oVirt-Host (гипервизор)
Обновление хостов выполняется проще, чем в vSphere, менеджер обновлений в oVirt органично встроен в платформу и не требует настроек. Официальная документация об обновлении.
Рис. 7 — При наличии обновлений менеджер сообщит о них значком компакт-диска.
Проходим все хосты и обновляем их.
Обновление oVirt-Engine (менеджер)
По началу это может сбить с толку, но обновление менеджера выполняется при помощи engine-setup, с дополнительными шагами, как описано в документации.
При успешном обновлении получим сообщение:
При необходимости (обновление ядра или его компонентов) перезагружаем машину.
Импорт ВМ
Импортировать можно из VMware, Export Domain (специальная сущность oVirt для обмена образами между Data Center), Virtual Appliance (OVA), XEN, KVM. Все официально поддерживаемые варианты:
Импорт машин из vCenter
Импорт машин из KVM
Подробности об импорте из KVM в документации.
Сперва надо разрешить подключение к KVM извне, если это не настраивалось ранее.
В статье расскажу о быстрой настройке для небезопасного подключения, предназначенного только на время импорта машины. Не используйте эту схему для постоянной работы! Предполагаю, что импорт нужен на короткое время, после чего предыдущий хост будет выведен из эксплуатации, либо настройки будут возвращены к предыдущим значениям. Процедура также описана в документации, напр., к ArchLinux.
В параметрах, передаваемых демону libvirtd
Создать резервную копию конфигурации и разрешить подключение
внеся следующие настройки:
Для диагностики дополнительно нужно раскомментировать строку
Далее нужно разрешить в брандмауре tcp:16509.
В CentOS 7 временное разрешение делается так (без ключа permanent):
Далее сам импорт выполняется очень просто:
Отмечаем нужные машины, выбираем политику размещения (Allocation Policy).
Allocation Policy — Preallocated предпочтительно для томов СХД с аппаратным zero detection, для томов с высоким вводом-выводом, томов с высоким заполнением и т.п., иначе можно thin provisioned. В любом случае смотрим ситуации и анализируем.
Установленная галочка «Clone» склонирует, а не скопирует машину. Напр., будет назначен новый MAC адрес сетевого интерфейса.
На вкладке General важно указать верный тип ОС, а на вкладке Network Interfaces можно указать нужные сети. Далее «импорт», и, в зависимости от скорости работы оборудования, получаем импортированную машину. После импорта (а можно и перед) не забудьте установить ovirt-guest-agent.
Управление задачами
При зависании задач начинаются непростые «танцы», некоторые па из которых попытаюсь затронуть. При штатном же поведении наблюдать за ними можно на рис. 2.
Если задача выполняется более или менее штатно — достаточно штатных инструментов. С пимерами и картинками можно посмотреть здесь.
Задачи выполняются на oVirt-host’е.
Дополнительно vdsm-client может попытаться откатить задачу, все поддерживаемые методы:
…
Task methods:
method [arg=value]
getStatus Get Task status information.
revert Rollback a Task to restore the previous system state.
clear Discard information about a finished Task.
getInfo Get information about a Task.
stop Stop a currently running Task.
Однако движения усложняются, если задачу штатными способами остановить не удается.
Официально для этого применяется инструмент taskcleaner:
Для еще более тяжелых случаев требуется прямое редактирование БД. К этому методу следует прибегать только в крайнем случае, имея свежие архивы oVirt’а и затронутых машин.
Итак, подключаем software collection
Далее подключаемся к БД
И непосредственное удаление — запуск процедуры DeleteJob для проблемной задачи:
Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!
Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3
В ней будет рассмотрен процесс базовой установки и настройки кластера oVirt 4.3, для хостинга высокодоступных виртуальных машин, с учётом того, что все предварительные шаги по подготовке инфраструктуры, уже выполнены ранее.
Вводная часть
С субъективной точки зрения, oVirt 4.3 по своему функционалу похож на VMware vSphere версии 5.х, но конечно же со своими особенностями настройки и работы.
Для интересующихся, все отличия между RHEV (aka oVirt) и VMware vSphere можно найти в Интернете, например здесь, но всё же буду иногда отмечать их некоторые отличия или похожести между собой, по ходу статьи.
Отдельно хотелось бы немного сравнить работу с сетями для виртуальных машин. В oVirt реализован похожий принцип управления сетями для виртуальных машин (далее ВМ), как и в VMware vSphere:
Необходимо отметить, что из-за простоты реализации, в статье будет описана настройка сетей в oVirt’е для ВМ с помощью стандартного Linux bridge, который является стандартным выбором, при использовании гипервизора KVM.
В связи с этим имеется несколько базовых правил по работе с сетью в кластере, которые лучше не нарушать:
Ещё одно важное замечание — для очень критичного окружения (весьма чувствительного к денежным потерям), всё-таки рекомендовалось бы использовать платную поддержку и использовать Red Hat Virtualization 4.3. В процессе эксплуатации кластера oVirt, могут возникать некоторые моменты, по которым желательно как можно скорее получить квалифицированную помощь, а не разбираться с ними самостоятельно.
И наконец, рекомендуется перед развёртыванием кластера oVirt, ознакомиться с официальной документацией, чтобы быть в курсе хотя бы основных понятий и определений, иначе далее статью читать будет немного трудно.
Базовыми для понимания статьи и принципов работы кластера oVirt, являются эти руководящие документы:
Объём там не очень большой, за час-два вполне можно осилить основные принципы, а для любителей подробностей рекомендуется почитать Product Documentation for Red Hat Virtualization 4.3 — RHEV и oVirt по сути одно и тоже.
Итак, если все базовые настройки на хостах, коммутаторах и СХД выполнены, переходим непосредственно к развёртыванию oVirt.
Часть 2. Установка и настройка кластера oVirt 4.3
Для удобства ориентирования, приведу по списку основные разделы в этой статье, которые поочерёдно должны быть выполнены:
Установка управляющего сервера oVirt
Управляющий сервер oVirt – это самый главный элемент в инфраструктуре oVirt, в виде виртуальной машины, хоста, или виртуального устройства, управляющего всей инфраструктурой oVirt.
Его близкие аналоги из мира виртуализации:
Для установки управляющего сервера oVirt, у нас имеется два варианта:
Вариант 1
Развёртывание сервера в виде специализированной ВМ или хоста.
Этот вариант вполне работает, но при условии, что такая ВМ работает независимо от кластера, т.е. не запущена на каком-либо хосте кластера в виде обычной виртуальной машины под управлением KVM.
Почему нельзя разворачивать такую ВМ на хостах кластера?
В самом начале процесса развёртывания управляющего сервера oVirt, у нас имеется дилемма — управляющую ВМ ставить нужно, но самого кластера фактически ещё нет, и поэтому что можно с ходу придумать? Правильно – установить KVM на будущий узел кластера, далее на нём создать виртуальную машину, например, с ОС CentOS и в ней развернуть oVirt engine. Это может делаться обычно из соображений полного контроля над такой ВМ, но это ошибочное намерение, потому что в таком случае, в дальнейшем 100% будут проблемы с такой управляющей ВМ:
Так что делайте всё по правилам — используйте для управляющего сервера oVirt или отдельный хост, или независимую ВМ, запущенную на нём, а лучше делайте как написано во втором варианте.
Вариант 2
Установка oVirt Engine Appliance на управляемый им же хост кластера.
Именно этот вариант будет рассмотрен далее, как более правильный и подходящий в нашем случае.
Требования к такой ВМ описаны ниже, добавлю лишь, что рекомендуется иметь минимум два хоста в инфраструктуре, на которых может быть запущена управляющая ВМ, чтобы сделать её отказоустойчивой. Здесь хотелось бы добавить, что как писал уже в комментариях в предыдущей статье, мне так и не удалось получить splitbrain на кластере oVirt из двух хостов, с возможностью запуска hosted-engine ВМ на них.
Установка oVirt Engine Appliance на первый хост кластера
В документе указаны предварительные условия, которые должны быть выполнены перед развёртыванием hosted-engine ВМ, а также детально расписан сам процесс её установки, так что повторять его дословно нет особого смысла, поэтому акцентируем внимание не некоторых важных деталях.
При желании можно запустить установку с заранее подготовленным файлом ответов:
Ранее мы также проверяли его видимость на хостах:
Если всё было сделано правильно, то после окончания установки заходим с помощью веб-браузера на https://ovirt_hostname/ovirt-engine с компьютера администратора, и кликаем [Administration Portal].
Введя логин и пароль (заданные в процессе установки) в окно как на скриншоте, попадаем в панель управления Open Virtualization Manager, в которой можно производить все действия с виртуальной инфраструктурой:
Все эти действия будут рассмотрены далее, что-то в крупную клетку, что-то более подробно и с нюансами.
Но сначала рекомендовал бы почитать это дополнение, которое наверняка многим может пригодиться.
Дополнение
1) В принципе, если есть такая необходимость, то ничего не мешает заранее установить гипервизор KVM на узлы кластера, используя пакеты libvirt и qemu-kvm (или qemu-kvm-ev) желаемой версии, хотя при развёртывании узла кластера oVirt, он может это сделать и сам.
Но если libvirt и qemu-kvm были установлены не самой свежей версии, то можно получить такую ошибку во время развёртывания hosted engine:
Т.е. необходимо иметь обновлённую версию libvirt с защитой от MDS, который поддерживает такую политику:
Устанавливаем libvirt v.4.5.0-10.el7_6.12, с поддержкой md-clear:
После этого можно продолжать установку hosted engine.
2) В oVirt 4.3 наличие и использование файервола firewalld является обязательным требованием.
То необходимо выключить другой файервол (если он используется), и установить и запустить firewalld:
В дальнейшем, при установке агента ovirt на новом хосте для кластера, он настроит требуемые порты в firewalld автоматически.
3) Перезагрузка хоста с работающей на нём ВМ с hosted engine.
Как обычно, ссылка 1 и ссылка 2 на руководящие документы.
Всё управление hosted engine ВМ делается ТОЛЬКО с помощью команды hosted-engine на хосте, где она работает, про virsh надо забыть, также, как и про то, что к этой ВМ можно подключиться по SSH и выполнить на ней команду «shutdown».
Перезагружаем хост с hosted engine agent и делаем с ним что нам нужно.
После перезагрузки проверяем статус ВМ с hosted engine:
Если наша ВМ с hosted-engine не запускается и если мы видим похожие ошибки в логе сервиса:
То подключаем хранилище и перезапускаем агента:
После запуска ВМ с hosted-engine, выводим её из режима обслуживания:
4) Удаление hosted engine и всего с ней связанного.
Иногда бывает необходимо правильно удалить ранее установленный hosted engine — ссылка на руководящий документ.
Просто выполняем команду на хосте:
Далее удаляем ненужные пакеты, забэкапив перед этим какие-то конфиги, если это необходимо:
Создание нового датацентра
Справочная документация — oVirt Administration Guide. Chapter 4: Data Centers
Сначала определим, что такое датацентр (цитирую из справки) — это логическая сущность, которая определяет набор ресурсов, используемых в специфическом окружении.
Датацентр — это своего рода контейнер, состоящий из:
Датацентр может включать в себя несколько кластеров, состоящих из нескольких хостов с виртуальными машинами, работающими на них, у него также может быть несколько областей хранения, ассоциированных с ним.
Датацентров может быть несколько, они работают независимо друг от друга. В ovirt имеется разделение полномочий по ролям, и можно настроить разрешения персонально, как на уровне датацентра, так и на его отдельные логические элементы.
Датацентр, или датацентры если их несколько, управляются из единой административной консоли или портала.
Чтобы создать датацентр, заходим в административный портал и создаём новый датацентр:
Compute >> Data Centers >> New
Так как у нас используется общее хранилище на СХД, то тип хранилища (Storage Type) должен быть Shared:
При установке виртуальной машины с hosted-engine, по умолчанию создаётся датацентр – Datacenter1, и далее при необходимости у него можно поменять тип хранилища (Storage Type) на другой.
Создание датацентра — это несложная задача, без каких-то хитрых нюансов, и все дополнительные действия с ним описаны в документации. Единственно замечу, что одиночные хосты имеющие только локальное хранилище (диск) для ВМ, в датацентр c Storage Type — Shared попасть не смогут (нельзя будет их туда добавить), и для них нужно создавать отдельный датацентр – т.е. каждому отдельному хосту с локальным хранилищем, нужен свой отдельный датацентр.
Создание нового кластера
Ссылка на документацию — oVirt Administration Guide. Chapter 5: Clusters
Без излишних подробностей, кластер – это логическая группировка хостов, имеющих общую область хранения (в виде общих дисков на СХД, как в нашем случае). Также желательно, чтобы хосты в кластере были идентичны по железу, и имели бы одинаковый тип процессора (Intel или AMD). Лучше всего конечно, чтобы сервера в кластере были полностью одинаковыми.
Кластер входит в состав датацентра (c определённым типом хранилища — Local или Shared), а все хосты в обязательном порядке должны принадлежать какому-либо кластеру, в зависимости от того, есть ли у них общее хранилище или нет.
При установке виртуальной машины с hosted-engine на хост, по умолчанию создаётся датацентр — Datacenter1, вместе с кластером – Cluster1, и в дальнейшем можно настроить его параметры, включить дополнительные опции, добавить в него хосты и т.п.
Как обычно, для получения подробностей о всех настройках кластера, желательно обратиться к официальной документации. Из каких-то особенностей настройки кластера, добавлю лишь, что при его создании достаточно настроить только основные параметры на вкладке General.
Отмечу наиболее важные параметры:
Установка дополнительных хостов в Self-Hosted окружении
Дополнительные хосты для Self-Hosted окружения, добавляются так же, как и обычный хост, с выполнением дополнительного пункта по развертыванию ВМ с hosted engine — Choose hosted engine deployment action >> Deploy. Так как дополнительному хосту тоже должен быть презентован LUN для ВМ с hosted engine, то это значит, что этот хост можно при необходимости использовать для размещения на нём ВМ с hosted engine.
В целях отказоустойчивости весьма рекомендуется, чтобы было минимум два хоста, на которых может быть размещена ВМ с hosted engine.
На дополнительном хосте отключаем iptables (если включен), включаем firewalld
Устанавливаем требуемую версию KVM (по необходимости):
Устанавливаем нужные репозитории и установщик hosted engine:
Далее переходим в консоль Open Virtualization Manager, добавляем новый хост, и делаем всё пошагово, как написано в документации.
В результате, после добавления дополнительного хоста, мы должны получить примерно картину в административной консоли, как на скриншоте.
Хост, на котором ВМ с hosted-engine в данный момент активна, имеет золотую корону и надпись «Running the Hosted Engine VM», хост, на котором эта ВМ может быть запущена при необходимости – надпись «Can run the Hosted Engine VM».
В случае сбоя хоста на котором «Running the Hosted Engine VM», она автоматически перезапустится на втором хосте. Также эту ВМ можно мигрировать с активного хоста на резервный, для его обслуживания.
Настройка Power Management / fencing на хостах oVirt
Ссылки на документацию:
Хотя может показаться, что добавление и настройка хоста выполнены, но это не совсем так.
Для нормальной работы хостов, и выявления/устранения сбоев с кем-либо из них, необходима настройка Power Management / fencing.
Fencing, или огораживание – это процесс временного исключения неисправного или сбойного хоста из кластера, в процессе которого перезапускаются или сервисы oVirt на нём, или сам хост.
Все подробности по определениям и параметрам Power Management / fencing даны, как обычно в документации, я лишь приведу пример, как настроить этот важный параметр, в применении к серверам Dell R640 с iDRAC 9.
Создание области хранения или Storage Domains
Ссылка на документацию — oVirt Administration Guide, Chapter 8: Storage.
Storage Domain, или область хранения – это централизованное место для хранения дисков виртуальных машин, установочных образов, шаблонов и снэпшотов.
Области хранения могут подключаться к датацентру, используя различные протоколы, кластерные и сетевые файловые системы.
У oVirt имеется три типа области хранения:
В нашем частном случае область хранения с типом Data Domain, использует Fibre Channel Protocol (FCP), для подключения к LUN’ам на СХД.
С точки зрения oVirt, при использовании СХД (FC или iSCSI) каждый виртуальный диск, снэпшот или шаблон — это логический диск.
Блочные устройства собираются в одно целое (на хостах кластера) с помощью Volume Group и затем разделяются с помощью LVM на логические тома, используемые как виртуальные диски для ВМ.
Все эти группы и множество томов LVM, можно увидеть на хосте кластера, с помощью команд vgs и lvs. Естественно, что все действия с такими дисками нужно делать только из консоли oVirt, кроме особых случаев.
Виртуальные диски для ВМ могут быть двух типов — QCOW2 или RAW. Диски могут быть «тонкими» или «толстыми«. Снэпшоты всегда создаются как «тонкие«.
Способ управления Storage domains, или областями хранения, доступ к которым осуществляется через FC, довольно логичен — для каждого виртуального диска ВМ существует отдельный логический том, который доступен для записи только одному хосту. В случае подключений через FC, oVirt использует что-то наподобие кластерного LVM.
Виртуальные машины, расположенные на одной области хранения, можно мигрировать между хостами, принадлежащими одному и тому же кластеру.
Как видим из описания, кластер в oVirt, как и кластер в VMware vSphere или в Hyper-V, по сути обозначают одно и тоже – это логическая группировка хостов, желательно одинаковых по составу «железа», и имеющих общее хранилище для дисков виртуальных машин.
После запуска мастера, заполняем требуемые поля:
В списке LUN’ов отмечаем нужный нам, кликаем Add и затем ОК. При необходимости можно скорректировать дополнительные параметры области хранения, кликнув на Advanced Parameters.
По результатам работы мастера, мы должны получить новую область хранения, а наш датацентр перейти в статус UP, или инициализирован:
Создание и настройка сетей для виртуальных машин
Ссылка на документацию — oVirt Administration Guide, Chapter 6: Logical Networks
Networks, или сети – служат для группировки логических сетей, используемых в виртуальной инфраструктуре oVirt.
Для взаимодействия сетевого адаптера на виртуальной машине, с физическим адаптером на хосте, используются логические интерфейсы типа Linux bridge.
Для группировки и разделения трафика между сетями, на коммутаторах настроены VLAN’ы.
При создании логической сети для виртуальных машин в oVirt, ей надо обязательно назначить идентификатор, соответствующий номеру VLAN на коммутаторе, чтобы ВМ могли бы взаимодействовать друг с другом, даже если они работают на разных узлах кластера.
Предварительные настройки сетевых адаптеров на хостах для подключения виртуальных машин должны были быть выполнены в предыдущей статье – настроен логический интерфейс bond1, далее все сетевые настройки должны производиться только через административный портал oVirt.
После создания ВМ с hosted-engine, помимо автоматического создания датацентра и кластера, также автоматически создалась и логическая сеть для управления нашим кластером – ovritmgmt, к которой была подключена эта ВМ.
При необходимости можно посмотреть настройки логической сети ovritmgmt и скорректировать их, но надо быть осторожным, чтобы не потерять управление инфраструктурой oVirt.
Для создания новой логической сети для обычных ВМ, в административном портале переходим в Network >> Networks >> New, и на вкладке General добавляем сеть с нужным идентификатором VLAN, а также ставим флажок напротив «VM Network», это означает что её можно использовать для назначения на ВМ.
На вкладке Cluster, прикрепляем эту сеть к нашему кластеру Cluster1.
После этого переходим в Compute >> Hosts, по очереди заходим в каждый хост, на вкладку Network interfaces, и запускаем мастер Setup host networks, для привязки к хостам новой логической сети.
Агент oVirt автоматически сделает все необходимые сетевые настройки на хосте – создаст VLAN и BRIDGE.
Ещё раз напомню, что на хосте кластера НЕ НУЖНО заранее создавать руками сетевые интерфейсы ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.
После добавления логической сети и проверки соединения между хостом и ВМ c hosted engine, её можно использовать в виртуальной машине.
Создание установочного образа для развёртывания виртуальной машины
Ссылка на документацию — oVirt Administration Guide, Chapter 8: Storage, раздел Uploading Images to a Data Storage Domain.
Без установочного образа ОС, не удастся установить виртуальную машину, хотя это конечно и не является проблемой, если в сети установлен, например, Cobbler с заранее созданными образами.
В нашем случае такой возможности нет, поэтому придётся самостоятельно этот образ импортировать в oVirt. Ранее, для этого требовалось создавать ISO Domain, но в новой версии oVirt он был признан устаревшим, и поэтому теперь можно загружать образы прямо в Storage domain из административного портала.
В административном портале идём в Storage >> Disks >> Upload >> Start
Добавляем наш образ ОС в виде ISO файла, в форме заполняем все поля, и кликаем кнопку «Test connection«.
Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine’s CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`
То необходимо добавить сертификат oVirt в «Доверенные корневые ЦС» (Trusted Root CA) на управляющей станции администратора, откуда пытаемся загрузить образ.
После добавления сертификата в Trusted Root CA, опять кликаем «Test connection«, должны получить:
Выполнив действие по добавлению сертификата, можно попробовать опять загрузить образ ISO в Storage Domain.
В принципе, можно сделать отдельный Storage Domain с типом Data, для хранения образов и шаблонов отдельно от дисков ВМ, или даже хранить их в Storage Domain для hosted engine, но это уже на усмотрение администратора.
Создание виртуальной машины
После загрузки в oVirt установочного образа с ОС, можно переходить непосредственно к созданию виртуальной машины. Много было работы проделано, но мы уже находимся на завершающем этапе, ради чего всё это и затевалось – получение отказоустойчивой инфраструктуры для хостинга высокодоступных виртуальных машин. И причём всё это абсолютно бесплатно – ни одной копейки на приобретение каких-либо лицензий на ПО, не было потрачено.
Для создания виртуальной машины с CentOS 7, должен быть загружен установочный образ с ОС.
Заходим в административный портал, идём в Compute >> Virtual Machines, и запускаем мастер создания ВМ. Заполняем все параметры и поля, и кликаем ОК. Всё очень просто, если следовать документации.
В качестве примера, приведу основные и дополнительные настройки высокодоступной ВМ, с созданным диском, подключенную к сети, и с загрузкой с установочного образа:
После окончания работ с мастером, закрываем его, запускаем новую ВМ и устанавливаем на неё ОС.
Для этого заходим в консоль этой ВМ через административный портал:
Чтобы подключиться к консоли ВМ, предварительно надо настроить консоль в свойствах виртуальной машины.
Для подключения к консоли ВМ можно использовать, например, Virtual Machine Viewer.
Чтобы подключиться к консоли ВМ прямо в окне браузера, настройки подключения через консоль должны быть такими:
После установки ОС на ВМ, желательно установить oVirt guest agent:
Таким образом, в результате наших действий, созданная ВМ будет высокодоступной, т.е. в случае сбоя узла кластера, на котором она запущена, oVirt её автоматически перезапустит на втором узле. Также эту ВМ можно мигрировать между хостами кластера для их обслуживания, или других целей.
Заключение
Надеюсь, что этой статьёй удалось донести, что oVirt – вполне нормальный инструмент по управлению виртуальной инфраструктурой, который развернуть не так и сложно — главное соблюдать определённые правила и требования, описанные как в статье, так и в документации.
Из-за большого объёма статьи в неё не удалось поместить многие вещи, типа пошагового выполнения различных мастеров со всеми подробными пояснениями и скриншотами, длинные выводы каких-то команд, и т.п. На самом деле для этого потребовалось бы написать целую книгу, что не имеет особого смысла, из-за постоянно появляющихся новых версий ПО с нововведениями и изменениями. Самое главное – это понять принцип, как оно всё вместе работает, и получить общий алгоритм действий по созданию отказоустойчивой платформы по управлению виртуальными машинами.
Хотя виртуальную инфраструктуру мы создали, но теперь надо научить её взаимодействовать как между своими отдельными элементами: хостами, виртуальными машинами, внутренними сетями, так и с внешним миром.
Этот процесс является одной из основных задач системного или сетевого администратора, которая будет раскрыта в следующей статье — про использование виртуальных маршрутизаторов VyOS в отказоустойчивой инфраструктуре нашего предприятия (как вы догадались, они будут работать в виде виртуальных машин на нашем кластере oVirt).