oVirt за 2 часа. Часть 4. Базовые операции

Сегодня мы рассмотрим ряд базовых операций, которые регулярно потребуется выполнять администратору среды виртуализации. Статья — продолжение серии по oVirt: часть 1, часть 2 и часть 3:

Содержание




Статьи


  1. Введение
  2. Установка менеджера (ovirt-engine) и гипервизоров (hosts)
  3. Дополнительные настройки
  4. Базовые операции — Мы здесь


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

При входе в oVirt Вы увидите 2 портала:
  • Administration Portal
  • VM Portal

Первый предназначен для администратора и административных задач, второй — для заказчиков машин, но может быть использован и администратором — некоторые функции там делать даже удобнее.
Вверху окна каждой коллекции объектов oVirt есть мощное окно поиска, с контекстными подсказками.
Как пример, выбор проблемных хостов в панели управления на самом деле вызывает фильтр:
status = unassigned or status = maintenance or status = installing or status = reboot or status = preparingformaintenance or status = pendingapproval or status = connecting or status = installingos or status = kdumping


Создание ВМ и шаблона


Думаю, простую ВМ Вы создали уже во 2-й части, сейчас познакомимся с другими сущностями oVirt, непосредственно относящимся к виртуальным машинам — сами виртуальные машины, шаблоны и пулы.
Шаблон — это копия машины (обычно заранее подготовленная), предназначенная для создания идентичных машин (клонирования). Шаблон может иметь версию, это удобно, т.к. не надо делать новый отдельный шаблон после каждого обновления эталонной машины. Подробнее в документации.
Пул — группа одинаковых машин, порожденных из одного шаблона. Удобно для VDI (virtual desktop infrastructure), когда десяткам или сотням пользователей нужно предоставить идентичное рабочее окружение и делается это буквально в мгновения. Подробнее о пулах — в документации.

Создадим шаблон, для чего можно склонировать ранее созданную машину, но для демонстрации мы пойдем иным путем — импорт шаблона из внешней коллекции Glance Images: Storage -> Domains -> ovirt-image-repository (1), Import (2):

Рис. 1 — Импорт образа Fedora 32.
Отмечаем «Импортировать как шаблон» (3, Import as Template), даем шаблону имя (4). Настоятельно рекомендуется диску дать понятное имя (5, Disk Alias).

За прогрессом задач удобно наблюдать в разделе Tasks (Задачи).

Рис. 2 — Прогресс выполнения задач в oVirt.

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

Рис. 3 — Шаблоны.

На базе загруженного шаблона создаем пул:

Рис. 4 — Создание пула.
Проходим в Compute -> Pools (1), New (2), выбираем шаблон Fedora32 (3), версия — latests (4), присваиваем имя «myPoolA-??» (5). Поля Number of VM и Prestarted VM пока не трогаем, вернемся к ним на следующем шаге. Далее включаем расширенные настройки (6) и переходим к настройке Initial Run.


Рис. 4 — Настройка первоначального запуска.
Т.к. из Glance Images мы загрузили Cloud Image, надо настроить аутентификацию. Проверяем, что включено «Use Cloud-Init/Sysprep» (1), распахиваем Authentication (2), указываем имя пользователя, напр., root или user (3). Для создания уникального пароля для пула отключаем «Use Already Configured Password» (4) и вводим свой пароль (5). Нажимаем «Ок» — пул создан, в Compute -> Virtual Machines появились идентичные машины (обратите внимание на их значок, он отличен от отдельно работающей машины).
Замечание по имени пула. Как Вы обратили внимание, в конце стоит "-??". Это включает «нормализованную» нумерацию машин (дополненную нулями — 01, 02, ..., 09, 10 и т.д.) В противном случае нумерация будет натуральными числами без выравнивания (1, 2, ..., 9, 10, ...)
Перед продолжением вернемся к настройкам пула. Обратите внимание, что поле «Number of VM» изменилось на «Increase number of VMs in pool by». Указываем здесь 31 и количество машин в пуле практически мгновенно становится 32. Теперь в поле «Prestarted VM» впишем 16 — это заставит oVirt держать предзапущенными и готовыми к подключению пользователей указанное количество машин. На этом о машинах, шаблонах и пулах завершим и перейдем к миграции.

