[Solved] VM Ignoring the CPU count, only one core available on a Xeon

[rand(9,9999)]

Hello,

This issue has got me stuck for a while.

The host is a Debian9/64
Intel Xeon E3-1225 V2 (OVH rental server)
vbox 5.2.0r118431
Virtualization enabled (# rdmsr 0x3A -> 5)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts

The guest is Debian9/64

This is what I'm doing :

Code: Select all

 # vboxmanage modifyvm "xxxxxxxxxxxxxxxxxxx" --cpus 2

The command shows no errors. And the vbox file seems to have accepted the two CPUs

And yet, cat /proc/cpuinfo in the guest show only 1 cpu/1 core.

Code: Select all

# cat /proc/cpuinfo 
───────┬────────────────────────────────────────────────────────────────────────────────────────
       │ File: /proc/cpuinfo
───────┼────────────────────────────────────────────────────────────────────────────────────────
   1   │ processor      : 0
   2   │ vendor_id      : GenuineIntel
   3   │ cpu family     : 6
   4   │ model          : 58
   5   │ model name     : Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz
   6   │ stepping       : 9
   7   │ microcode      : 0x19
   8   │ cpu MHz                : 3199.998
   9   │ cache size     : 8192 KB
  10   │ physical id    : 0
  11   │ siblings       : 1
  12   │ core id                : 0
  13   │ cpu cores      : 1
  14   │ apicid         : 0
  15   │ initial apicid : 0
  16   │ fpu            : yes
  17   │ fpu_exception  : yes
  18   │ cpuid level    : 13
  19   │ wp             : yes
  20   │ flags          : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx rdrand hypervisor lahf_lm kaiser
  21   │ bugs           : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
  22   │ bogomips       : 6399.99
  23   │ clflush size   : 64
  24   │ cache_alignment        : 64
  25   │ address sizes  : 36 bits physical, 48 bits virtual
  26   │ power management:
  27   │ 
───────┴─────

Attached in the .vbox

I've done this on multiple other servers, and never has this issue.
Has anyone any idea of what could be going on here ?
Thanks very much .

[mpack]

Please provide a VM log file. With the VM fully shut down, right click it in the GUI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

I know nothing about Debian 9, but on some previous Windows versions you had to replace the kernel (or rather the HAL element of it) from single CPU to a multi-CPU version, assuming the OS was originally installed with the former.

[rand(9,9999)]

I'm sorry but it's a server so it has no GUI. How would I extract the requested file in CLI please ?

Code: Select all

VBoxManage debugvm <uuid|vmname> log [[--release] | [--debug]] [group-settings...]

is all I've found from vboxmanage | grep log

I can confirm that the host's kernel is vanilla and is able to use all cores. As far as I can remember, GNU/Linux distros have always been multi-cpu.

I have similar setups on multiple different servers (Debian 9 on Xeon and virtualbox 5 5.1 5.2) without issues assigning or using multiple cores.
This is the first time I encounter this problem.

[rand(9,9999)]

Sorry, found the log (It was stored in a non-standard folder).
I can't afford to shutdown the VM right now, so here (attached) is the last log file, with the VM running.

[mpack]

You are currently running 5.2.0, which is almost exactly 1 year old and by definition is the buggiest member of the 5.2.x branch.

00:00:00.448419 PcBios: [SMP] BIOS with 2 CPUs

As far as I can tell, the guest OS already has access to two cores. So, this is going to be a Debian configuration matter somehow, but as mentioned I'm not a Debian user so I can't advise on where to look inside Debian. Presumably you did a full reboot of Debian since changing the vCPU count.

[rand(9,9999)]

Thanks for your answer.

I will try running the VM on a more recent version of virtualbox and see if that helps.

[rand(9,9999)]

There's been progress.

After a reboot of the VM, I found this is dmesg :

Code: Select all

[    0.000000] kvm-clock: cpu 0, msr 1:9fff1001, primary cpu clock
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_node_ids:1
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=1.
[    0.370598] APIC: NR_CPUS/possible_cpus limit of 1 reached. Processor 1/0x1 ignored.
[    0.370599] ACPI: Unable to map lapic to logical cpu number
[    0.370809] APIC: NR_CPUS/possible_cpus limit of 1 reached. Processor 2/0x2 ignored.
[    0.370809] ACPI: Unable to map lapic to logical cpu number
[    0.371019] APIC: NR_CPUS/possible_cpus limit of 1 reached. Processor 3/0x3 ignored.
[    0.371020] ACPI: Unable to map lapic to logical cpu number
[    0.639346] ledtrig-cpu: registered to indicate activity on CPUs

Interesting part being (I guess)

Code: Select all

ACPI: Unable to map lapic to logical cpu number

and

Code: Select all

APIC: NR_CPUS/possible_cpus limit of 1 reached. Processor 3/0x3 ignored.

Code: Select all

RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=1.

the issue seems to lie in the VM as suggested by mpack.
I'm investigating.

[andyp73]

Your log file from back in October seems to show the IOAPIC is disabled. IIRC the IOAPIC support has to be enabled for SMP i..e more that 1 CPU.

-Andy.

[mpack]

There's a spot in the log where that appears to get overridden by the VM. Still, worth a test.

00:00:00.448419 PcBios: [SMP] BIOS with 2 CPUs
00:00:00.448458 PcBios: Using the 386+ BIOS image.
...
00:00:00.458511 CPUM: SetGuestCpuIdFeature: Enabled xAPIC

[rand(9,9999)]

And... the conclusion.

Upgrading virtualbox from 5.2.0r118431 to 5.2.26r128414 had no effect.
All requested cores appeared in the VM after toggling the following virtualbox options (with no changes done to the guest OS) :

Code: Select all

--x2apic off -> on
--biosapic apic -> x2apic
--ioapic off -> on 

[mpack]

Thanks for reporting back. Marking as solved.