F@H in parallel with VirtualBox

[diskerror]

TL;DR

VirtualBox VMs interact with Folding@Home causing unpredictable behavior within the VM and long pauses waiting for the Folding@Home controller to receive an update. This bug is produced on a Hackintosh running MacOS 13.2.1.

It is suggested that the user fully pause Folding@Home before starting a VirtualBox virtual machine instance.

Environment

Folding@Home 7.6.21 (FAH) VirtualBox for MacOS version 7.0.6 r155176 (Qt5.15.2) (VB) MacOS Ventura 13.2.1 (MacOS)

• OpenCore 0.8.7 (OC)
• 8-Core Intel Core i7, 32G RAM (looks like an iMac20,2)

Current Behavior

Two problems seen, possibly related:

• When a VirtualBox virtual machine instance (VM) is running in parallel to FAH, the FAH controller will take a very long time to update, if at all.
• A VB managed VM exhibits spurious subtle unpredictable behavior, ultimately resulting in a kernel panic within the VM. Upon restarting the VM cannot connect to the VM via ssh. Logging in is possible only through the virtual console.

Possible Solution

Fully pause the FAH daemon.

Steps To Reproduce

1. Build working Hackintosh. (Should be tested on standard Apple/Intel hardware first.)
   • MSI MEG Z490i Unify mini-ITX
   • Intel i7-10700K, 8 core, 3.8GHz
   • Two DDR-2933 16-gig RAM modules at 2933MHz
   • RX-480 Saphire
   • Nothing is overclocked.
2. Run FAH with a 4-core slot at 100%.
3. Create and run a VB VM with 4 cores, 4 gig RAM, bridged ethernet with Intel interface
4. Install Debian 10 on the VM with LAMP software, in this case:
   • L = Debian Linux
   • A = Nginx (not Apache)
   • M = MariaDB (not MySQL)
   • P = PHP 7.4
5. Within the VM, execute a long running PHP process that uses the database engine.

Context

FAH and VB are both running on my desktop Hackintosh. Overnight, my desktop system is manually changed using the FAH controller to reconfigure the slots to run with 16 cores. While working during the day slots would be changed to 4 cores for the desktop system to be more responsive and have less fan noise.

I am debugging a PHP/MariaDB/Nginx web site, SuiteCRM 7.10, running on a Debian 10 instance, assigned 4 cores and 4G RAM by VB. This is the only thing running on the VB Debian instance. Often a web page from the SuiteCRM instance would appear blank. While using PHPStorm IDE and XDebug on the VM using step-debugging the process would just disappear. No message. No indicator. And the system often would be frozen.

Possibly relevant segment of syslog file included.

syslog(segment).txt

[jcoffland]

Thank you for the thorough report. However, I don't see any reasonable change to the client software. We cannot add lots of exceptions for possible interactions with 3rd party software. You can take care of this at the system level with scripting.

[diskerror]

I understand and that's perfectly reasonable. I posted this for anyone else who might have dealt with this interaction. I spent most of a week dealing it. I would never have considered a competition for hardware resources to be an issue for non-realtime processes on modern OSs. Hopefully my system wasn't also returning corrupted FAH results.