Обновление oVirt Hosted Engine 4.0.6 до версии 4.1.0

Ранее мы уже рассматривали пример обновления oVirt Hosted Engine между релизами в рамках версии 4.0, который в своей основе применим и к данному обновлению. Однако в случае обновления версии oVirt 4.0.6 на 4.1.0 имеются некоторые свои особенности, которые я постараюсь описать на практическом примере с имеющейся у меня инфраструктурой oVirt.

Информацию о новой версии oVirt 4.1.0 можно найти в документе oVirt 4.1.0 Release Notes.

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

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

1. Включаем Hosted Engine Global Maintenance
2. Обновляем виртуальную машину Hosted Engine
3. Обновляем первый хост Hosted Engine
4. Отключаем Hosted Engine Global Maintenance
5. Обновляем второй и последующие хосты Hosted Engine
6. Повышаем уровень Cluster Compatibility Version
7. Повышаем уровень Data Center Compatibility Version
8. Обновляем oVirt Guest Agent в виртуальных машинах

 

Шаг 1. Включаем Hosted Engine Global Maintenance

Включаем на любом из хостов, обслуживающих Hosted Engine, глобальный режим обслуживания, чтобы отключить наблюдение HA-агентов за виртуальной машиной Hosted Engine. В версии 4.0.6 сделать это можно, как через веб-портал администрирования oVirt, открыв контекстное меню действий для виртуальной машины HostedEngine > Enable Global HA Maintenance

Про версию я написал не просто, ибо после обновления до 4.1.0 такой пункт меню я не обнаружил (управление глобальным режимом обслуживания Hosted Engine перенесено на закладку управления хостами).

Ту же самую процедуру мы можем выполнить в консоли любого из хостов, обслуживающих Hosted Engine, командой:

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

Убеждаемся в том, что в веб-консоли статус всех хостов Hosted Engine изменился на Global Maintenance Enabled:

Переходим к шагу обновления виртуальной машины Hosted Engine.

Шаг 2. Обновляем виртуальную машину oVirt Engine

Перейдём на консоль виртуальной машины oVirt Engine и установим пакет, который добавит в систему репозитории поддержки новой версии:

# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

Репозитории поддержки старой версии oVirt мы можем удалить, но сделать это лучше после процедуры обновления oVirt Engine (после выполнения команды engine-setup), в противном случае у процедуры обновления не будет возможности отката на старую версию в случае проблем при обновлении.

Выполним очистку кэша менеджера пакетов и произведём установку всех обновлённых пакетов:

# yum clean all
# yum update

Затем запустим программу развёртывания oVirt Engine:

# engine-setup

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

Здесь мы можем видеть список обновляемых и устанавливаемых дополнительно пакетов…

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

Здесь нас предупредят о том, что в процессе обновления служба Engine будет перезапускаться…

Ещё раз просмотрим сводные параметры Engine и запускаем процесс обновления, нажав Enter…

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

После завершения обновления перезапустим веб-портал администрирования oVirt и убедимся в том, что отображается новая версия.

Кстати, по субъективным ощущениям, с обновлённой веб-консолью в версии 4.1.0 (по сравнению 4.0.6) стало существенно комфортней работать в Internet Explorer 11.

***

Итак, oVirt Engine мы обновили и теперь уже можно избавиться от ссылок на репозитории старой версии.

Удалим пакет репозитория старой версии, так как в нём нет больше никакой необходимости:

# yum remove ovirt-release40

Однако после удаления пакета в системе всё-равно останутся ссылки на репозитории старой версии. Убедиться в этом можно так:

# yum repolist | grep ovirt

Repository virtio-win-stable is listed more than once in the configuration
 * ovirt-4.0: ftp.nluug.nl
 * ovirt-4.0-epel: epel.besthosting.ua
 * ovirt-4.1: ftp.nluug.nl
 * ovirt-4.1-epel: epel.besthosting.ua
