Насчет остальных не знаю, но лично я не против.

нет, просто как GUI можно использовать cockpit.

Есть свои нюансы и засады, но если надо куда-то валить с вмтвари - альтернатив просто нет. Ну да - XCPng есть, но там вечная проблема с тем что Citrix последовательно кастрируют опенсоурсную версию Xen

Если системный администратор разбирается в тонкостях ОС Linux он сможет легко использовать oVirt и ей подобные, потому что это всего-навсего надстройка над всем тем, что и так есть в Linux.

Тем кто покрупнее я предложу еще сверху накрутить OpenStack для того чтобы иметь возможность разделять инфраструктурные проекты между разными отделами и регионами. Видите ли, oVirt без OpenStack в проде это действительно редкость, отсюда ваш вполне закономерный вопрос. Если же используется OpenStack, то его рекомендуется сейчас использовать либо поверх oVirt либо вам нужно что-то дополнительно такое что решает вопросы, с которыми у oVirt плоховато:

1. Не так страшен oVirt как его storage
Red Hat уже начал писать новый сторадж, чтобы решить все эти проблемы, но его пока еще нет, поэтому напишем о проблемах по-факту. Гиперконвергентное развертывание oVirt в сочетании с GlusterFS в ненадёжных руках - это карточный домик. Под HCI-развертывание предлагаются отдельные образы за подпиской и к ним нужно докупать хотя бы базовый саппорт от RH, потому что его очень легко сломать и трудно починить. Кроме того как и под любое HCI-решение требуется выполнить уйму сетевых требований, которые новичку будут не понятны, а документация опять по подписке. Вторая проблема - это Ceph. Ceph - это конвергентное объектное хранилище. Для размещения виртуалок на сверхбыстрых NVMe дисках эта штука пожирает производительность фактом своего существования на отдельно стоящем кластере и кучей абстракций в юзерспейсе. Для медленного стораджа и для контейнеров он хорош, хоть поедает много ресурсов CPU. Опять же, если кто-то догадается совместить его кластер с кластером виртуализации, то он познает боль. Последнее что вы захотите делать - это играть в угадайку, где чего накрутил RH в своих продуктах и дистрах (документация закрыта подпиской), когда у вас сторадж упал. В этом смысле Microsoft Storage Spaces проще и понятнее. Это всё уступает даже VMware VSAN, который мягко говоря отстаёт от S2D по поддержке некоторых HCI-топологий.

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

2. Забудьте про Virtual Desktop на oVirt
oVirt - это самое плохое, что может случиться с компанией, которая применяет виртуализацию рабочих мест с использованием графических ускорителей. Там всё настолько плохо с поддержкой API, что самое лучшее что вы можете сделать - поставить рядом кластер с Xen. Проблема виртуализации десктопов в том, что хосты виртуализации тюнятся совсем по другим принципам. В условиях обычной виртуализации вам нужна предсказуемость работы вашего оборудования и предсказуемая производительность. По виртуальные десктопы вы захотите, чтобы планировщик процессов гипервизора четко интегрировался с планировщиками процессов гостя и играл с ними в игры через SMT (Hyper Threading и его временное отключение на ядре при использовании Turbo Boost). Кроме того вам нужна поддержка виртуализации GPU адаптеров и поддержка Pass Through не только на уровне гипервизора, но еще и на уровне API управления, чтобы генерировать динамические виртуальные машины по из шаблонов. Пользователи при этом имеют перемещаемые профили. oVirt даже в сочетании с NiceDCV может очень мало и все хосты под десктопы всё равно не должны принимать на себя виртуальные сервера, поэтому почему бы действительно не поставить рядышком Xen.
Опять же, если у вас нет задач по массовой виртуализации десктопов, вам этот минус не актуален. Это не значит, что в oVirt нельзя использовать GPU или заниматься расчётами, можно. И прокидывать их можно. Теоретически, всё можно. Даже Proxmox может, однако на практике там ну никакой автоматизации нет, хоть Hyper-V ставь. Когда у вас этих десктопов больше 200 становится невыносимо.