Основные значки ВМ:
  • rack unit — сервер;
  • монитор — десктоп;
  • 3 towers — сервер из пула;
  • 3 монитора — десктоп из пула;
  • rewind (перемотка назад) — stateless (машина сбрасыват свое состояние на исходное после выключения; все изменения откатываются);
  • треугольник в оранжевом мониторе — запрошенное изменение конфигурации требует перезагрузки.


Миграция ВМ (live migration)


Миграция состояния включенной машины выполняется просто — правый клик по машине или группе машин. Процедура похожа на аналогичную vMotion в vSphere.


Рис. 5 — Запуск миграции.
Compute -> Virtual Machine, выбрать одну или несколько машин, Migrate.


Рис. 6 — За процессом миграции можно наблюдать в хостах (Compute -> Hosts).
В один момент времени переезжает не более 2-х машин.

Миграция хранилища (storage migration)


А вот эта процедура пользователю VMware vSphere может показаться непривычной, т.к. подходы к хранению как образов дисков, так и конфигурации машин в системах различаются.
Для переноса хранилища ВМ следует пройти в диски (Storage -> Disks), либо домены (Storage -> Domains -> {Domain Name} -> Disks). Выбрать диск(и) и нажать Move. Вот и все, диск(и) отправлены на другое хранилище.
Примечание: в силу внутренней организации для миграции хранилища шаблона и пула есть ограничения. Знакомство со storage migration лучше выполнить на отдельной машине, вне пула.
Копирование дисков выполняется в этих же меню, как и ручная загрузка/выгрузка.

Переименование ВМ и диска


Изменить имя машины или шаблона очень просто — Edit и вписать новое имя. Переименование пула требует удаления его машин и пересоздания, т.к. на его основе порождаются ВМ с соответствующими именами и конфигурацией.
Переименовать диск также возможно, но путь длиннее: Compute -> Virtual Machine -> {VM Name} -> Disks -> {VM Disk Alias} -> Edit, Alias.
Внутренние идентификаторы объектов построены на UUID. При переименовании мы фактически меняем псевдонимы.

В разделе речь идет об обновлении, которое update (минорное), а не upgrade (мажорное), когда меняется номер версии (это более сложная процедура и не входит в ежедневные задачи).

Обновление oVirt-Host (гипервизор)


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


Рис. 7 — При наличии обновлений менеджер сообщит о них значком компакт-диска.


Рис. 8 — Перед запуском обновления нужно включить режим обслуживания (Management -> Maintenance), он автоматически запустит миграцию ВМ на другие хосты (см. рис. 6) и подготовит к обновлению.


Рис. 9 — Значок гаечного ключа сообщает о готовности хоста к обслуживанию.


Рис. 10 — Installation -> Upgrade запускает процедуру обновления.


Рис. 11 — Мы можем попросить менеджер дать хосту команду на перезапуск после окончания обновления, для вступления его в силу.


Рис. 12 — После перезагрузки выводим гипервизор из режима обслуживания (Management -> Activate).

Проходим все хосты и обновляем их.