centos-ovirt-common-candidate/x86_64     CentOS-7 - oVirt common             198
centos-ovirt40-release/x86_64            CentOS-7 - oVirt 4.0                365
centos-ovirt41-candidate/x86_64          CentOS-7 - oVirt 4.1                 95
ovirt-4.0/7                              Latest oVirt 4.0 Release            908
ovirt-4.0-centos-gluster37/x86_64        CentOS-7 - Gluster 3.7              214
ovirt-4.0-epel/x86_64                    Extra Packages for Enterprise Li 11,204
ovirt-4.0-patternfly1-noarch-epel/x86_64 Copr repo for patternfly1 owned       2
ovirt-4.1/7                              Latest oVirt 4.1 Release            219
ovirt-4.1-centos-gluster38/x86_64        CentOS-7 - Gluster 3.8              151
ovirt-4.1-epel/x86_64                    Extra Packages for Enterprise Li 11,204
ovirt-4.1-patternfly1-noarch-epel/x86_64 Copr repo for patternfly1 owned       2

Все старые репозитории oVirt подтягиваются из repo-файлов в /etc/yum.repos.d/

# ls -la /etc/yum.repos.d/ | grep ovirt

-rw-r--r--.   1 root root  1672 Jan 13 13:17 ovirt-4.0-dependencies.repo
-rw-r--r--.   1 root root   289 Jan 13 13:17 ovirt-4.0.repo
-rw-r--r--.   1 root root  2097 Feb 19 18:19 ovirt-4.1-dependencies.repo
-rw-r--r--.   1 root root   289 Feb 19 18:19 ovirt-4.1.repo

Удаляем файлы со ссылками на старые репозитории:

# rm /etc/yum.repos.d/ovirt-4.0.repo
# rm /etc/yum.repos.d/ovirt-4.0-dependencies.repo

Чистим кэш менеджера пакетов и выполняем проверочный запрос обновлений

# yum clean all
# yum update

На этом обновление oVirt Engine можно считать законченным. Переходим к обновлению хостов.

 

Шаг 3. Обновляем первый хост Hosted Engine

Перед обновлением первого хоста переводим его в режим обслуживания на веб-портале администрирования в обновлённом меню действий Management > Maintenance. В процессе перевода в режим обслуживания с хоста должны будут эвакуироваться все виртуальные машины. Кстати, обратите внимание на то, что в новой версии в веб-консоли на закладке управления хостами теперь видно все хосты, обслуживающие Hosted Engine.

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

 

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

# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

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

# yum clean all 
# yum update

При первой же попытке установки пакетов можем столкнуться с проблемой неразрешённых зависимостей, связанных с пакетами collectd*:

...
--> Finished Dependency Resolution
Error: Package: collectd-disk-5.7.0-2.el7.x86_64 (centos-opstools-testing)
           Requires: collectd(x86-64) = 5.7.0-2.el7
           Available: collectd-5.5.2-2.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.5.2-2.el7
           Available: collectd-5.6.2-1.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.6.2-1.el7
           Available: collectd-5.7.0-1.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.7.0-1.el7
           Available: collectd-5.7.0-2.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.7.0-2.el7
           Installing: collectd-5.7.1-1.el7.x86_64 (epel)
               collectd(x86-64) = 5.7.1-1.el7
Error: Package: collectd-write_http-5.7.0-2.el7.x86_64 (centos-opstools-testing)
           Requires: collectd(x86-64) = 5.7.0-2.el7
           Available: collectd-5.5.2-2.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.5.2-2.el7
           Available: collectd-5.6.2-1.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.6.2-1.el7
           Available: collectd-5.7.0-1.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.7.0-1.el7
           Available: collectd-5.7.0-2.el7.x86_64 (centos-opstools-testing)
               collectd(x86-64) = 5.7.0-2.el7
           Installing: collectd-5.7.1-1.el7.x86_64 (epel)
               collectd(x86-64) = 5.7.1-1.el7
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Смысл заключается в том, что если на сервере ранее был подключен репозиторий EPEL (а он у вас скорее всего подключен), то из него доступна более новая версия пакета collectd-5.7.1-1.el7.x86_64, хотя Ovirt 4.1 нужен пакет более старой версии collectd-5.7.0-2.el7.x86_64.

