Re: [libvirt] [virt-devel] [RHEL6 PATCH] Correct cpuid flags and "model" fields, V2
A question arose in today's kvm meeting concerning any
impact to libvirt from this change. I've discussed it
with Cole and it seems to be a non-issue. But just to
err on the side of caution, here's a summary:
The current cpu model definition of "qemu64" upstream
is problematic from kvm's perspective such that we need
to modify it slightly (BZ justifications listed below).
Doing so we've left the qemu64 definition as-is, but
added "cpu64-rhel6" and "cpu64-rhel5" models which
are now selected by default via "-M <machine>", for
"RHEL 6.0.0 PC" and "RHEL 5.x.y PC" respectively.
I was following the whole thread and I would have stepped in in case libvirt
was affected by the change. Still, thanks for keeping libvirt on your mind.
So the only issue would be libvirt invoking qemu with
neither a "-cpu" nor "-M" argument (which defaults to
qemu64) or explicitly requesting "-cpu qemu64".
>From my discussion with Cole it appears the use cases
where this may happen fall outside of routine/expected
usage and would need to be explicitly requested by the
user. However I wanted to call this out here in the
event we're overlooking something.
Yeah, libvirt basically never runs qemu without -M option and the only way to
get -cpu qemu64 is to explicitly ask for it in guest XML. There is a scenario
when libvirt creates -cpu option for qemu even though no cpu requirements were
specified in guest XML but it only happens for 32b guests on 64b hosts and
qemu32 CPU model is used in that case, which should be OK since the problem is
only about qemu64. And IIUC we don't want users to be able to specify the new
cpu64-rhel[56] models directly in guest XML so there's nothing to be done on
libvirt side.
Jirka