I am exerience the same problem as some of the other members.

"Rosetta@home | Message from server: VirtualBox jobs require hardware acceleration support. Your processor does not support the required instruction set."

VirtualBox is installed (version 6.1.12). Virtualization is enabled on BIOS and I can conifrm that is enabled on Win10 Task Manager too.
PC specs: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=5945561

Any ideas what is going wrong ?

It could mean that the CPU of your computer doesn't support virtualization, or you have it turned off in the BIOS settings.

You could mention what model of computer you are running, so someone can tell you how to reach the BIOS settings,

CPU Model: AMD Ryzen 5 3400G with Radeon Vega Graphics
MOTHERBOARD: ASRock A320M_HDV (AM4)

Virtualization is enabled on BIOS, I can confirm that. Check link

https://drive.google.com/file/d/1A1MjBVI291CL8Y5iTg2fzj-pDl-Z9Olc/view?usp=sharing

Hi,

I am also now getting this message in the Event Log for Rosetta: "Message from server: VirtualBox jobs require hardware acceleration support. Your processor does not support the required instruction set." This apparently started in the last couple of days, maybe even today.

I have been running R@H for over 1.5 years, usually 24 hrs a day, with no problems, VirtualBox or otherwise. Could something have changed very recently with R@H to cause this? Does anyone have any idea (besides not have VB) what could suddenly cause this?

Thanks.

Doug

Did you go back into BIOS and tell it to allow virtualization?
When you update everything goes back to default.

I am sorry, if it has been asked before, but here I found the only mention of "VirtualBox"..
I am running Boinc (now latest version 7.16.20, but it does not matter) Standalone on Windows 10.
Since some days I get the message:
"Rosetta@home: Notice from server
VirtualBox is not installed"
All my remaining Rosetta tasks finished and uploaded. However, I am not able to download new tasks. Response in the message log ist always:
"Notice from server: VirtualBox is not installed. Project requested delay..."

Is this a new technical requirement of Rosetta (to use the Virtual Box version) or is there any other change or problem in the infrastructure?

Thanks, Edgar

Is this a new technical requirement of Rosetta (to use the Virtual Box version) or is there any other change or problem in the infrastructure?

We don't know whether it's just a case of all the last batch of Rosetta 4.20 work being done, and we're now waiting on more to be released, or if there is more but it's a server issue stopping it from being sent out.

---

Grant
Darwin NT

Thank you for the response!
I just got a new task 16min ago and the "VirtualBox" message disappeared.
So message was a little bit misleading and all seems back to normal now.

Thank you for the response!
I just got a new task 16min ago and the "VirtualBox" message disappeared.
So message was a little bit misleading and all seems back to normal now.

VirtualBox is necessary for the Rosetta Python tasks but not the standard Rosetta 4.20 tasks.

---

I wish they'd use KVM/QEMU instead of Virtualbox for Linux. It's the much more efficient method of virtualization on Linux that doesn't require installing external DKMS modules since it's supported directly by the Linux kernel. That said, I don't see why we're even using virtualization when a sandboxed namespace does the job just as well. Anyway, call me when there's interest in seeking open source contributors to transition from Python to Rust.

I wish they'd use KVM/QEMU instead of Virtualbox for Linux.

I am sure it would work better, since it can't work worse. It is getting practically impossible to run the pythons. The first problem is "Vm job unmanageable" suspensions, which occur on all of my machines no matter what steps I take (mainly limiting cores) to prevent it. You need to either wait a long time, or reboot to fix it.

But now the problem is that about half the pythons won't run at all. They get stuck at less than 1% CPU utilization, and I have to abort them.
I am moving away from interventionist projects on my machines, and the pythons are the next ones to go.

---

I do constantly get the issue of having to abort Python units at 99.996% completion, even on my Ryzen 5700g desktop with 64 GB RAM, which seems to be good enough for running 8 python units simultaneously on each physical core. Have tried to limit the number of Python work units to 4 just in case so I can run 12 normal tasks in addition to that, but apparently using an app_config.xml to define max-concurrent work units causes BOINC to repeatedly ask for 12 work units every 30 seconds, so had to abort that attempt.

