guest kernel panic on continious high usage

[blackmamba]

Host machine runs Debian Jessie 64 bit and Guest machine the same.

from time to time I am experiencing a kernel panic on the guest, making the virtual machine unresponsive. A soft reset from VirtualBox GUI will not work for the vm in question, the process has to be killed from console entirely and started again. The other running VMs are not affected when this even occurs.

I can't find relevant info in the vbox.log files on the host so I am attaching a print screen with the call trace that is shown on the guest console.

[blackmamba]

screenshot of the guest console with kernel panic

[Socratis]

Replying to blackmamba:

from time to time

Any patterns? You also mentioned "continuous high usage". What does that mean? CPU? I/O? Network?

I can't find relevant info in the vbox.log files

Unless you are a real expert in the analysis of the "VBox.log" files, please attach one that shows/contains the crash. Zipped please. The log files can tell a lot more than you think they are. Just make sure that you shutdown the VM before you do. Even if you have to shut it down by force.

PS. For future reference, print screens are usually not your best option. Why? They're not text => not searchable...

[blackmamba]

Replying to socratis:

Replying to blackmamba:

from time to time

Any patterns? You also mentioned "continuous high usage". What does that mean? CPU? I/O? Network?

Say every 15 days (+/- 3 days), as for the usage it is mostly RAM and I/O (Host has SSD only).

I can't find relevant info in the vbox.log files

Unless you are a real expert in the analysis of the "VBox.log" files, please attach one that shows/contains the crash. Zipped please. The log files can tell a lot more than you think they are. Just make sure that you shutdown the VM before you do. Even if you have to shut it down by force.

PS. For future reference, print screens are usually not your best option. Why? They're not text => not searchable...

I agree, I know it sucks. I made a print screen because I only saw the error there (there was nothing in the bottom of the log file that would indicate the fatal error was logged) and I couldn't scroll-up the vm console to copy/paste the text.

Right now the vm is restarted and contains VBox.log, VBox.log.1 VBox.log.2 and VBox.log.3 but I am not sure which contains / should contain the crash. Should I attach everything existent now or should I better clean up the log folder, wait for the crash to occur again and send after that?

[Socratis]

VBox.log is the newest, VBox.log.1 for the previous VM run, VBox.log.2 for the run before that, etc.

You shouldn't need to clean up the Logs directory, but if you only run the VM once since the crash, then it should be the VBox.log.1, since VBox.log is your current run. You could check out the last modification date/time as well.

Of course your best option, taking out the guesswork, would be to wait for the VM to crash and then know for sure it was the VBox.log. Before restarting the VM.

there was nothing in the bottom of the log file that would indicate the fatal error was logged

The log file is not your guest's dmesg. It's a log of the inner working of the VM. It will not contain your guests kernel panic, but clues that may (or may not) have led to the kernel panic.

[blackmamba]

Log that should contain the crash of the vm

[blackmamba]

Attached the log as requested. Hopefully it will contain relevant information related to the crash. Please let me know if other information is needed.

[Socratis]

From the log:

VirtualBox VM 4.3.36_Debian r105129 linux.amd64 (Jan 26 2016 10:28:06) release log

You're using a way too old, forked version of VirtualBox. The current release is 5.1.12 and you can download the official (non-forked) version from https://www.virtualbox.org/wiki/Downloads

[blackmamba]

I will upgrade the infrastructure. I thought that this version being shipped in the default repo is somehow more stable or something. Anyway, there's nothing else in the log file that could have caused the kernel panic? Or is sure it's old version's fault.

[Socratis]

Replying to blackmamba:

Anyway, there's nothing else in the log file that could have caused the kernel panic? Or is sure it's old version's fault.

I stopped looking after the first line. If that doesn't get fixed, all bets are off.

[Frank Mehnert]

VBox 4.3.36 is no longer supported. Please reopen if you can reproduce the same problem with VBox 5.1.14. In that case please provide a new VBox.log file.