Linux guest VM becomes "stuck" after a period of time.

[Presence]

Regarding the host, it actually does have two physical CPUs, each with 4 cores.

As far as paravirtualization, I changed it where you suggested. Virtualbox app settings->Acceleration->Paravirtualization was previously set to KVM (usual for linux) is now set to None.

Now when I run htop on the system, it believes it has only one CPU core...same with /proc/cpuinfo, even though two vCPUs are configured for the host. With KVM, it did see one/two/four based on the vCPU setting within the virtualbox configuration for that VM.

Just for clarification:

2 physical cpu's, 4 cores each, 8 cores total.
1 vCPU assigned to an Ubuntu 14.0.4 host.
2 vCPUs assigned to another Ubuntu 64 bit host (alienvault-sensor)
currently 2 vCPUs assigned to this VM we are debugging (alienvault)

Alienvault is a 64bit linux based on Ubuntu/Debian.

Here is the uname -a from the host:

Code: Select all

Linux alienvault 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

[Perryg]

Well that is interesting. It should in no way change the actual amount of processors available. You need to raise a ticket at bugtracker and provide logs and a detailed description of how to reproduce this.

[Presence]

Hmm, changed Paravirtualization back to KVM, with 2 CPUs still shows one. Weird.

The only modification outside of the UI I've made is "VBoxManage setextradata VM_NAME "VBoxInternal/MM/CanUseLargerHeap" 1" which should not have locked it to a single CPU right?

[Perryg]

Correct. I think you have a condition that the DEVs need to look at. On some processors and some host/guest configurations there is a bug that does not identify the processor properly and this causes all kinds of weird things to happen. To date there have only been a handful of these crop up and they have not been able to reproduce it reliably as far as I know and from the sounds of it you are one of the unlucky ones. That is why I have been saying you really need to raise a ticket. If anyone can help it will be the DEVs, and if they already know what to do you will get your fix sooner. Like I said they don't always tell me that an issue is fixed and even if they had I probably would not remember it since it is so rare.

[Presence]

Actually, I scrubbed through the config, and noticed that "Allow Hot CPU Plugging" was enabled, and apparently the other CPUs default to unplugged. So that was a red herring.

After turning that off, I'm back to 4 CPUs with Paravirtualization set to "None". I'll let you know if I have the CPU stuck conditions...I tried it with Paravirtualization set to "KVM" and I received CPU "Stuck" messages during the boot sequence.

[Presence]

So the system was "stable" most of the night, but basically imploded this morning. The system console works rarely for input, but mostly dumps errors, including the dreaded CPU#0 stuck for 22m! along with stack faults.

Here is the VBOX log...

[Perryg]

You can keep posting here if you like but the only way this gets fixed is for you to raise a ticket. I said this issue usually produces weird things to happen and so far I see nothing to the contrary.

[Presence]

As it turns out, it wasn't a bug. As I stated a few items above, the reason why the CPUs weren't properly showing up was due to the Virtualbox configuration having "Allow CPU Hotplugging" and the CPUs are not plugged by default. The fact that the system did not see the CPUs was due to this. I've turned the setting off.

[Perryg]

You said you turned that off and everything was A-OK, then you posted that it imploded this morning. Given that statement I can only deduce that it crashed again after the change. Anyway I have done all I can. Good luck.

[Presence]

What you have stated is true. For the time being I'm throwing only one processor at it. I will open a bug and post the pertinent information to see if anything falls out. Thanks for your time, skill, and effort. You have been extremely helpful.