[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

["berrange at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

Daniel Berrange <berrange at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |berrange at redhat dot com

--- Comment #13 from Daniel Berrange <berrange at redhat dot com> ---
(In reply to H.J. Lu from comment #6)
> (In reply to H.J. Lu from comment #5)
> > 
> > virt-manager defaults to "Copy host CPU configuration".  On
> > Westmere, when I selected the qemu64 device model, I couldn't
> > even power on the VM since my host CPU isn't compatible with
> > qemu64 due to the missing SVM feature.
> 
> Since Intel CPUs don't have SVM and the qemu64 device model requires
> SVM, how can libvirt default to the qemu64 model?

There's some subtle behavioural things going on here as there's two different
ways qemu64 can get used.

In the libvirt XML config, if *no* <cpu> element is present at all, then QEMU's
built-in default "qemu64" model is used.   When it does this, it operates in a
relaxed mode where any features in qemu64 that don't exist in the host and
dropped from the CPU exposed to the guest. IIRC, there is a message in
/var/log/libvirt/qemu/$GUEST.log for each feature that is dropped in this way.
In this mode you can use qemu64 on an Intel host and "svm" will be dropped. I
don't believe you can configure this way in virt-manager, as it tries hard to
ensure you always have an explicit CPU specified to follow best practice. If
you want to test it use 'virsh edit $GUEST' to manually delete the <cpu>

Conversely if you specify a <cpu mode='custom''><model>qemu64</model></cpu>,
then it will operate in strict mode, where QEMU will refuse to start the guest
if the host lacks features. In this mode you can NOT use qemu64 on a Intel host
because 'svm' doesn't exist.

Yes, this is confusing, but we have to maintain the historical behaviour for
upgrade / live migration compatibility.

Well maintained applications will *always* specify a <cpu> in libvirt and pick
a sane modern model.  If live migration is not required, then using simple
host-passthrough is simplest. If live migration is required, then a named model
that matches your host CPU generation is best (Westmere, IvyBridge, Nehalm,
Broadwell, etc).  This is described

https://qemu.readthedocs.io/en/latest/system/target-i386.html#recommendations-for-kvm-cpu-model-configuration-on-x86-hosts

All widely used libvirt apps that are actively maintained by their upstream,
should be doing the thing thing in this area. oVirt, OpenStack, virt-manager,
virt-install, GNOME Boxes, Cockpit all do the right thing. Unfortunately the
'oz' program that Florian mentions is barely maintained and not following
recommendations, thus hitting the problem due to its reliance on the builtin
defualt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.