I do constantly get the issue of having to abort Python units at 99.996% completion, even on my Ryzen 5700g desktop with 64 GB RAM, which seems to be good enough for running 8 python units simultaneously on each physical core.

It isn't a problem of memory, and you don't need to go to 99%.
If in the first five minutes they are less than 1% CPU utilization, you can abort them. I use BoincTasks to monitor that.

---

Thanks for the reply.

I have not done that, nor have I ever had to do it in the past. I'm running Win10 with all the latest updates. In Task Manager, on the second (Performance) tab, at the bottom with all the CPU info, it says "Virtualization: Enabled". Does that address what you are asking about? If not, do you know where in Windows I can find the info you are asking for?

Thanks.

Doug




[/img]

Deleted.

---

Maybe try what I do for LHC ATLAS which is a very picky project and has a hard time running on single cores and such.

I have in the past wrote an app_config that forced it to run on just 4 cores and 1 task at a time.
Now I can set that in the web preferences of this project.

So maybe you can try that for Python. But being it falls under "Rosetta" it will apply to all tasks from RAH.
Another stupid thing from this project and you can not set this in the web preferences here either.

I tried to get RPP to run multithreaded with this app config :-

<app_config>
<app>
<name>rosetta_python_projects</name>
</app>
<app_version>
<app_name>rosetta_python_projects</app_name>
<plan_class>vbox64</plan_class>
<avg_ncpus>5</avg_ncpus>
</app_version>
</app_config>

but even though it shows on boinc manager as ` Running(5cpus) `
each RPP task runs 25 threads total, so unless the data they are crunching is very linier.
it don't actualy do it when looking at cpu graphs, any ideas as to what else could be in an app config to force it to use multi thread
or could it be hard coded in the VM not to??
or am I wasting my time trying :(

I changed it around from the one I use at cosmology@home

<app_config>
<app>
<name>camb_boinc2docker</name>
<max_concurrent>2</max_concurrent>
</app>
<app_version>
<app_name>camb_boinc2docker</app_name>
<plan_class>vbox64_mt</plan_class>
<avg_ncpus>7</avg_ncpus>
</app_version>
</app_config>

I tried to get RPP to run multithreaded with this app config :-

[snip]

It's rare that you can make a program run multithreaded unless it's written to know how to do so.

Changing the app config file isn't enough if that's all you do.

<name>rosetta_python_projects</name>

That as far as I know is an internal naming of the type of task.
As far as I know all tasks fall under "rosetta"

I have not found a way to isloate python tasks.

I decided to have a go at it again, give the computer a full reboot [not out the door]
even if it is / was a case of knowing just enuf to make a big mess of it
I did get a some xml errors noted in event log,
I just keep bashing away at it till something happens :)
well
it did some thing . . . . .
I know it sounds like something from a Frankenstine video
because one of the `vboxheadless.exe` instances in win7 resource monitor is using 22% of cpu on 16 core cpu, [one cpu is only 6.25%]
could someone be mad enuf to try it @home and see what happens
only new tasks downloaded AFTER the app-config is in place will get the new settings config

Using an app_config to set the max-concurrent value will cause your system to endlessly request work until you've fully depleted the server of work units. I don't recommend doing so until this issue is fixed: https://github.com/BOINC/boinc/issues/4322

Using an app_config to set the max-concurrent value will cause your system to endlessly request work until you've fully depleted the server of work units. I don't recommend doing so until this issue is fixed: https://github.com/BOINC/boinc/issues/4322

I have not run cosmo@home for several months , endless workfetch was stopped by them having a limit serverside on the number of workunits anyone was allowed to have
I have been reading the threads here on R@H with interest about that work fetch problem

I have been reading the threads here on R@H with interest about that work fetch problem

I first ran into it several years ago on WCG. More recently, we had a discussion of it on LHC.
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5720&postid=45308#45308

Also:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5726&postid=45384#45384

It has been reported to BOINC.
https://github.com/BOINC/boinc/issues/4322

---