Оно везде управляет kvm, кроме Нутаникса и Опенстека

Это не верно. Оно управляет только в ovirt. Ну и rhev, потому что он и есть ovirt. 😄

Вы пишете "везде" и тут же указываете 2 альтернативы на базе kvm.
Я добавлю ещё, например, proxmox.

Итого, получается что ovirt используется только в ovirt 😅

Proxmox разве не на ovirt?

Давайте начнем с начала =) квм это кусок ядра, который реализует возможность запускать виртуалочки. С этим все согласны?

Но не стоит продолжать экскурс в системы виртуализации в теме про бэкап 🙄
Относительно бэкапа, в частности Veeam, важно то, что ovirt предоставляет полноценный Backup-Restore API (не так давно, кстати). И Veeam добавил его поддержку.
И на самом деле не важно что за гипервизор в основе, поскольку это относится к управлению образами дисков, а не к гипервизору. Можно прикрутить к ovirt xen. И с точки зрения Veeam ничего не поменяется

Примерно так.
И говорить "поддержка бэкапов kvm" всё равно что запросить "поддержку бэкапа vmkernel" относительно VMware.

Vsphere ))

Ну есть ещё отдельно esxi, который тоже поддерживается 😜

PS: как раз сфера - это и есть аналог ovirt. (Ну точнее наоборот конечно).
По уровню абстракции.

что то мне подсказывает, что если к овирту прикрутить ксен - вим ничего не забекапит 🙂

Он не увидит этот уровень. Используемый гипервизор в api бэкапа не фигурирует 🙄
Бэкап - это не работа с гипервизором, а работа с его окружением. Запустить снапшот диска, или трекинг его изменений, или сделать снимок памяти. Эти механизмы предоставляет система управления гипервизором.
По этому и невозможно сделать поддержку "сферического kvm".

Думаю вы всё таки перепутали oVirt и libvirt🤔

Сколько вы вообще выделяете ресурсов ВМ с VeeamBackup (Я повысил с 8 до 16 ядер AMD Epyc и 16 Гб ОЗУ) ? Есть ли какой-то профит, если выделяешь сверхмеры? Просто ресурсы сервера простаивают, так не хватает дисков под другие системы.

Если уж правильно говорить, то "среднеуровневый" api у kvm — это libvirtd. У которого есть всякие ендпоинты для ovs, zfs, qemu, xen, lxc, rbd и прочая.
Все эти опенстаки, овирты и проксмоксы — это уже API на control plane (типа muon, nova, cinder).
Так вот. "Появился API для бэкапа kvm" — если речь идёт про libvirtd — то это очень громко сказано. По факту демон поддерживает app-consistent snapshots только для образов дисков qcow2, которые не просто убоги, а очень убоги. Из-за i/o оверхеда страждущие уходят на lvm-thin-pool, zfs, ceph и аппаратные снапшоты, которые по определению crash-consistent. Хуков для сигналов в гостя сделать sync и fsfreeze, ну, как бы так сказать... не научились, в общем.
Hy и на всякий случай проверил, virsh backup-begin выдаёт еггог, гугл которого выдаёт линки на багзиллу :)

Вы тоже путаете слова oVirt и libvirt?

Овирт это очередной фронтенд к libvirtd, чего непонятного?

Не понятно как это относится к veeam? 🤔
Вопрос начинался примерно так: "появилась поддержка oVirt, почему не поддержано всё что на kvm?"
Ответ: потому что veeam работает с api, как вы выразились, "фронтенда".

https://www.ovirt.org/documentation/incremental-backup-guide/incremental-backup-guide.html#backup-rest-api

Так что нет, речь идёт не про libvirt