I found the following idea via the Rosetta@home message board, originally posted by @computezrmle at the Cosmology@home message board:
http://www.cosmologyathome.org/forum_thread.php?id=7769&postid=22921

On Dec 5 2021 computezrmle wrote:

Volunteers frequently affected by the postponed issue may try a different vboxwrapper.

BOINC's wiki pages mention communication problems between vboxwrapper and VirtualBox 6.x, especially on Windows.
They offer premade executables that may solve the problems:
https://boinc.berkeley.edu/trac/wiki/VboxApps#Premadevboxwrapperexecutables

It would be the job of the project developers to test those vboxwrappers and distribute them to the clients.
As long as this is not done volunteers could use the following steps as a workaround:

1. Download an alternative vboxwrapper from the page mentioned above (or use one you got from another project, e.g. LHC@home)
2. Start the BOINC client but suspend computing
3. Change to the project directory, e.g. projects/www.cosmologyathome.org, and replace the vboxwrapper there with the test version; the filename must be the name of the old vboxwrapper
4. Resume computing -> check the logfiles of tasks started after the patch


Each restart of the BOINC client will replace the patch with the original vboxwrapper from the project server.
This can be avoided setting <dont_check_file_sizes>1</dont_check_file_sizes> in cc_config.xml, but then all other automatic updates will also not work.

I haven't tried this myself yet.

I am running QuChem on Linux, therefore am not observing this here. But I got the same occasionally at Cosmology@home with the "camb_boinc2docker" application, and very frequently at Rosetta@home with the "rosetta python projects" application. (I've got Vbox 6.1.28, that's apparently a factor for the frequency of such events.)

I suspect that vboxwrapper simply doesn't cope with the large latencies which a Vbox VM can sometimes exhibit. IOW my guess is that someone set a timeout too small somewhere.

I am currently running "rosetta python projects" (merely 16 or fewer tasks at one on a computer with plenty of cores and 256 GB RAM) and am restarting the boinc client twice a day. Otherwise the client would run out of work eventually, since it does not request new work as long as there is one or more "postponed" task in the buffer. :-(

curious issue...

So burned a bunch of CPU time for a dead task. Nice. [heavy sarcasm]

Yes, I know. That is a very common situation.

I asked some time ago whether they could not reduce the number of work units before they declare it an "invalid".
But apparently they need that many results to ensure that it is in fact invalid.

I still expect that they could cut it down to maybe five (I think the "aborted" does not count).
After that, I have never seen one that turns our "valid". But I don't see the overall statistics either. The project admin does.

I have Einstein on another PC, a recent laptop with an AMD CPU with graphic capabilities . Another, my fastest AMD PC, runs WCG but also a Linux Virtual Machine running both Einstein and QuChem on a SuSE Tumbleweed Linux, which is a Development version and has a 5.15.8 kernel. It is frequently updated and I have to reboot it. On the Intel PC from which I am writing I run QuChem, Rosetta@home and, alternating, LHC@home. Another older laptop runs QuChem on a SuSE Leap 15.0. I am trying to distribute my BOINC projects on 4 PCs plus one Virtual Machine.All this hardware costs me about 50 euros/month in electricity.
Tullio

I have 12 GB RAM on an Intel i5 CPU 9400F running Windows 11 home edition and I am running two tasks at a time.The same PC can run two rosetta python tasks at the same time which need much more RAM. VBox uses 6344 MB.
Tullio

I am using VirtualBox.6.1.30 on this project, on Rosetta python and LHC@home without any problem.
Tullio

What percentage of RAM do you allow BOINC to use (set in your preferences) ?

My RAC is now 2955 yet I am out of the credits list. My last position was 40.
Tullio

Neither LHC@home nor rosetta python.which requests 6144 MB of RAM, ever signal an "unmanageable VM job". Only QuChem does and I kill and restart BOINC.
Tullio

If you don't listen to what I say, you are on your own.

Well being that doesn't work..i guess i'll roll back to 5.
Nothing to lose.

If you don't listen to what I say, you are on your own.

You can usually solve it by going back to VirtualBox 5.2.44, at least on most projects.
https://www.virtualbox.org/wiki/Download_Old_Builds_5_2

You will still get a lot of invalids, but that is just the nature of the scientific work and not a VBox problem.