Оффлайн
- Регистрация
- 12.04.17
- Сообщения
- 19.095
- Реакции
- 107
- Репутация
- 0
Сегодня мы рассмотрим ряд базовых операций, которые регулярно потребуется выполнять администратору среды виртуализации. Статья — продолжение серии по oVirt:
Содержание
Статьи
Традиционно, для подробностей по административным задачам — добро пожаловать в
При входе в oVirt Вы увидите 2 портала:
Первый предназначен для администратора и административных задач, второй — для заказчиков машин, но может быть использован и администратором — некоторые функции там делать даже удобнее.
Вверху окна каждой коллекции объектов 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 держать предзапущенными и готовыми к подключению пользователей указанное количество машин. На этом о машинах, шаблонах и пулах завершим и перейдем к миграции.
Основные значки ВМ:
Миграция ВМ (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, с дополнительными шагами, как описано в
Импорт ВМ
Импортировать можно из VMware, Export Domain (специальная сущность oVirt для обмена образами между Data Center), Virtual Appliance (OVA), XEN, KVM. Все официально поддерживаемые варианты:
Остановимся на 2-х вариантах — импорт из vSphere и отдельно стоящей машины с KVM. Для запуска матера импорта в Compute -> Virtual Machines нажимаем кнопку дополнительных пунктов меню (3 вертикальные точки, см. рис. 13). Исходная машина должна быть выключена.
Импорт машин из vCenter
В мастере:
Рис. 13 — Импорт ВМ из VMware vSphere.
Импорт машин из KVM
Подробности об импорте из KVM в
Сперва надо разрешить подключение к KVM извне, если это не настраивалось ранее.
Разрешение экспорта машин в KVM
В статье расскажу о быстрой настройке для небезопасного подключения, предназначенного только на время импорта машины. Не используйте эту схему для постоянной работы! Предполагаю, что импорт нужен на короткое время, после чего предыдущий хост будет выведен из эксплуатации, либо настройки будут возвращены к предыдущим значениям. Процедура также описана в документации, напр., к
В параметрах, передаваемых демону 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://[email protected]/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=
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task stop taskID=
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task clear 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');
Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!
You must be registered for see links
,
You must be registered for see links
и
You must be registered for see links
:Содержание
-
You must be registered for see links;
-
You must be registered for see links(live migration);
-
You must be registered for see links(storage migration);
-
You must be registered for see links;
-
You must be registered for see links(гипервизор);
-
You must be registered for see links(менеджер);
-
You must be registered for see links;
-
You must be registered for see links.
Статьи
-
You must be registered for see links
-
You must be registered for see links
-
You must be registered for see links
- Базовые операции — Мы здесь
Традиционно, для подробностей по административным задачам — добро пожаловать в
You must be registered for see links
.При входе в 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, непосредственно относящимся к виртуальным машинам — сами виртуальные машины, шаблоны и пулы.
Шаблон — это копия машины (обычно заранее подготовленная), предназначенная для создания идентичных машин (клонирования). Шаблон может иметь версию, это удобно, т.к. не надо делать новый отдельный шаблон после каждого обновления эталонной машины. Подробнее в
You must be registered for see links
.Пул — группа одинаковых машин, порожденных из одного шаблона. Удобно для VDI (virtual desktop infrastructure), когда десяткам или сотням пользователей нужно предоставить идентичное рабочее окружение и делается это буквально в мгновения. Подробнее о пулах — в
You must be registered for see links
.Создадим шаблон, для чего можно склонировать ранее созданную машину, но для демонстрации мы пойдем иным путем — импорт шаблона из внешней коллекции 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 органично встроен в платформу и не требует настроек. Официальная
You must be registered for see links
об обновлении.
Рис. 7 — При наличии обновлений менеджер сообщит о них значком компакт-диска.
Рис. 8 — Перед запуском обновления нужно включить режим обслуживания (Management -> Maintenance), он автоматически запустит миграцию ВМ на другие хосты (см. рис. 6) и подготовит к обновлению.
Рис. 9 — Значок гаечного ключа сообщает о готовности хоста к обслуживанию.
Рис. 10 — Installation -> Upgrade запускает процедуру обновления.
Рис. 11 — Мы можем попросить менеджер дать хосту команду на перезапуск после окончания обновления, для вступления его в силу.
Рис. 12 — После перезагрузки выводим гипервизор из режима обслуживания (Management -> Activate).
Проходим все хосты и обновляем их.
Обновление oVirt-Engine (менеджер)
По началу это может сбить с толку, но обновление менеджера выполняется при помощи engine-setup, с дополнительными шагами, как описано в
You must be registered for see links
.- По возможности сделать архив либо снимок машины, убедиться, что последняя плановая архивация прошла без ошибок.
- Проверяем и обновляем установочные пакеты:
$ sudo engine-upgrade-check
$ sudo update ovirt\*setup\* - Основная часть обновления выполяется программой 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.
SeeYou must be registered for see links
(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.
SeeYou must be registered for see links
(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
virt_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:
You must be registered for see links
You must be registered for see links
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
- Выполняем обновление ОС и остальных дополнительных пакетов:
$ sudo yum update
При необходимости (обновление ядра или его компонентов) перезагружаем машину.
Импорт ВМ
Импортировать можно из VMware, Export Domain (специальная сущность oVirt для обмена образами между Data Center), Virtual Appliance (OVA), XEN, KVM. Все официально поддерживаемые варианты:
- Import VM from VMware ESXi/VSPHERE: The user specify URL+authentication to the host wher ESXi/VSPHERE runs on
- Import KVM/Xen VM from Libvirt: The user specify URL+authentication to the host where Libvirt runs on
- Import KVM/Xen VM from a given path: The user specify nfs/posix path to the VM configuration & disks
- Import VM which was exported from VMware: The user specify nfs/posix path to ova file
- Upload KVM/Xen VM: The user specify files of the configuration and the disks
- Upload VM which was exported from VMware: The user specify ova file
- 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 в
You must be registered for see links
.Сперва надо разрешить подключение к KVM извне, если это не настраивалось ранее.
Разрешение экспорта машин в KVM
В статье расскажу о быстрой настройке для небезопасного подключения, предназначенного только на время импорта машины. Не используйте эту схему для постоянной работы! Предполагаю, что импорт нужен на короткое время, после чего предыдущий хост будет выведен из эксплуатации, либо настройки будут возвращены к предыдущим значениям. Процедура также описана в документации, напр., к
You must be registered for see links
.В параметрах, передаваемых демону 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://[email protected]/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.
Если задача выполняется более или менее штатно — достаточно штатных инструментов. С пимерами и картинками можно посмотреть
You must be registered for see links
.Задачи выполняются на oVirt-host'е.
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Host getAllTasksInfo
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task getStatus taskID=
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task stop taskID=
[mgmt@ovirt-nodeNN] $ sudo vdsm-client Task clear 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');
Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!