Обновление oVirt-Engine (менеджер)


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

  1. По возможности сделать архив либо снимок машины, убедиться, что последняя плановая архивация прошла без ошибок.
  2. Проверяем и обновляем установочные пакеты:
    $ sudo engine-upgrade-check
    $ sudo update ovirt\*setup\*
  3. Основная часть обновления выполяется программой engine-setup. Она задаст ряд вопросов о конфигурации, затем остановит службу ovirt-engine, загрузит и установит обновленные пакеты, создаст архив и обновит базу данных, применит обновленную конфигурацию и запустит службу ovirt-engine.
    $ sudo engine-setup

    При успешном обновлении получим сообщение:
    Execution of setup completed successfully

    Пример вывода работы скрипта engine-setup
    $ sudo engine-setup

    [ INFO  ] Stage: Initializing
    [ INFO  ] Stage: Environment setup
              Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
              Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20200522232449-o97vyx.log
              Version: otopi-1.8.2 (otopi-1.8.2-1.el7)
    [ INFO  ] Stage: Environment packages setup
    [ INFO  ] Stage: Programs detection
    [ INFO  ] Stage: Environment setup (late)
    [ INFO  ] Stage: Environment customization
             
              --== PRODUCT OPTIONS ==--
             
             
              --== PACKAGES ==--
             
    [ INFO  ] Checking for product updates...
              Setup needs to install or update the following packages:
              [updated] ovirt-engine-4.3.5.5-1.el7.noarch will be updated
    ...
              [update] ovirt-engine-wildfly-overlay-17.0.1-1.el7.noarch is an update
              Replying "No" will abort Setup. You can pass the option "--offline" to prevent installing or updating packages.
              Do you wish to update them now? (Yes, No) [Yes]: 
    [ INFO  ] Checking for an update for Setup...
             
              --== NETWORK CONFIGURATION ==--
             
              Setup can automatically configure the firewall on this system.
              Note: automatic configuration of the firewall may overwrite current settings.
              NOTICE: iptables is deprecated and will be removed in future releases
              Do you want Setup to configure the firewall? (Yes, No) [Yes]: 
    [ INFO  ] firewalld will be configured as firewall manager.
             
              --== DATABASE CONFIGURATION ==--
             
              The detected DWH database size is 439 MB.
              Setup can backup the existing database. The time and space required for the database backup depend on its size. This process takes time, and in some cases (for instance, when the size is few GBs) may take several hours to complete.
              If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost.
              Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: 
              Perform full vacuum on the oVirt engine history
              database ovirt_engine_history@localhost?
              This operation may take a while depending on this setup health and the
              configuration of the db vacuum process.
              See https://www.postgresql.org/docs/10/sql-vacuum.html
              (Yes, No) [No]: 
             
              --== OVIRT ENGINE CONFIGURATION ==--
             
              Perform full vacuum on the engine database engine@localhost?
              This operation may take a while depending on this setup health and the
              configuration of the db vacuum process.
              See https://www.postgresql.org/docs/10/sql-vacuum.html
              (Yes, No) [No]: 
             
              --== STORAGE CONFIGURATION ==--
             
             
              --== PKI CONFIGURATION ==--
             
             
              --== APACHE CONFIGURATION ==--
             
             
              --== SYSTEM CONFIGURATION ==--
             
             
              --== MISC CONFIGURATION ==--
             
             
              --== END OF CONFIGURATION ==--
             
    [ INFO  ] Stage: Setup validation
              During execution engine service will be stopped (OK, Cancel) [OK]: 
    [ INFO  ] Cleaning stale zombie tasks and commands
             
              --== CONFIGURATION PREVIEW ==--
             
              Default SAN wipe after delete           : False
              Firewall manager                        : firewalld
              Update Firewall                         : True
              Host FQDN                               : ovirt.example.com
              Upgrade packages                        : True
              Set up Cinderlib integration            : False
              Engine database secured connection      : False
              Engine database user name               : engine
              Engine database name                    : engine
              Engine database host                    : localhost
              Engine database port                    : 5432
              Engine database host name validation    : False
              Engine installation                     : True
              PKI organization                        : JSC Open Lab
              Set up ovirt-provider-ovn               : False
              Configure WebSocket Proxy               : True
              DWH installation                        : True
              DWH database secured connection         : False
              DWH database host                       : localhost
              DWH database user name                  : ovirt_engine_history
              DWH database name                       : ovirt_engine_history
              Backup DWH database                     : True
              DWH database port                       : 5432
              DWH database host name validation       : False
              Configure Image I/O Proxy               : True
              Configure VMConsole Proxy               : True
             
              Please confirm installation settings (OK, Cancel) [OK]: 
    [ INFO  ] Cleaning async tasks and compensations
    [ INFO  ] Unlocking existing entities
    [ INFO  ] Checking the Engine database consistency
    [ INFO  ] Stage: Transaction setup
    [ INFO  ] Stopping engine service
    [ INFO  ] Stopping ovirt-fence-kdump-listener service
    [ INFO  ] Stopping dwh service
    [ INFO  ] Stopping Image I/O Proxy service
    [ INFO  ] Stopping vmconsole-proxy service
    [ INFO  ] Stopping websocket-proxy service
    [ INFO  ] Stage: Misc configuration (early)
    [ INFO  ] Stage: Package installation
    [ INFO  ] Yum Status: Downloading Packages
    ...
    [ INFO  ] Stage: Misc configuration
    [ INFO  ] Upgrading CA
    [ INFO  ] Not rewriting /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf because it was changed manually. You might want to compare it with /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf.new and edit as needed.
    [ INFO  ] Backing up database localhost:ovirt_engine_history to '/var/lib/ovirt-engine-dwh/backups/dwh-20200522233531.6LDItj.dump'.
    [ INFO  ] Creating/refreshing DWH database schema
    [ INFO  ] Configuring Image I/O Proxy
    [ INFO  ] Configuring WebSocket Proxy
    [ INFO  ] Backing up database localhost:engine to '/var/lib/ovirt-engine/backups/engine-20200522233538.LZCwME.dump'.
    [ INFO  ] Creating/refreshing Engine database schema
    [ INFO  ] Creating/refreshing Engine 'internal' domain database schema
              Unregistering existing client registration info.
    [ INFO  ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
    [ INFO  ] Stage: Transaction commit
    [ INFO  ] Stage: Closing up
    [ INFO  ] Starting engine service
    [ INFO  ] Starting dwh service
    [ INFO  ] Restarting ovirt-vmconsole proxy service
             
              --== SUMMARY ==--
             
    [ INFO  ] Restarting httpd
              Web access is enabled at:
                  http://ovirt.example.com:80/ovirt-engine
                  https://ovirt.example.com:443/ovirt-engine
              SSH fingerprint: SHA256:JvilhbwRuMjBCJEjQVPlFQgk0aLaKz7Od0WzsZtx4j4
              Did not update /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf because it was changed manually. You might want to compare it with /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf.new and edit as needed.
             
              --== END OF SUMMARY ==--
             
    [ INFO  ] Stage: Clean up
              Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20200522232449-o97vyx.log
    [ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20200522233608-setup.conf'
    [ INFO  ] Stage: Pre-termination
    [ INFO  ] Stage: Termination
    [ INFO  ] Execution of setup completed successfully

  4. Выполняем обновление ОС и остальных дополнительных пакетов:
    $ sudo yum update

    При необходимости (обновление ядра или его компонентов) перезагружаем машину.


Импорт ВМ


Импортировать можно из VMware, Export Domain (специальная сущность oVirt для обмена образами между Data Center), Virtual Appliance (OVA), XEN, KVM. Все официально поддерживаемые варианты:
  1. Import VM from VMware ESXi/VSPHERE: The user specify URL+authentication to the host wher ESXi/VSPHERE runs on
  2. Import KVM/Xen VM from Libvirt: The user specify URL+authentication to the host where Libvirt runs on
  3. Import KVM/Xen VM from a given path: The user specify nfs/posix path to the VM configuration & disks
  4. Import VM which was exported from VMware: The user specify nfs/posix path to ova file
  5. Upload KVM/Xen VM: The user specify files of the configuration and the disks
  6. Upload VM which was exported from VMware: The user specify ova file
  7. Import VM from folder: The user specify path to folder that contains KVM/Xen VMs or VM exported from VMware

Остановимся на 2-х вариантах — импорт из vSphere и отдельно стоящей машины с KVM. Для запуска матера импорта в Compute -> Virtual Machines нажимаем кнопку дополнительных пунктов меню (3 вертикальные точки, см. рис. 13). Исходная машина должна быть выключена.

Импорт машин из vCenter


В мастере:
  • Data Source: VMware;
  • External Provider: в Administration -> Providers можно настроить шаблон для частых операций;
  • vCenter: имя или адрес vCenter сервера;
  • ESXi: с какого гипервизора будем забирать машину;
  • Data Ceter: полный путь к кластеру;
  • Cluster: содержащий гипервизор кластер;
  • Username/password: имя и пароль для подключения к vCenter;
  • Verify server's SSL certificate: при использовании самоподписанных сертификатов придется отключить их проверку.


Рис. 13 — Импорт ВМ из VMware vSphere.

Импорт машин из KVM


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

В параметрах, передаваемых демону libvirtd
$ sudo vim /etc/sysconfig/libvirtd

раскомментировать стороку
LIBVIRTD_ARGS="--listen"

Создать резервную копию конфигурации и разрешить подключение
$ sudo cp /etc/libvirt/libvirtd.conf /etc/libvirt/libvirtd.conf.`date +%F`
$ sudo vim /etc/libvirt/libvirtd.conf

внеся следующие настройки:
listen_tls = 0
listen_tcp = 1
listen_addr = "0.0.0.0"
auth_tcp = "none"

Для диагностики дополнительно нужно раскомментировать строку
log_outputs="3:syslog:libvirtd"

После чего нужно перезапустить libvirtd. На работающих гостевых машинах, начиная с версии libvirtd > 0.6 (проверка версии libvirtd --version), это не скажется.
$ sudo service libvirtd restart

Далее нужно разрешить в брандмауре tcp:16509.
В CentOS 7 временное разрешение делается так (без ключа permanent):
$ sudo firewall-cmd --add-rich-rule='rule family="ipv4" source address="172.17.71.32/30" port port="16509" protocol="tcp" accept'

Проверка подключения:
$ virsh -r -c 'qemu+tcp://mgmt@kvm46.example.com/system' list --all


Далее сам импорт выполняется очень просто:
Compute -> Virtual Machines ->: (доп. меню, 3 вертикальные точки) -> Import -> Source (KVM via libvirt) -> URI (qemu+tcp://kvm46.example.com/system) -> Require Authentication (Disable) -> Load.
Отмечаем нужные машины, выбираем политику размещения (Allocation Policy).
Allocation Policy — Preallocated предпочтительно для томов СХД с аппаратным zero detection, для томов с высоким вводом-выводом, томов с высоким заполнением и т.п., иначе можно thin provisioned. В любом случае смотрим ситуации и анализируем.
Установленная галочка «Clone» склонирует, а не скопирует машину. Напр., будет назначен новый MAC адрес сетевого интерфейса.
На вкладке General важно указать верный тип ОС, а на вкладке Network Interfaces можно указать нужные сети. Далее «импорт», и, в зависимости от скорости работы оборудования, получаем импортированную машину. После импорта (а можно и перед) не забудьте установить ovirt-guest-agent.

Управление задачами


При зависании задач начинаются непростые «танцы», некоторые па из которых попытаюсь затронуть. При штатном же поведении наблюдать за ними можно на рис. 2.
Если задача выполняется более или менее штатно — достаточно штатных инструментов. С пимерами и картинками можно посмотреть здесь.

Задачи выполняются на oVirt-host'е.
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Host getAllTasksInfo
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task getStatus taskID=<TASKID>
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task stop taskID=<TaskID>
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task clear taskID=<TaskID>
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Host getAllTasksInfo

Дополнительно vdsm-client может попытаться откатить задачу, все поддерживаемые методы:
$ sudo vdsm-client Task -h


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:
[mgmt@ovirt-engine] $ sudo /usr/share/ovirt-engine/setup/dbutils/taskcleaner.sh --help

Для еще более тяжелых случаев требуется прямое редактирование БД. К этому методу следует прибегать только в крайнем случае, имея свежие архивы oVirt'а и затронутых машин.
Итак, подключаем software collection
[mgmt@ovirt-engine] $ sudo scl enable rh-postgresql10 "psql -d engine -U postgres"

Далее подключаемся к БД
su postgres
psql -d engine -U postgres
select * from job order by start_time desc;

И непосредственное удаление — запуск процедуры DeleteJob для проблемной задачи:
select DeleteJob('UUID_HERE');

Пример:
select DeleteJob('ed0127c7-b052-4ec2-a67c-8b3a65d55e19');


Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!
Источник: habr.ru