LHC@home

Yes I know this is an LHC forum, but I thought someone in here might be kind enough to shed light on what's wrong here. If you know what's up, I'll try to find a point of contact over there to pass it on.

They've just started using virtualbox, and it seems some machines run it fine and some go wrong. There are two forms of going wrong, some machines appear to run them correctly and send them back, but they don't validate. Others, like the example below, use no CPU time at all and sit there ticking over for a day.

https://boinc.bakerlab.org/rosetta/result.php?resultid=1463541284

It includes many of these lines:

Hypervisor System Log:
24:11:34.575288 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={85cd948e-a71f-4289-281e-0ca7ad48cd89} aComponent={MachineWrap} aText={The object functionality is limited}, preserve=false aResultDetail=0"

I have asked over in the main Boinc forum too, https://boinc.berkeley.edu/dev/forum_thread.php?id=14532

The Rosetta thread is here: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6893

I would test a setup with the most recent VirtualBox version (currently 6.1.30) together with the vboxwrapper used for CMS.

1. Set BOINC to no new tasks
2. Suspend all vbox task not yet started
3. Shut down BOINC
4. Upgrade VirtualBox
5. Reboot
6. Restart BOINC
7. Wait until all vbox task that were in progress before are done and reported
8. Overwrite the vboxwrapper in the projects folder with the version from CMS; keep the original name; don't restart BOINC (it would download the original file)
9. Start a vbox task and slowly increase the load by starting additional tasks until you are at full load


This is a test to check whether too much total load or the vboxwrapper causes the issues.
If it's the original vboxwrapper => contact the project admins and ask for a new app version that delivers the working vboxwrapper.

Thanks for your help.

I assume the CMS wrapper is the one called "vboxwrapper_26203_windows_x86_64.exe", and not "vboxwrapper_26198ab7_windows_x86_64.exe" which I think is Atlas?

I copied vboxwrapper_26203_windows_x86_64.exe across, although there was one already called that in the Rosetta folder, so does that mean they were already on the same version as you?

I attempted to start just one of their tasks, and the same is happening, no CPU usage at all.

When I aborted the task and sent it back, I find this stderr output on the server:
https://boinc.bakerlab.org/rosetta/result.php?resultid=1463612627

I don't understand why my other machine does them fine.

grcpool as User?
It would be better to let a task running from LHC@Home here, looking for a error here and search for this problem in rosetta@home.

I copied vboxwrapper_26203_windows_x86_64.exe across, although there was one already called that in the Rosetta folder, so does that mean they were already on the same version as you?

I can't answer this since I don't run Rosetta VMs.
Even if the source code and the filename are the same the may have been compiled using different compiler switches.


What makes me wonder are this lines from the logfile (they tell you something about the vdi file):
Capacity: 8192 MBytes
Size on disk: 7115 MBytes

7 GB is rather huge for this kind of usecase and it appears that the virtual disk has only 1 GB space left.
LHC@home usually allows up to 20 GB capacity.

grcpool as User?
It would be better to let a task running from LHC@Home here, looking for a error here and search for this problem in rosetta@home.

Why would an LHC task have the error?

I copied vboxwrapper_26203_windows_x86_64.exe across, although there was one already called that in the Rosetta folder, so does that mean they were already on the same version as you?

I can't answer this since I don't run Rosetta VMs.
Even if the source code and the filename are the same the may have been compiled using different compiler switches.


What makes me wonder are this lines from the logfile (they tell you something about the vdi file):
Capacity: 8192 MBytes
Size on disk: 7115 MBytes

7 GB is rather huge for this kind of usecase and it appears that the virtual disk has only 1 GB space left.
LHC@home usually allows up to 20 GB capacity.

Good point, I'll pass it on.

Just to check, does "dynamic default" in the log mean the disk image should grow to occupy more space on the real disk?

Storage format: VDI
Format variant: dynamic default

Just to check, does "dynamic default" in the log mean the disk image should grow to occupy more space on the real disk?

Storage format: VDI
Format variant: dynamic default

It tells you the image files in question are dynamically allocated with the value shown as "Capacity: ..." being the upper limit.
See end of chapter 5.2 here:
https://www.virtualbox.org/manual/ch05.html#vdidetails

Does this mean anything to you?

Hypervisor System Log:

24:11:34.575288 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={85cd948e-a71f-4289-281e-0ca7ad48cd89} aComponent={MachineWrap} aText={The object functionality is limited}, preserve=false aResultDetail=0

I can post the whole log if you need it.

Be so kind as to keep Rosetta logs away from this forum.
They definitely use a different task configuration, a much larger vdi image, ...
The snippet here clearly states "E_ACCESSDENIED".

Just a guess:
Together with "[COM]" it might point out a temporary lock set by your vboxwrapper (more precise: the Windows COM interface that vboxwrapper version uses for communication).

All of that should be discussed at the VirtualBox forum and/or the main BOINC forum.

I've tried Boinc, nobody knows. I'll try virtualbox.

I don't suppose there's any chance of creditnew being sorted? I can't use LHC through gridcoin, since it's easy for people to cheat the credit system in here by a factor of 10 :-(