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
Troubleshooting OSX panic while running VirtualBox
-
- Site Moderator
- Posts: 20945
- 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
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.
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.
Re: Troubleshooting OSX panic while running VirtualBox
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
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
-
- Volunteer
- Posts: 708
- 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
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?
Which version of VirtualBox do you have installed?
Re: Troubleshooting OSX panic while running VirtualBox
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
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
-
- Volunteer
- Posts: 5677
- 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
Well, you didn't give us a chance.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.
See VBoxManage debugvm dumpvmcore in 8.43. VBoxManage debugvm.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?
Re: Troubleshooting OSX panic while running VirtualBox
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.
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 12 times
-
- Volunteer
- Posts: 5677
- 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
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.
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.