Сегодня мы рассмотрим ряд базовых операций, которые регулярно потребуется выполнять администратору среды виртуализации. Статья — продолжение серии по oVirt: часть 1, часть 2 и часть 3:
Традиционно, для подробностей по административным задачам — добро пожаловать в документацию.
При входе в oVirt Вы увидите 2 портала:
Первый предназначен для администратора и административных задач, второй — для заказчиков машин, но может быть использован и администратором — некоторые функции там делать даже удобнее.
Вверху окна каждой коллекции объектов oVirt есть мощное окно поиска, с контекстными подсказками.
Как пример, выбор проблемных хостов в панели управления на самом деле вызывает фильтр:
Думаю, простую ВМ Вы создали уже во 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 держать предзапущенными и готовыми к подключению пользователей указанное количество машин. На этом о машинах, шаблонах и пулах завершим и перейдем к миграции.
Основные значки ВМ:
Миграция состояния включенной машины выполняется просто — правый клик по машине или группе машин. Процедура похожа на аналогичную vMotion в vSphere.
Рис. 5 — Запуск миграции.
Compute -> Virtual Machine, выбрать одну или несколько машин, Migrate.
Рис. 6 — За процессом миграции можно наблюдать в хостах (Compute -> Hosts).
В один момент времени переезжает не более 2-х машин.
А вот эта процедура пользователю 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 (мажорное), когда меняется номер версии (это более сложная процедура и не входит в ежедневные задачи).
Обновление хостов выполняется проще, чем в vSphere, менеджер обновлений в oVirt органично встроен в платформу и не требует настроек. Официальная документация об обновлении.
Рис. 7 — При наличии обновлений менеджер сообщит о них значком компакт-диска.
Рис. 8 — Перед запуском обновления нужно включить режим обслуживания (Management -> Maintenance), он автоматически запустит миграцию ВМ на другие хосты (см. рис. 6) и подготовит к обновлению.
Рис. 9 — Значок гаечного ключа сообщает о готовности хоста к обслуживанию.
Рис. 10 — Installation -> Upgrade запускает процедуру обновления.
Рис. 11 — Мы можем попросить менеджер дать хосту команду на перезапуск после окончания обновления, для вступления его в силу.
Рис. 12 — После перезагрузки выводим гипервизор из режима обслуживания (Management -> Activate).
Проходим все хосты и обновляем их.
По началу это может сбить с толку, но обновление менеджера выполняется при помощи engine-setup, с дополнительными шагами, как описано в документации.
Импортировать можно из VMware, Export Domain (специальная сущность oVirt для обмена образами между Data Center), Virtual Appliance (OVA), XEN, KVM. Все официально поддерживаемые варианты:
Остановимся на 2-х вариантах — импорт из vSphere и отдельно стоящей машины с KVM. Для запуска матера импорта в Compute -> Virtual Machines нажимаем кнопку дополнительных пунктов меню (3 вертикальные точки, см. рис. 13). Исходная машина должна быть выключена.
В мастере:
Рис. 13 — Импорт ВМ из VMware vSphere.
Подробности об импорте из KVM в документации.
Сперва надо разрешить подключение к KVM извне, если это не настраивалось ранее.
Далее сам импорт выполняется очень просто:
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'е.
Дополнительно 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 для проблемной задачи:
Пример:
Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!
Содержание
- Создание ВМ и шаблона;
- Миграция ВМ (live migration);
- Миграция хранилища (storage migration);
- Переименование ВМ и диска;
- Обновление oVirt-Host (гипервизор);
- Обновление oVirt-Engine (менеджер);
- Импорт ВМ;
- Управление задачами.
Статьи
- Введение
- Установка менеджера (ovirt-engine) и гипервизоров (hosts)
- Дополнительные настройки
- Базовые операции — Мы здесь
Традиционно, для подробностей по административным задачам — добро пожаловать в документацию.
При входе в 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, с дополнительными шагами, как описано в документации.
- По возможности сделать архив либо снимок машины, убедиться, что последняя плановая архивация прошла без ошибок.
- Проверяем и обновляем установочные пакеты:
$ 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. 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
- Выполняем обновление ОС и остальных дополнительных пакетов:
$ 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 в документации.
Сперва надо разрешить подключение к KVM извне, если это не настраивалось ранее.
Разрешение экспорта машин в KVM
В статье расскажу о быстрой настройке для небезопасного подключения, предназначенного только на время импорта машины. Не используйте эту схему для постоянной работы! Предполагаю, что импорт нужен на короткое время, после чего предыдущий хост будет выведен из эксплуатации, либо настройки будут возвращены к предыдущим значениям. Процедура также описана в документации, напр., к ArchLinux.
В параметрах, передаваемых демону libvirtd
раскомментировать стороку
Создать резервную копию конфигурации и разрешить подключение
внеся следующие настройки:
Для диагностики дополнительно нужно раскомментировать строку
После чего нужно перезапустить libvirtd. На работающих гостевых машинах, начиная с версии libvirtd > 0.6 (проверка версии libvirtd --version), это не скажется.
Далее нужно разрешить в брандмауре tcp:16509.
В CentOS 7 временное разрешение делается так (без ключа permanent):
Проверка подключения:
В параметрах, передаваемых демону 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');Сегодня на этом все и, надеюсь, ручное редактирование БД Вам никогда не понадобится!
werter78
Спасибо за подробное руководство.
Вопрос. В чем преимущество перед теми же Proxmox VE и\или Opennebula?
Зы. Пробовали ли RH VDO прикрутить на ноды для дедупликации?