Для решения этой проблемы воспользуемся рекомендацией с ранее упомянутой страницы Release Notes и внесём правку в repo-файл, описывающий репозиторий epel

# nano /etc/yum.repos.d/epel.repo

В секцию описания репозитория последней строкой добавим правило исключения пакетов collectd*:

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
exclude=collectd*

...

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

# yum clean all
# yum update

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

***

После окончания установки пакетов, перезапускаем службы oVirt на хосте:

# systemctl restart vdsmd.service
# systemctl restart ovirt-ha-broker.service
# systemctl restart ovirt-ha-agent.service

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

***

Нам осталось только вычистить информацию о репозиториях старой версии oVirt:

# yum remove ovirt-release40
# rm /etc/yum.repos.d/ovirt-4.0.repo
# rm /etc/yum.repos.d/ovirt-4.0-dependencies.repo
# yum clean all
# yum update

 

Шаг 4. Отключаем Hosted Engine Global Maintenance

oVirt Engine обновлён, первый хост Hosted Engine обновлён, и теперь можно попробовать отключить глобальный режим обслуживания, чтобы снова задействовать наблюдение HA-агентов за виртуальной машиной Hosted Engine. Сделать это можно разными способами. Например из веб-консоли на любом из активных хостов Hosted Engine выбрав в контактном меню действий Disable Global HA Maintenance 

Тоже самое можно сделать в консоли активного хоста Hosted Engine командой:

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

Затем активируем уже обновлённых хост в веб-консоли oVirt в меню навигации Management > Activate  

при этом обращаем внимание на то, что в консоли теперь отображается обновлённая версия службы VDSM.

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

 

Шаг 5. Обновляем второй и последующие хосты Hosted Engine

Обновление остальных хостов Hosted Engine выполняется по аналогичной схеме:

• Включаем глобальный режим обслуживания Hosted Engine
• Включаем режим обслуживания хоста (эвакуация виртуальных машин)
• Обновляем хост с последующим перезапуском служб или перезагрузкой
• Устанавливаем пакет ovirt-release41
• Отключаем установку пакетов collectd* из репозитория EPEL
• Обновляем пакеты oVirt
• Перезапускаем хост
• Удаляем пакет ovirt-release40 и ссылки на репозитории старой версии oVirt
• Выводим хост из режима обслуживания и отключаем глобальный режим обслуживания Hosted Engine

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

 

Шаг 6. Повышаем уровень Cluster Compatibility Version

Такие объекты инфраструктуры oVirt, как Cluster, имеют уровень совместимости - Cluster Compatibility Version. Режим совместимости определяет возможности хостов, входящих в этот кластер. Так как на данном этапе мы считаем, что все наши хосты обновлены, то теперь мы можем поднять уровень совместимости кластера до новой версии oVirt. Для этого на веб-портале администрирования oVirt на закладке управления кластерами дата-центра выберем пункт меню его правки Edit

В форме редактирования свойств кластера изменим значение поля Compatibility Version, выбрав в нём новую версию 4.1.

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

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

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

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

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

 

Шаг 7. Повышаем уровень Data Center Compatibility Version

Такие объекты инфраструктуры oVirt, как Data Center, также имеют уровень совместимости - Data Center Compatibility Version. Уровень совместимости дата-центра зависит от уровня совместимости всех входящих в него кластеров. Так как на данном этапе мы считаем, что все наши кластеры имеют обновлённый уровень совместимости, то теперь мы можем поднять уровень совместимости самого дата-центра до новой версии oVirt. Для этого на веб-портале администрирования oVirt на закладке Data Centers выберем наш дата-центр и вызовем пункт меню правки Edit

В форме свойств дата-центра изменим значение поля Compatibility Version на новую версию 4.1.

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

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

На этом обновление уровня совместимости дата-центра можно считать законченным.

 

Шаг 8. Обновляем oVirt Guest Agent в виртуальных машинах

