[libvirt] Unable to start Nehalem VM on Nehalem host
Hi list, I'm trying to debug a strange issue I have, and I'd appreciate some help. I've upgraded libvirt to 1.2.2, on Scientific Linux, with qemu-kvm-0.12.1.2-2.415.el6_5.3 Here’s my analysis so far: I figured out that libvirt uses HMP to get the list of models from qemu-kvm by running qemu-kvm -cpu ?model -nodefconfig. This returns the following: x86 Opteron_G5 AMD Opteron 63xx class CPU x86 Opteron_G4 AMD Opteron 62xx class CPU x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) x86 Haswell Intel Core Processor (Haswell) x86 SandyBridge Intel Xeon E312xx (Sandy Bridge) x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) x86 cpu64-rhel5 QEMU Virtual CPU version (cpu64-rhel5) x86 cpu64-rhel6 QEMU Virtual CPU version (cpu64-rhel6) x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz x86 athlon QEMU Virtual CPU version 0.12.1 x86 pentium3 x86 pentium2 x86 pentium x86 486 x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz x86 qemu32 QEMU Virtual CPU version 0.12.1 x86 kvm64 Common KVM processor x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor x86 qemu64 QEMU Virtual CPU version 0.12.1 The comment describing the function parsing this list states that the output is expected to be as follows: /* Format: * <arch> <model> * qemu-0.13 encloses some model names in []: * <arch> [<model>] */ static int virQEMUCapsParseX86Models(const char *output, virQEMUCapsPtr qemuCaps) { but this function doesn’t strip the rest of the line, so the models array becomes: Breakpoint 1, x86Decode (cpu=0x7fffd82a8460, data=0x7fffd8272d00, models=0x7fffd82b7440, nmodels=25, preferred=0x7fffd82a81f0 "Nehalem", flags=0) at cpu/cpu_x86.c:1487 1487 { (gdb) p models $1 = (const char **) 0x7fffd82b7440 (gdb) p *models $2 = 0x7fffd82ba240 "Opteron_G5 AMD Opteron 63xx class CPU", ' ' <repeats 22 times> (gdb) p *models@25 $3 = {0x7fffd82ba240 "Opteron_G5 AMD Opteron 63xx class CPU", ' ' <repeats 22 times>, 0x7fffd82c8c30 "Opteron_G4 AMD Opteron 62xx class CPU", ' ' <repeats 22 times>, 0x7fffd8169e00 "Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) ", 0x7fffd8169cb0 "Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) ", 0x7fffd8169b60 "Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)", ' ' <repeats 11 times>, 0x7fffd8169a10 "Haswell Intel Core Processor (Haswell)", ' ' <repeats 18 times>, 0x7fffd81697e0 "SandyBridge Intel Xeon E312xx (Sandy Bridge)", ' ' <repeats 16 times>, 0x7fffd8169690 "Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) ", 0x7fffd8169460 "Nehalem Intel Core i7 9xx (Nehalem Class Core i7) ", 0x7fffd81693f0 "Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) ", 0x7fffd8169310 "Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) ", 0x7fffd8169230 "cpu64-rhel5 QEMU Virtual CPU version (cpu64-rhel5) ", 0x7fffd8169150 "cpu64-rhel6 QEMU Virtual CPU version (cpu64-rhel6) ", 0x7fffd82ba2b0 "n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz ", 0x7fffd81690e0 "athlon QEMU Virtual CPU version 0.12.1", ' ' <repeats 17 times>, 0x7fffd8169000 "pentium3", ' ' <repeats 50 times>, 0x7fffd8168f90 "pentium2", ' ' <repeats 50 times>, 0x7fffd8168eb0 "pentium", ' ' <repeats 50 times>, 0x7fffd82a8760 "486", ' ' <repeats 50 times>, 0x7fffd8168e40 "coreduo Genuine Intel(R) CPU", ' ' <repeats 11 times>, "T2600 @ 2.16GHz ", 0x7fffd8168d60 "qemu32 QEMU Virtual CPU version 0.12.1", ' ' <repeats 17 times>, 0x7fffd82bb150 "kvm64 Common KVM processor", ' ' <repeats 28 times>, 0x7fffd8168cf0 "core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz ", 0x7fffd8168c10 "phenom AMD Phenom(tm) 9550 Quad-Core Processor ", 0x7fffd8168b30 "qemu64 QEMU Virtual CPU version 0.12.1", ' ' <repeats 17 times>} cpuModellsAllowed then does a strcmp between “Nehalem” and "Nehalem Intel Core i7 9xx (Nehalem Class Core i7)” which fails, and the vm fails to start with: 2014-03-10 14:56:16.917+0000: 8328: info : qemuDomainDefineXML:6231 : Creating domain '530df8bd-7b64-4553-b4f4-18922e1327bf' 2014-03-10 14:56:17.114+0000: 8329: warning : x86Decode:1515 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used 2014-03-10 14:56:17.114+0000: 8329: error : x86Decode:1571 : internal error: Cannot find suitable CPU model for given data Kind regards, Ruben Kerkhof
On Mon, Mar 10, 2014 at 15:58:01 +0100, Ruben Kerkhof wrote:
Hi list,
I'm trying to debug a strange issue I have, and I'd appreciate some help.
I've upgraded libvirt to 1.2.2, on Scientific Linux, with qemu-kvm-0.12.1.2-2.415.el6_5.3
cpuModellsAllowed then does a strcmp between “Nehalem” and "Nehalem Intel Core i7 9xx (Nehalem Class Core i7)” which fails, and the vm fails to start with: 2014-03-10 14:56:16.917+0000: 8328: info : qemuDomainDefineXML:6231 : Creating domain '530df8bd-7b64-4553-b4f4-18922e1327bf' 2014-03-10 14:56:17.114+0000: 8329: warning : x86Decode:1515 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used 2014-03-10 14:56:17.114+0000: 8329: error : x86Decode:1571 : internal error: Cannot find suitable CPU model for given data
Yeah, this is a result of using upstream libvirt with downstream qemu-kvm. The change that made qemu's list of supported CPU models more verbose was backported from upstream to qemu-kvm-0.12.1.2-* and thus downstream libvirt had to be fixed to correctly handle that. However, upstream QEMU made the output more verbose after libvirt switched to using QMP for checking supported CPU models. See [1] thread for a patch and a discussion which resulted in not applying the patch. [1] https://www.redhat.com/archives/libvir-list/2012-October/msg00251.html Jirka
Hi Jiri, On Mon, Mar 10, 2014 at 4:16 PM, Jiri Denemark <jdenemar@redhat.com> wrote:
Yeah, this is a result of using upstream libvirt with downstream qemu-kvm. The change that made qemu's list of supported CPU models more verbose was backported from upstream to qemu-kvm-0.12.1.2-* and thus downstream libvirt had to be fixed to correctly handle that. However, upstream QEMU made the output more verbose after libvirt switched to using QMP for checking supported CPU models. See [1] thread for a patch and a discussion which resulted in not applying the patch.
[1] https://www.redhat.com/archives/libvir-list/2012-October/msg00251.html
Great, thanks for the patch and the pointer to the discussion. I've applied it locally and my vms now start without problems.
Jirka
Kind regards, Ruben
participants (2)
-
Jiri Denemark -
Ruben Kerkhof