Кибербекап: развёртывание virtual appliance для oVirt

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

Начну с того, что официально текущий релиз oVirt 4.5 не поддерживается и будет поддерживаться скорее всего уже в 16-й версии, которая, как я думаю, появится ближе к концу первого квартала 23-го года (примерно в те же сроки, что и Veeam V12). Но что помешает мне попробовать?

Кибербекап умеет самостоятельно разворачивать прокси аплаенсы для систем виртуализации с которыми работает, соответственно, я и пошёл по наиболее простому и логичному пути — автоматическому. Но после введения учётных данных от oVirt сразу же получил ошибку «Неправильный аргумент запроса», из чего можно было сделать вывод, что Кибербекап получил от oVirt ответ, которого не ожидал, либо передал какой-то неподдерживаемый параметр. Самым простым была посмотреть что же происходит со стороны системы виртуализации, а там уже была создана виртуальная машина Acronis_Agent_for_oVirt и во всю шёл процесс загрузки её диска, что вселило в меня надежду на удачный исход задумки. Но по окончании процесса загрузки диска виртуальная машина просто пропала. Я повторил операцию пару раз, чтобы убедиться в том, что симптомы одни и те же, после чего приступил к изучению логов. Самый полезный в данном случае лог это va-deployer, который располгается на сервере управления КБ в папке C:\ProgramData\Acronis\VaDeployer\Logs. Из него можно было сделать вывод, что R< как-то неверно отслеживает прогресс загрузки диска виртуальной машины на сервер и пытается запустить виртуальную машину до окончания загрузки.
2022-11-16T16:18:06.040+0300 INFO Request finished successfully: [status: 200]
2022-11-16T16:18:06.060+0300 INFO Request finished successfully: [status: 200]
2022-11-16T16:18:06.066+0300 INFO Deploying oVirt VA to engine ‘https://ovirt-mgr.korphome.local’, login ‘admin@ovirt@internalsso’
2022-11-16T16:18:06.494+0300 INFO Creating virtual machine ‘Acronis_Agent_for_oVirt’ in cluster ‘e637dc94-6599-11ed-8b04-005056b8956d’
2022-11-16T16:18:06.908+0300 INFO Virtual appliance’s system tag already exists: acronis_virtual_appliance
2022-11-16T16:18:06.935+0300 INFO System tag ‘acronis_virtual_appliance’ assingned to virtual appliance
2022-11-16T16:18:17.783+0300 INFO Uploading disk to storage ’47b0a2cf-a02d-4b97-b767-0e8bec3d5fb0′
2022-11-16T16:18:18.694+0300 INFO Transferring disk data to https://192.168.1.43:54322/images/b16026f5-6e58-420d-a0f5-cbbc8eab3c1a
2022-11-16T16:19:55.518+0300 INFO Attaching disk ’53db105c-dc2f-4c29-b3a4-33fc795baa04′ to VM ‘489cc0e4-cce7-4ddb-bca5-936d500cf171’
2022-11-16T16:19:55.625+0300 ERROR Attach uploaded disk to VM failed with error: Fault reason is «Operation Failed». Fault detail is «[Cannot attach Virtual Disk. Disk appliance_disk is being transferred.]». HTTP response code is «409». HTTP response message is «409 Conflict».
2022-11-16T16:19:55.752+0300 ERROR Failed to deploy oVirt virtual appliance: va-deployer.failedToAttachDiskToVM: Fault reason is «Operation Failed». Fault detail is «[Cannot attach Virtual Disk. Disk appliance_disk is being transferred.]». HTTP response code is «409». HTTP response message is «409 Conflict».
2022-11-16T16:19:55.752+0300 ERROR Failed to deploy oVirt VA for task 1268652985345376256: va-deployer.failedToAttachDiskToVM: Fault reason is «Operation Failed». Fault detail is «[Cannot attach Virtual Disk. Disk appliance_disk is being transferred.]». HTTP response code is «409». HTTP response message is «409 Conflict».
2022-11-16T16:19:55.752+0300 INFO Completing task 1268652985345376256 with result: va-deployer.failedToAttachDiskToVM: Fault reason is «Operation Failed». Fault detail is «[Cannot attach Virtual Disk. Disk appliance_disk is being transferred.]». HTTP response code is «409». HTTP response message is «409 Conflict».

Собственно, это поведение подтвердили и сотрудники технической поддержки и пообещали что что-то будет исправлено в 16-й версии, где должна быть и поддержка oVirt 4.5. Но ведь задачу я так и не решил, поэтому воспользовался вторым вариантом — ручное разворачивание аплаенса.
Скачиваем его с сайта, загружаем на хост, делаем импорт и получаем готовую виртуальную машину, которую и пробуем запустить. Но чуда не произошло — oVirt выдал ошибку при запуске машины
Exit message: unsupported configuration: domain configuration does not support video model ‘qxl’.
Естественно, я сразу открыл настройки виртуальной машины и посмотрел графические настройки консоли. К моему удивлению, вместо режима QXL, я увидел VGA.

Поверив собственным глазам я попытался запустить машину ещё несколько раз, но снова получил ту же ошибку. Графических режимов на выбор у меня всего два — VGA и QXL, который и так не поддерживается. Тогда я решил попробовать запустить машину, отключив графику — в Headless режиме. После чего машина успешно стартанула и даже получила адрес по DHCP. Но такое положение вещей меня не устраивало, ведь я разворачивал аплаенс вручную и мне необходимо было указать внутри настройки подключения к гипервизору и серверу управления. Я выключил виртуальную машину, не испытывая особых надежд отключил Headless Mode и снова запустил машину. Я был сильно удивлён, не получив ошибки запуска от oVirt, а открыв консоль VM увидел, что она вполне успешно загружается. Дальше оставалось уже дело техники — просто указать параметры подключения и получить уже рабочую систему

Собственно причина ясна и понятна — в моём кластере действительно нет поддержки QXL, а в шаблоне OVirtAppliance используется именно он.

ПС если вы только знакомитесь с системой oVirt и читаете мануалы, в том числе и на сайте ovirt.org, то хочу поделиться одним секретом, который я не увидел в документации, а нашёл лишь в Release Notes к версии 4.5.1. Если вы внимательно читали лог или посмотрели на скриншот, то увидели довольно странный логин — admin@ovirt@internalsso, хотя во всех документация он указывается как admin@internal. Так вот выдержка из Release Notes:
oVirt administrators will be able to fully use Keycloak capabilities in terms of setting up authentication/SSO mechanism and multiple user bases. Please note that default ovirt administrator user name has been changed from ‘admin’ to ‘admin@ovirt’ (Administrator Panel, VM Portal) and from ‘admin@internal’ to ‘admin@ovirt@internalsso’ (REST API).
Соответственно, и все пользователи теперь создаются также через панель Keycloak, а не ovirt-aaa-jdbc-tool, который описан в документации.