On Thu, Oct 21, 2021 at 10:56:42AM -0700, Clark Boylan wrote:
On Thu, Oct 21, 2021, at 10:49 AM, Kashyap Chamarthy wrote:
[...]
To fix this, please update the CPU model to "Nehalem". It is the oldest CPU model that is compatible with CentOS-9/RHEL-9 "x86-64-v2". Further, Nehalem also works with `virt_type=kvm|qemu`, _and_ on both Intel and AMD hardware. So this is a good alternative.
Thank you for looking into this and providing such detailed information. It has been really helpful.
No problem at all. I should've wrote this a bit sooner. [...]
Why is "qemu64" model undesirable for production? -------------------------------------------------
[...]
An understandable reason why CI systems running in a cloud environment go with 'qemu64' is convenience: with 'qemu64', you can live-migrate a guest regardless of its underlying hardware (whether it's Intel or AMD). That's one main reason why upstream DevStack defaults to it.
I've got a change up to Devstack to convert it over to Nehalem by default [5]. So far it looks good, but we will want to recheck it a few times and make sure we have good test coverage across the clouds we run testing on just to be sure that the CPUs we get from those clouds are able to support this CPU type. Good news is that we successfully built a centos-9-stream image and booted it with the Nehalem change in place [6].
I see that the DevStack default has now merged. Very cool. If anyone is wondering: "How come the 'Nehalem' QEMU CPU model works on both Intel and AMD hardware?". The answer is the CPU feature flags in Nehalem happened to supported by both Intel and AMD. Joy to us!
Overall, the thumb-rule here is to either always explicitly specify a "sane" CPU model, based on the recommendations here[3]. Or to use Nova/libvirt's default ("host-model").
Devstack is currently setting cpu_mode to none. Should Nova be updated to make this result in a better behavior? Is this literally not passing a cpu mode to libvirt/qemu and allowing them to choose a default? If so maybe libvirt/qemu need to update their defaults?
Yes, if you explicitly set `cpu_mode=none`, that does mean "use whatever is the default of QEMU". And no, we cannot update Nova to "result in better behaviour" for `cpu_mode=none` -- it essentially means changing the hypervisor-reported default from "qemu64" to something else in Nova. Changing the default in libvirt/QEMU is also very difficult -- "hysterical raisins" :-(. The reason is the following (thanks, Daniel Berrangé): Historically, QEMU never reported[1] what the default CPU model was. So libvirt assumed it was "qemu64". But unfortunately, until very recently[2][3] libvirt didn't expand this into the XML configs. So if upstream QEMU ever changes its default it would impact guests without an explicit XML config for CPU. * * * In any case, FWIW, Daniel also echoes what I noted in my previous email: in practise, both the upstream QEMU and libvirt defaults are "reasonably irrelevant" -- essentially any serious management tool will be setting an CPU model explicitly (Nova sets it to `host-model` for the KVM/QEMU driver). [1] [QEMU] https://gitlab.com/qemu-project/qemu/-/commit/04109957d4 -- qapi: report the default CPU type for each machine [2] https://bugzilla.redhat.com/show_bug.cgi?id=1598151 -- [RFE] Add 'qemu64' as the CPU model if user doesn't supply a <cpu/> element [3] [libvirt] https://gitlab.com/libvirt/libvirt/-/commit/5e939cea89 -- qemu: Store default CPU in domain XML -- /kashyap