[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] inconsistent handling of "qemu64" CPU model



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]