Problem ------- When a user doesn't provide any <cpu/> element in the guest configuration, libvirt doesn't automatically add it. So you have have no way of knowing _what_ CPU your libvirt-launched guest is using. (Unless you look at the QEMU source to figure out the default CPU model, which is 'qemu64', for x86 hosts). Users should be reminded of the CPU model they are using. Especially so when they are using an inefficient and insecure model such as the default 'qemu64'. Steps to reproduce ------------------ (1) Edit a libvirt guest configuration and remove any <cpu/> element in it. (2) Boot the guest. Actual result ------------- Guest starts fine. But no <cpu/> element in the libvirt XML configuration -- which, in turn, means no '-cpu qemu64' on the QEMU command-line either. Expected result --------------- Guest should be assigned a <cpu/> element with the QEMU / libvirt default CPU model 'qemu64'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still relevant. Not sure how easy it is to implement this generally, if qemu has some API that reports the default CPU model or if libvirt has to hardcode it. Kashyap is this still important? If so please move it to the upstream tracker, product=Virtualization Tools component=libvirt
Moving to upstream tracker, since Fedora doesn't do RFEs QEMU doesn't report default CPU model against query-cpu-definitions since this varies per machine type and QMP probing is done with "none" machine type. The challenge with hardcoding it is that we don't know if what libvirt hardcodes really matches what QEMU runs with later. Machine types are not easily introspectable, but we have dealt with this on a case by case basis to expose some limited info via query-machines. I think it would be viable to get this to expose default CPU model per machine type.
Proposed a QEMU patch that could help for libvirt https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg04906.html
Patches sent for review: https://www.redhat.com/archives/libvir-list/2019-October/msg00140.html
Acked version 3 of the series: https://www.redhat.com/archives/libvir-list/2019-November/msg00070.html
Implemented by commit 5e939cea896fb3373a6f68f86e325c657429ed3d Refs: v5.9.0-352-g5e939cea89 Author: Jiri Denemark <jdenemar> AuthorDate: Thu Sep 26 18:42:02 2019 +0200 Commit: Jiri Denemark <jdenemar> CommitDate: Wed Nov 20 17:22:07 2019 +0100 qemu: Store default CPU in domain XML When starting a domain without a CPU model specified in the domain XML, QEMU will choose a default one. Which is fine unless the domain gets migrated to another host because libvirt doesn't perform any CPU ABI checks and the virtual CPU provided by QEMU on the destination host can differ from the one on the source host. With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for a particular machine type and store it in the domain XML. This way the chosen CPU model is more visible to users and libvirt will make sure the guest will see the exact same CPU after migration. Architecture specific notes - aarch64: We only set the default CPU for TCG domains as KVM requires explicit "-cpu host" to work. - ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU, we will translate the default model to the model corresponding to the host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.). This is not a problem as the corresponding CPU model is in fact an alias for "host". This is probably not ideal, but it's not wrong and the default virtual CPU configured by libvirt is the same QEMU would use. TCG uses various CPU models depending on machine type and its version. - s390x: The default CPU for KVM is "host" while TCG defaults to "qemu". - x86_64: The default CPU model (qemu64) is not runnable on any host with KVM, but QEMU just disables unavailable features and starts happily. https://bugzilla.redhat.com/show_bug.cgi?id=1598151 https://bugzilla.redhat.com/show_bug.cgi?id=1598162 Signed-off-by: Jiri Denemark <jdenemar> Reviewed-by: Ján Tomko <jtomko>