vbox causes kernel to hang

[semsen]

I'm running virtualbox on RHEL7, since a kernelupdate, about 2 months ago, It doesn't work anymore. I don't know it exact, becaus we didn't use it for a time.
It started with an errormsg in vagrant, so I updated vagrant, then vagrant said it Needs a newer virtualbox. SO I updated everything and installationg went through like described in the docs. But when I start a vbox Image (also an empty one) the kernel or some (vbox)moduole eats up a whole CPU and the box doesn't came up.
It writes this line about 20000 times in a few seconds.
kernel: AssertLogRel /home/vbox/vbox-5.2.16/src/VBox/VMM/VMMAll/PGMAllPool.cpp(2204) int pgmPoolCacheFreeOne(PPGMPOOL, uint16_t): iLoop < 8192

THen nothing happens, it isn't possible to stop or kill this box, since the kernel is very busy anything else doesn't work normal, it's not possible to reboot/shutdown the os, I have to reset ist.

I have
VirtualBox-5.2-5.2.16_123759_el7-1.x86_64
kernel-3.10.0-862.9.1.el7.x86_64

Please help!

[andyp73]

Vagrant is a program that relies on VirtualBox but modifies its configuration files in unknown ways to us. It is not supported on these VirtualBox user forums, they have their own Vagrant support channels.

If you are having this problem with a standalone version of VirtualBox, i.e. you will have to clean your system and your VirtualBox configuration from them, then we can continue this discussion.

-Andy.

[socratis]

Having said that, completely remove all VirtualBox traces (except your VMs of course). Then install the official version from the Downloads section of VirtualBox (https://www.virtualbox.org/wiki/Downloads).

[semsen]

Hello,

1. I used only the official downloads (before some 5.0) and now the above mentioned 5.2. I've also tried the latest 5.1 I found.
2. I do have the problem without vagrant. I create a new/empty vm and tried to start from a (different) rescue image(s), but ist always the same.

sem

[semsen]

Today, I updated to VirtualBox-5.2-5.2.18_124319_el7-1.x86_64 and also to the newest kernel kernel-3.10.0-862.11.6.el7.x86_64, but still the same result.
kernel eats up one CPU, this message on console

Message from syslogd@myserver at Aug 20 09:22:47 ...
 kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [EMT:18508]

And this message n x 10k times in /var/log/Messages

Aug 20 09:22:51 myserver kernel: AssertLogRel /home/vbox/vbox-5.2.18/src/VBox/VMM/VMMAll/PGMAllPool.cpp(2204) int pgmPoolCacheFreeOne(PPGMPOOL, uint16_t): iLoop < 8192

Am I really the only one who has this problem?

And how do I "completely remove all VirtualBox traces"?

Regards Matthias

[socratis]

And how do I "completely remove all VirtualBox traces"?

Shouldn't that be a question for RHEL? I don't quite remember off the top of my head if RHEL uses 'yum' or 'dnf', but it's one of these two. They have I believe 'man' pages that you can look for help...

[lucasrangit]

I am having the same kernel error when trying to boot an Ubuntu 16.04 64-bit guest with VirtualBox 5.2.22 (with extpack) on an ESXi 6.7.0 Ubuntu 18.04 64-bit VM with open-vm-tools 10.3.0 build 8931395 installed. Hardware virtualization is exposed to the Ubuntu 18.04 guest. I can reproduce this with or without vagrant 2.2.2.

AssertLogRel /home/vbox/vbox-5.2.22/src/VBox/VMM/VMMAll/PGMAllPool.cpp(2204) int pgmPoolCacheFreeOne(PPGMPOOL, uint16_t): iLoop < 8192

The error spams the dmesg log. I have tried various things to get around this but nothing has helped so far. Based on random sources on the Internet, this nesting of VirtualBox on ESXi does work if I expose hardware assisted virtualization to the ESXi guest.

The same software combination works when not nesting VirtualBox inside an ESXi guest. In other words, running the exact same software combination on a physical machine works. The issue is clearly with the use of ESXi as the hypervisor but it's strange that some are/were able to get this working before.

Any ideas what could be wrong/different?