Hi The first issue of booting UEFI guests at all is resolved, honestly I don't know what I messed up the first time with Windows guests. TL;DR: Q35 and UEFI (with or without SecureBoot) should do the job in many cases.
Can you give a try of the workaround in https://bugzilla.redhat.com/show_bug.cgi?id=1727987#c0 ?
At least it works for RHEL 8 (and most probably CentOS 8). Thanks for pointing to this Bugzilla. But no, I'm pretty certain it's only partially related in the case for Debian. I've tried to replicate your findings with both RHEL and CentOS 8.0 ISOs but failed to get the guests booted into the installed (Stops at "pciehp... Failed to check link status") nonetheless I'll share my findings with Debian on that bug if possible.
TL;DR: The issue affecting Debian and openSuse however ends up being the same: Lack of a persistent NVRAM in oVirt guests as Michael Skrivanek as outlined there. While openSuse has its own signing keys but in the "default right"place for OVMF (boot/bootx64.efi), Debian has obtained a Microsoft-signed shim loader like RHEL but doesn't put in the place where the non-persisted OVMF is looking for (debian/shimx64.efi). ("mokutil --db" from a UEFI guest shows the 2 main Microsoft UEFI CAs included in the OVMF image of oVirt guests.) Ubuntu - confirmed with 18.04 - seems to do something clever: They seem to put an extra copy of ubuntu/shimx64.efi into the default location boot/boox64.efi where even the most broken UEFI implementations (read: often old physical ones in my experience) look for a loader. RHEL8 seems to do a similar thing on other UEFI platforms, but I've only been able to get RHEL8 booted/installed in UEFI mode on (FreeBSD) bhyve as of writing. Debian doesn't do that sort of thing (yet) so you need to copy debian/shimx64.efi to BOOT/BOOTX64.EFI then booting works. You need to manually update that copy on Debian whenever they ship a new version of that binary but at least it does work. Regards, Mathieu