This sounds like a lot of fun. What are you doing with those VMs?
I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes.
Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky.
SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
* Aggressively compile out unused features/devices.
* Confine each VM with separate SELinux contexts (sVirt).
* Run qemu as a special non-root user.
* Use seccomp to confine the system calls.
* Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy).
* Run qemu in a cgroup.
* Run qemu-img with resource limits.
* Compile qemu with all hardening features enabled like RELRO, PIE, etc.
* Audit the code manually and with Coverity.
* Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu).
Probably more that I've forgotten about ...