12:13 a.m.
Hi,
I'm not sure where the problem lies, hence the CC to both lists. Please copy me
on the reply.
I'm playing with OpenStack's devstack environment on an Ubuntu 14.04 host with a
Celeron 2961Y CPU. (libvirt detects it as a Nehalem with a bunch of extra
features.) Qemu gives version 2.2.0 (Debian 1:2.2+dfsg-5expubuntu9.7~cloud2).
If I don't specify a virtual CPU model, it appears to give me a "qemu64"
CPU,
and /proc/cpuinfo in the guest instance looks something like this:
processor 0
vendor_id GenuineIntel
cpu family 6
model 6
model name: QEMU Virtual CPU version 2.2.0
stepping: 3
microcode: 0x1
flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush
mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx cx16 x2apic popcnt
hypervisor lahf_lm abm vnmi ept
However, if I explicitly specify a custom CPU model of "qemu64" the instance
refuses to boot and I get a log saying:
libvirtError: unsupported configuration: guest and host CPU are not compatible:
Host CPU does not provide required features: svmlibvirtError: unsupported
configuration: guest and host CPU are not compatible: Host CPU does not provide
required features: svm
When this happens, some of the XML for the domain looks like this:
<os>
<type arch='x86_64'
machine='pc-i440fx-utopic'>hvm</type>
....
<cpu mode='custom' match='exact'>
<model fallback='allow'>qemu64</model>
<topology sockets='1' cores='1' threads='1'/>
</cpu>
Of course "svm" is an AMD flag and I'm running an Intel CPU. But why does
it
work when I just rely on the default virtual CPU? Is kvm_default_unset_features
handled differently when it's implicit vs explicit?
If I explicitly specify a custom CPU model of "kvm64" then it boots, but of
course I get a different virtual CPU from what I get if I don't specify anything.
Following some old suggestions I tried turning off nested kvm, deleting
/var/cache/libvirt/qemu/capabilities/*, and restarting libvirtd. Didn't help.
So...anyone got any ideas what's going on? Is there no way to explicitly
specify the model that you get by default?
Thanks,
Chris
4:45 a.m.
On Wed, May 25, 2016 at 11:13:24PM -0600, Chris Friesen wrote:
[...]
However, if I explicitly specify a custom CPU model of
"qemu64" the
instance refuses to boot and I get a log saying:
[Not a direct answer to the exact issue you're facing, but a related
issue that is being investigated presently...]
Currently there's a related (regression) in upstream libvirt 1.3.4:
The crux of the issue here is: the libvirt custom 'gate64' model is not
being translated into a CPU definition that QEMU can recognize
(which you can find from `qemu-system-x86 -cpu \?`).
See this bug (it has reproducer, and discussion):
https://bugzilla.redhat.com/show_bug.cgi?id=1339680 -- libvirt CPU
driver fails to translate a custom CPU model into something that
QEMU recognizes
The bug (regression) is bisected, by Jiri Denemark, to this commit:
v1.2.9-31-g445a09b "qemu: Don't compare CPU against host for TCG".
libvirtError: unsupported configuration: guest and host CPU are not
compatible: Host CPU does not provide required features: svmlibvirtError:
unsupported configuration: guest and host CPU are not compatible: Host CPU
does not provide required features: svm
When this happens, some of the XML for the domain looks like this:
<os>
<type arch='x86_64'
machine='pc-i440fx-utopic'>hvm</type>
....
<cpu mode='custom' match='exact'>
<model fallback='allow'>qemu64</model>
<topology sockets='1' cores='1' threads='1'/>
</cpu>
Of course "svm" is an AMD flag and I'm running an Intel CPU. But why does
it work when I just rely on the default virtual CPU? Is
kvm_default_unset_features handled differently when it's implicit vs
explicit?
If I explicitly specify a custom CPU model of "kvm64" then it boots, but of
course I get a different virtual CPU from what I get if I don't specify
anything.
Following some old suggestions I tried turning off nested kvm, deleting
/var/cache/libvirt/qemu/capabilities/*, and restarting libvirtd. Didn't
help.
So...anyone got any ideas what's going on? Is there no way to explicitly
specify the model that you get by default?
Thanks,
Chris
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
/kashyap
5:41 a.m.
On Wed, May 25, 2016 at 23:13:24 -0600, Chris Friesen wrote:
Hi,
If I don't specify a virtual CPU model, it appears to give me a "qemu64"
CPU,
and /proc/cpuinfo in the guest instance looks something like this:
processor 0
vendor_id GenuineIntel
cpu family 6
model 6
model name: QEMU Virtual CPU version 2.2.0
stepping: 3
microcode: 0x1
flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush
mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx cx16 x2apic popcnt
hypervisor lahf_lm abm vnmi ept
However, if I explicitly specify a custom CPU model of "qemu64" the instance
refuses to boot and I get a log saying:
libvirtError: unsupported configuration: guest and host CPU are not compatible:
Host CPU does not provide required features: svmlibvirtError: unsupported
configuration: guest and host CPU are not compatible: Host CPU does not provide
required features: svm
The qemu64 CPU model contains svm and thus libvirt will always consider
it incompatible with any Intel CPUs (which have vmx instead of svm). On
the other hand, QEMU by default ignores features that are missing in the
host CPU and has no problem using qemu64 CPU, the guest just won't see
some of the features defined in qemu64 model.
In your case, you should be able to use
<cpu mode'custom' match='exact'>
<model>qemu64</model>
<feature name='svm' policy='disable'/>
</cpu>
to get the same CPU model you'd get by default (if not, you may need to
also add <feature name='vmx' policy='require'/>).
Alternatively
<cpu mode'custom' match='exact'>
<model>qemu64</model>
<feature name='svm' policy='force'/>
</cpu>
should work too (and it would be better in case you use it on an AMD
host).
But why you even want to use qemu64 CPU in a domain XML explicitly? If
you're fine with that CPU, just let QEMU use a default one. If not, use
a CPU model that fits your host/needs better.
BTW, using qemu64 with TCG (i.e., domain type='qemu' as oppose to
type='kvm') is fine because libvirt won't check it against host CPU and
QEMU will emulate all features so you'd get even the features that host
CPU does not support.
Jirka
P.S. Kashyap is right, the issue he mentioned is not related at all to
your case.
9:08 a.m.
On 05/26/2016 04:41 AM, Jiri Denemark wrote:
The qemu64 CPU model contains svm and thus libvirt will always
consider
it incompatible with any Intel CPUs (which have vmx instead of svm). On
the other hand, QEMU by default ignores features that are missing in the
host CPU and has no problem using qemu64 CPU, the guest just won't see
some of the features defined in qemu64 model.
In your case, you should be able to use
<cpu mode'custom' match='exact'>
<model>qemu64</model>
<feature name='svm' policy='disable'/>
</cpu>
to get the same CPU model you'd get by default (if not, you may need to
also add <feature name='vmx' policy='require'/>).
Alternatively
<cpu mode'custom' match='exact'>
<model>qemu64</model>
<feature name='svm' policy='force'/>
</cpu>
should work too (and it would be better in case you use it on an AMD
host).
It's actually OpenStack that is setting up the XML, not me, so I'd have to
special-case the "qemu64" model and it'd get ugly. :)
The question remains, why is "qemu64" okay when used implicitly but not
explicitly? I would have expected them to behave the same.
But why you even want to use qemu64 CPU in a domain XML explicitly?
If
you're fine with that CPU, just let QEMU use a default one. If not, use
a CPU model that fits your host/needs better.
Working around another issue would be simpler/cleaner if I could just explicitly
set the model to qemu64.
Chris
3102
days inactive
3102
days old
3 comments
3 participants
participants (3)
-
Chris Friesen -
Jiri Denemark -
Kashyap Chamarthy