The problem here is that every Linux distro, and releases within distros, does things differently even when it comes to "common" services like qemu-kvm/libvirt.
Not sure why distro publishers continue to insist on that, but it results in a lot of wasted time downstream. My message, if I could get any of them to pay attention, would be: STOP IT!
I recently created a new Windows 11 guest in KVM on my Ubuntu 22 LTS Desktop system. My main motivation was to try running a game my kids had created, which I knew was going to require 3D accelerated graphics (whose installation is a matter for a different gist).
The installation went well. The trick, at least on Ubuntu 22.04's configuration of KVM, was to create a fresh guest and be sure to use the dropdown on the Overview tab to select a UEFI firmware (in my case, OVMF_CODE_4M.ms.fd) and to add an Emulated TPM 2.0 device (pass-through didn't work for me). Note, I did try and fail to change the settings of an existing guest from BIOS to UEFI as the Internet proclaimed that could easily be done. It couldn't.
Unfortunately, I did the install to a virtual SATA disk, instead of selecting Virtio and supplying the viostor driver during install. If you go that route, as used to be de rigueur in turn of the century server hardware installs, you won't have to deal with any of the nonsense here. Just remember to add a second SATA CDROM device to mount the latest Virtio ISO on.
So I had to find a way to change that SATA boot disk to Virtio. The Internet (as usual) was full of confident advice, just as it is for just about everything. They were all wrong. Of course they were. Most of those discussions made no mention of the distro being used, let alone the particular version of qemu-kvm/libvirt being employed.
It turns out the answer was simple, yet devious.
Even though I'd already installed all the VirtIO drivers on the guest, including viostor and the other storage drivers, they weren't loading during boot. They answer was to create a dummy virtio disk first that would ensure the drivers were loaded. Once the guest had been rebooted it was time to shut down again and replace the SATA boot disk with another new VirtIO disk (created using virt-manager and setting it to use the boot disk's qcow2 image). I then deleted the SATA disk and used virsh edit to make sure the new VirtIO boot disk was set as vda. Then another startup.
Voila! It worked!