All my wus stop at 88% with the message "Posponed: VM Hypervisor failed....."
I'm using Win 10 1089 and Virtual Box 5.1.10

Only 2 wus continue to crunch, but at the end, error 197 like this thread

Please, fix the app

Same problem for me.
I`m using VirtualBox 5.2.28 and nearly all of my WUs stopped at around 80%.
After 30 minutes I had 40 VirtualMachines and my RAM ( 16GB ) began
to get crazy --> restart the PC with alt strg entf.
Maybe you can set a limit for WUs at the same time as other VM Projects do ?

All my wus stop at 88% with the message "Posponed: VM Hypervisor failed....."
I'm using Win 10 1089 and Virtual Box 5.1.10

VirtualBox 5.2.8 works fine for me.

VirtualBox 5.2.8 works fine for me.

I tried and it works!!

I'm seeing more and more of these along with ones that run for so long and abort. Task conditions have changed the past couple of days.

Hi,

I am trying to get nanoHub@Home working without the given error message "Posponed: VM Hypervisor failed.....".

Are you still using this Virtualbox 5.2.8 to execute their WU's?

Hi,

I am trying to get nanoHub@Home working without the given error message "Posponed: VM Hypervisor failed.....".

Are you still using this Virtualbox 5.2.8 to execute their WU's?

Hi,

I am trying to get nanoHub@Home working without the given error message "Posponed: VM Hypervisor failed.....".

Are you still using this Virtualbox 5.2.8 to execute their WU's?

If you are getting that message than your VB version is too new

How many work units are you trying to run? They take about 2 GB each.
You have 24 cores and 20 GB of memory.

45 WUs are stuck in the “Posponed: VM Hypervisor failed....." (33% of progress).

Windows Server 2016
Boinc client 7.16.7
Virtualbox 5.2.8
1 CPU 4 core (8 thread)
32GB RAM

45 WUs are stuck in the “Posponed: VM Hypervisor failed....." (33% of progress).

In BOINC settings, are you allowing enough memory to be used? I set it to 95%.

I haven't seen a problem with my Ryzen 2700, with 8/16 cores and 32 GB (Ubuntu 18.04 and VBox 5.2.42),
though I usually limit it to a maximum of 8 work units at a time.

In BOINC settings, are you allowing enough memory to be used? I set it to 95%.

The memory usage was 90%, so I'm going to increase it.

I usually limit it to a maximum of 8 work units at a time

How can I do it?

In BOINC settings, are you allowing enough memory to be used? I set it to 95%.

The memory usage was 90%, so I'm going to increase it.

I usually limit it to a maximum of 8 work units at a time

How can I do it?

Something like this except I'm not sure the <name> or <app_name> is correct:

<app_config>

<app>
<name>boinc2docker</name>
<max_concurrent>1</max_concurrent>
<fraction_done_exact/>
</app>
<app_version>
<app_name>boinc2docker</app_name>
<cmdline>-t4</cmdline>
</app_version>

<report_results_immediately/>

</app_config>

The above would run 1 workunit at a time, the <max_concurrent> part, and then use 14 cpu cores for each task, the <cmdline> part.

You would place this file in C:\program data\Boinc\projects\(thenanohubfolder), to do that copy and paste it into Notepad, I don't know Linux so this is for Windows, and save the file as app_config.xml in the folder. Be sure Notepad does NOT append .txt on the end when it saves it, it has a habit of doing that, and then in the Boinc Manager go to Options, read config files. and Boinc should find it, check the Event Log under Tools to make sure and that it doesn't have an error other than 'app not found' if you do not have any nanhub workunits. The change will apply when you get new tasks from the Server NOT to any existing tasks.

I usually limit it to a maximum of 8 work units at a time

How can I do it?

I use a simple version:

<app_config>
  <app>
  <name>boinc2docker</name>
  <max_concurrent>8</max_concurrent>
  </app>
</app_config>

It runs a maximum of 8 works units, with one CPU core per work unit.
You can add the other items as mikey suggests if you wish.

This happens to me from time to time. It seams to always happen when I am doing a number of concurrent things on the computer, and not limited boinc to take into account my activities, AND disk usage is at capacity from the nanohub tasks in progress. Bottom line, the message makes sense, the VM did not start the next task within the allotted time because too much was going on - on the computer.

The fix is very simple. exit boinc, and then restart boinc. Since the tasks in execution have the disk drive at capacity (temporarily) I prefer to suspend all tasks, underway (started) and not started before exiting boinc. That way when you restart boinc, it starts without having any jobs in que. I start the task manager, and release tasks as disk capacity is available. It usually only takes a 1 to 2 minutes.

Finally, I set my overall configuration to keep it under 75% CPU capacity, as I have the system set up to automatically overdrive. So even with 74% capacity, the overall CPU capacity on the computer is often in the 95+% range. I limit the number of tasks running by using

Options
Computer Preferences
Computing
Usage limits: x% of CPU's.

Currently, I had this set at 60% and I still got this message. Checking disk usage was pegged at 100%. Meaning the current batch of tasks from nanohub were slaming my disk drive.

No big deal. Shut down boinc and restart it.

---

Currently, I had this set at 60% and I still got this message. Checking disk usage was pegged at 100%. Meaning the current batch of tasks from nanohub were slaming my disk drive..

Yes, nanoHUB does hammer the disk drive. I posted on it a long time ago. The write rate is high, but the work units are short. I don't know if it will damage the drive or not. But I use SSDs, which are fast enough to avoid this problem, but may need to be protected. In Linux, I increase the size of the built-in write buffer to around 4 GB in size and an hour write-delay. In Windows, I use the Samsung Rapid Mode cache (included in their Magician utility), or even better PrimoCache, which allows for a bigger write buffer (similar to the Linux values). I think the Crucial SSDs have a cache included in their utility too.