Troubleshooting OSX panic while running VirtualBox

Discussions related to using VirtualBox on Mac OS X hosts.
Post Reply
plb0202
Posts: 4
Joined: 17. Feb 2022, 01:19

Troubleshooting OSX panic while running VirtualBox

Post by plb0202 »

Hi All

I am attempting to troubleshoot a kernel panic issue where OSX is panicking. Its not clear whether it is virtualbox related however as this is pretty much the only application running along side the VM's open at the time I am trying to tie down where this failure is appearing. Have had an open case with Apple for what seems like 12 months now and it has gotten to the point where they are indicating my only path forward is to move on to Monterey and then they will investigate further.

I am currently running the latest Big Sur patch level however this won't be investigated according to the support person I am dealing with at Apple.

My main questions are : Will VirtualBox happily run on Monterey and will I run into any issues during or post upgrade?

Any advice/help/experiences appreciated. Trying to avoid killing important environments work wise.

Cheers

Paul
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Troubleshooting OSX panic while running VirtualBox

Post by scottgus1 »

I personally may not know Mac enough to troubleshoot this, but a log from the VM might help.

Start the VM from full normal shutdown, not save-state. Run until you see the problem happen, then shut down the VM from within the VM's OS if possible. If not possible, close the Virtualbox window for the VM with the Power Off option set.

Right-click the VM in the main Virtualbox window's VM list, choose Show Log. Save the far left tab's log, zip it, and post the zip file, using the forum's Upload Attachment tab.
plb0202
Posts: 4
Joined: 17. Feb 2022, 01:19

Re: Troubleshooting OSX panic while running VirtualBox

Post by plb0202 »

Thanks for the reply @scottgus1

The issue is the host OS (an iMac) panicking when running virtual machines. An OS stack is produced when the iMac restarts indicating which CPU the panic occurred in as well as other info I assume only Apple can decode. I guess what I am after is whether or not there is anything in Virtual Box itself that I can see that may be triggering this OSX panic in the machine hosting the VM's.

I'm also wanting to know if upgrading to Monterey will present any problems for VirtualBox as the VM's are used heavily in my work.

Cheers

Paul
granada29
Volunteer
Posts: 690
Joined: 3. Mar 2015, 07:27
Primary OS: Mac OS X other
VBox Version: OSE other
Guest OSses: Linux, macOS, Windows

Re: Troubleshooting OSX panic while running VirtualBox

Post by granada29 »

There were kernel panic problems with VirtualBox 6.1.28 and earlier when running in Monterey. The current release, VirtualBox 6.1.32, does NOT cause the kernel panics as far as I am aware.

Which version of VirtualBox do you have installed?
plb0202
Posts: 4
Joined: 17. Feb 2022, 01:19

Re: Troubleshooting OSX panic while running VirtualBox

Post by plb0202 »

Hi,

Its been a while as I have been continuing the kernel panic fight with Apple. I am running version 6.1.32 r149290 of VB. The kernel panics continue. It seems when I get to 3 VM or above it gets worse. Over the past 2 days while attempting to build and patch a 3 node Oracle RAC cluster I experienced 7-8 panics. Apple is proving useless in telling me where the issue is coming from. One minute its hardware the next software.

Is there a way to trigger an OS dump (which I would have thought it would do by default) that will capture process state and stacks that could be of use in identifying the trigger point for the failures?

Any help/advice appreciated.

Cheers

PLB
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Troubleshooting OSX panic while running VirtualBox

Post by fth0 »

plb0202 wrote:An OS stack is produced when the iMac restarts indicating which CPU the panic occurred in as well as other info I assume only Apple can decode.
Well, you didn't give us a chance. ;)
plb0202 wrote:Is there a way to trigger an OS dump (which I would have thought it would do by default) that will capture process state and stacks that could be of use in identifying the trigger point for the failures?
See VBoxManage debugvm dumpvmcore in 8.43. VBoxManage debugvm.
plb0202
Posts: 4
Joined: 17. Feb 2022, 01:19

Re: Troubleshooting OSX panic while running VirtualBox

Post by plb0202 »

This morning after leaving a 3 node RAC cluster running over night, one of three VM's was found to be completely hung. It may or may not be related to kernel panics I am experiencing.

I attempted to collect a core from it using Vboxmanage debug however this never completed. I possibly should have sent an NMI to the machine however, a force quit was performed which resulted in OSX producing a bucket load of process state and stack information.

Uploading it here in case anyone has the ability to diagnose what may be occurring.

This may or may not be the forum and place for reporting a problem like this, requesting forgiveness in advance if it is not.
Attachments
oelc5n2_c2_hang-06-08-2022.stacks.gz
Vbox VM hang diagnostics
(204.01 KiB) Downloaded 7 times
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Troubleshooting OSX panic while running VirtualBox

Post by fth0 »

The stacks of the VirtualBox processes and threads only show to me what you seem to be describing:

The main thread recognized a mouse down event and while trying to close a window, it waits on a semaphore inside the VMMR3EmtRendevous() method. One of the helper threads also waits on a semaphore inside the VMMR3EmtRendevous() method and was called from DBGFR3CoreWrite(). This could mean that the core dump is blocked by something and itself is blocking the VM closing. But I didn't notice anything else indicating a previous cause.

To see what happened in the past, the next step would be to look at a (zipped) VBox.log file from the hanging VM. If you haven't started the VM 4 times since the hang, the rotating log file should be still available ...

If the problem happens again, you could create spindumps of one hanging and one non-hanging VMs in the Activity Monitor. A comparison might reveal something.
Post Reply