В обновлённой версии oVirt 4.1.0 на закладке управления виртуальными машинами появился новый статусный индикатор, который отображает необходимость обновления компонент интеграции oVirt внутри гостевых систем. Для ВМ, имеющих не самую актуальную версию oVirt Guest Agent будет отображаться предупреждение "The latest guest agent needs to be installed and running on the guest"

Самый простой способ – попытаться установить обновлённые версии пакета ovirt-guest-agent из официальных репозиториев вашего Linux-дистрибутива.

Для гостевой ОС на CentOS 7

# yum update ovirt-guest-agent
# systemctl enable ovirt-guest-agent
# systemctl restart ovirt-guest-agent
# systemctl status ovirt-guest-agent

Для гостевой ОС Ubuntu 16.04 LTS / Debian 8

# apt-get update
# apt-get install ovirt-guest-agent
# systemctl enable ovirt-guest-agent 
# systemctl restart ovirt-guest-agent 
# systemctl status ovirt-guest-agent

***

В моём случае почти все гостевые системы работают на базе Debian 8.7. В официальных репозиториях для этой ОС в ветке jessie stable доступен пакет ovirt-guest-agent_1.0.10.2.dfsg-2+deb8u1_all. Однако веб-портал администрирования oVirt вещает о том, что это неактуальная версия.

Установить более новую версию 1.0.12.2.dfsg-2 можно из репозиториев ветки stretch testing (ветка относящаяся к разрабатываемому Debian 9). Для этого придётся внести небольшие изменения в настройки менеджера пакетов apt.

Создадим файл, добавляющий в систему репозиторий Debian Stretch:

# cat > /etc/apt/sources.list.d/debian-9-stretch.list << EOF

# Testing repos for Debian 9 (Stretch)
deb     http://ftp.ru.debian.org/debian stretch main
deb-src http://ftp.ru.debian.org/debian stretch main

EOF

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

# cat > /etc/apt/preferences.d/debian-9-stretch.pref  << EOF

Package: ovirt-guest-agent
Pin: release n=stretch
Pin-Priority: 550

Package: *
Pin: release n=jessie
Pin-Priority: 500

Package: *
Pin: release n=stretch
Pin-Priority: -1

EOF

Таким образом, при обновлении в систему, как и прежде, будут устанавливаться все пакеты из репозитория Debian 8 (Jessie) и не будут устанавливаться пакеты из репозитория Debian 9 (Stretch). А пакет ovirt-guest-agent из репозитория Debian 9 (Stretch) будет иметь приоритет над пакетом из Debian 8 (Jessie).

После создания дополнительных конфигурационных файлов apt выполним обновление и убедимся в том, что теперь нам для установки доступна новая версия ovirt-guest-agent: 

# apt update
# apt list --upgradable
...
ovirt-guest-agent/testing 1.0.12.2.dfsg-2 all [upgradable from: 1.0.10.2.dfsg-2+deb8u1]

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

# apt-cache policy ovirt-guest-agent
ovirt-guest-agent:
  Installed: 1.0.10.2.dfsg-2+deb8u1
  Candidate: 1.0.12.2.dfsg-2
  Package pin: 1.0.12.2.dfsg-2
  Version table:
     1.0.12.2.dfsg-2 550
         -1 http://ftp.ru.debian.org/debian/ stretch/main amd64 Packages
 *** 1.0.10.2.dfsg-2+deb8u1 550
        500 http://ftp.ru.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

Обновляемся:

# apt-get install ovirt-guest-agent

После установки новой версии гостевого агента предупреждение из веб-консоли исчезнет. И, кстати, обновлённая версия решит старую проблему, когда вкладка Guest Info не отображала никакой информации для Debian-систем: 

На этом, пожалуй, всё.

В качестве заключения хочу напомнить, что рассмотренный в этой заметке пример обновления практически применим только к конфигурации Hosted Engine и только для указанных здесь версий ПО. При обновлении до следующих версий oVirt описанная логика процедуры обновления может остаться такой же, а может и измениться, поэтому на этапе планирования развёртывания каждого последующего обновления крайне рекомендуется внимательно изучать Release Notes к новой версии.