3. Не минус, а скорее специфическая особенность рынка. У всех инфраструктурных решений с KVM либо жутко дорогие бекап-решения, либо совершенно костыльные. Commvault да и даже Acronis стоят не малых денег... Это так странно, когда даже платная версия RHEV вам обходится дешевле её же бекапилки...
Костылестроителям на ансибле, который зачастую вращается внутри той же самой инфраструктуры хочется передать пламенный привет и напомнить, что нужно бекапить еще и менеджмент-ноды и уметь восстанавливать машины в другие кластеры и восстанавливать машины конвертациями в другие гипервизоры. Встречал я такие бекапы выключенных виртуалок сделанных tar.gz, которые восстановить оперативно не получается. Но это не проблема oVirt, это просто низкая конкуренция готовых бекап-решений под KVM. Низкая конкуренция -> высокая цена.

Если с п.2 смирятся десятки тысяч даже самых крупных бизнесов (не всем нужен VD), то п.1 это большое техническое ограничение, которое обуславливает низкую цену на платные версии RHEV по сравнению с конкурентами. Под "низкую" я имею в виду в 10 раз ниже!

oVirt имеет значительное преимущество перед Proxmox, например, потому что не имеет такой убогой сети.
Точнее как... Он её имеет и умеет, но вам вовсе не обязательно страдать, вы можете просто использовать OpenStack Neutron в рамках вашего кластера. И совершенно пофиг, что ваша вышестоящая сеть не понимает VXLAN и не поддерживает VRF и не поднимает VTEP-ы на вышестоящих коммутаторах. Всё лучше чем то что делает Proxmox (а точнее НЕ делает).

У Proxmox и oVirt есть еще одна общая черта: уронить виртуалку OOM-киллером. Ни один ни второй не имеют защиты от дурака и не учит дуралеев-админов считать overcommitment ни по CPU, ни по RAM. А это придётся делать отдельно самостоятельно мониторингом. Причем второе (по RAM) разительно сложнее, потому что см п.1 если вы впаяли HCI-сторадж как попало, то идите угадайте, сколько нужно на ноде под страничный кэш и пересчитайте калькуляцию по памяти доступной под VM. oVirt за вас это не сделает. Хотите дешевый HCI-кластер, который не позволит вам отстрелить себе ногу, купите Virtuozzo или System Center.

Если выбирать между решения поверх KVM я рекомендую oVirt/RHEV всем кто не готов платить, остальным Virtuozzo. Бомж-решения (proxmox) и буржуй-решения (nutanix) я не признаю. Если вам нужен виртуальный рабочий стол, я порекомендую поставить рядом Citrix (Xen) в классическом конвергентном развертывании или даже Hyper-V, потому что ну очень плохо с этим на KVM. VMware не предлагать, ею я сыт по горло. Соотношение цена/качество там как у нутаникса, но она распиарена дурачками админами, которые её ставят ломаную по мануалу из интернета и не знают, что с ней делать.

Оговорюсь, что я сейчас выдвигаю предложения для небольших развертываний от 16-32 физических серверов с конвергентной сетью не ниже 10G на адаптер (коих у вас как минимум 2) и соответствующие коммутаторы хотя бы парочка в MLAG. Если вы используете что-то меньше чем 5 физических серверов, то целесообразность oVirt для вас под вопросом. Вам тогда должно быть вообще всё равно...

Получите. Можешь даже запустить целый один свой личный десктопчик. А дальше с него параллельный ксен настроить, например. Платный, конечно.

И да, после похорон последнего вменяемого протокола для этих десктопчиков как-то и непонятно, на чем их теперь делать редхату. (SPICE же предан анафеме как NiH и вообще щас покажем как нада...ой, ну вода сегодня холодная, а так-то у нас огого и эгеге)