Description of problem: Centos Stream 9 and RHEL9 now assumes a x86_64 cpu supporting x86_64-v2. https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level This means that for example (bug 2079915) that booting a RHEL9 iso with "qemu-kvm -m 2048 -boot d -cdrom ..." panics, which is a little surprising. As noted in the above bug a workaround is to use "-cpu host", but that is probably not immediately obvious to most users. So I am wonder if it would be better to try to default qemu-kvm to "-cpu host" or x86_64-v2 for a qemu-system-x86 vm?
Thanks for the report. It's already generated a lot of bugs and discussions elsewhere, See this upstream qemu thread for example from almost a year ago: https://lore.kernel.org/qemu-devel/20210607135843.196595-1-berrange@redhat.com/ But we won't change Fedora to differ from upstream here. Until upstream changes, best to consider `-cpu host` a mandatory option, like `-m XXX` is to get a usable ram mount.
Okay thanks, Cole ((I still feel from my limited perspective that `-cpu host` would be a pretty sane default anyway.))
Using '-cpu host' would mean that live migration is significantly restricted in a default scenario, so that's non-trivial change. At the libvirt level we have a 'host-model' which is close to '-cpu host' but with improve live migration support - some apps using libvirt explicitly set this as a default, such that the QEMU default is irrelevant. Overall we expect the majority of people to be using apps built using libvirt, rather than invoking QEMU directly, because there is sooo much more to configuring a well performing VM than the few CLI args shown aove. Also note it would actually have to be '-cpu max', because '-cpu host' doesn't exist as a model for TCG (emulation), only for KVM. '-cpu max' is equivalent to '-cpu host'.