After dealing with a BIOS configuration glitch at the beginning, I have VB running VirtualLHC and Atlas since June 1st, 2015. I went to the forum and got the info I needed to get her up and running. A couple glitches after Windows 7 upgrades, but then back to running smooth after a couple days without touching it.

---

Tried some. Not working properly on my machine...

I have been running VM applications for RNAWorld. As others have mentioned, they have a high error rate. If the computer crashes, it can cause multiple snapshots in the VM that have to be cleaned up manually before the machine will run, again. This can also cause the WUs to error out.

The VM doesn't run well on low-end computers and is RAM intensive. My old box (now my husband's) has dual-core CPU and 3G of RAM, and the VM has to wait until the computer is completely idle to have enough RAM to run. My current box is 6-core with 8G RAM. The VM runs on one CPU with the other 5 available to other projects.

I will note that I have never successfully completed one of RNAWorld's WUs. Those that didn't die to computer failure or operator error (see duplicate snapshots above), errored out on their own. I currently have one WU running on each machine and my fingers crossed that at least one of them will actually complete. It's damned painful to have several hundreds or thousands of hours of computing time end in a failed computation.

For users with higher-end machines and enough knowledge to play with the VMs, they seem to work just fine. For the average user who just wants to contribute spare cycles to science, they're a pain in the tailfeathers.

VM are quite bad at using GPU power. Since GPUgrid has not been renamed to something like IntelPhiGrid yet, it doesn't sound nice to use VMs.

Personally I'm not quite comfortable with VM projects since they makes the programs less transparent to the volunteers. The app just appears like a huge black box that eats up a fixed (probably unnecessary) amount of your memory and processing power.

If you are looking for some `compile once, run (or perhaps debug?) everywhere' solution, even wine will do better at using CUDA power. The `staging area' fork of wine, wine-staging, supports using the native CUDA support found in nVidia's proprietary driver. Please note that as long as it's still in the staging area, it cannot be considered as stable. And I can't find any support for CUDA pass-thru on OS X.

ATLAS has proven to be really difficult to run. The admins have gone through countless versions over many months and after all that I now find the tasks no longer run on OSX after some success.

Cosmology, by way of contrast, worked firs time and has been going great.

So VMs CAN work but as always the source material dictates.

Having said that, I'd much rather you spend what resources you have on supporting AMD cards on Linux than on VMs.

When you say VM's I take it you mean vendors of VM applications

Microsoft HyperV, VMware ESXi, Virtual box, Etc

And also depending on CPU/RAM/STORAGE how many Vm's can be created.

All these give a virtual switch so the Application can talk to the host, that then can talk on the internet.

If what's called NAT or Network Address Translation is not setup properly you wont get any access or updates on the VM, it will just sit there not doing anything, and boinc wont update.

So get the VM's Started and on host run CMD in Admin IPCONFIG/ALL to see the gateway. Note down gateway, Goto VM and open CMD, then type PING ( Gateway ). you are either going to get a response or not, if not look at your virtual switch config its not set correctly, usually with any application on a Microsoft platform anyway now sets up a rule to let the application access the internet through the firewall, play with setting until you get a response then boinc should update

Hope this helps.

Also Raptures Riot gives a good tip as well

FWIW - I don't run any BOINC projects in VMs, but I do run one at work from time to time to support software that only runs on XP. We use Microsoft's VM, and it is noticeably slow. Some times, it fails to connect to the resources of the base OS - Win 7 - and I must restart it at least once for it to run properly. My machine at work is a Sandy Bridge machine.

I have also setup Virtual box on one of my machines at home. It was a Sandy Bridge E running a quad core, eight thread i7-3820 with 32G of ram. I wanted to set up an isolated environment for developing an Android app. I went through the procedure to clone my Windows 7 machine and turn that into a VM to run inside of Virtual Box.

I abandoned that approach when it became apparent that I would need an additional license for Win 7 in the VM. So, this is a potential problem for us end users if the OS for the project is Windows. Also, the VM, even on the Sandy Bridge E machine, was noticeably slower than the native OS and one of the things that SBE machines do well is handle memory intensive apps like VMs.

From the sound of it and speaking as a software developer, the CERN project takes the burden off of their developers and places it on the volunteer. A project that requires high maintenance will probably only appeal to the most technical of volunteers, and some may not want to devote the time to running the project.

On that note, GDF, my question to you as a software developer would be what are your reasons for considering a VM? In my opinion, the reasons for doing something are the most important. I work in an R & D department, and there is one developer there that does things because he can, often, without consulting others, and without considering the consequences. Right now, he has a significant amount of work to do because he dug himself into a hole by writing custom code for a GL toolkit that is now outdated and now uses DX. My point here is that as I see things, it is best to try to find the best overall solution when engineering software.

While it sounds like the VM solutions work for some, it also sounds like the VM solution does not work well for others. Personally, I would be adverse to running a BOINC project that depends on a VM especially if it requires more time than I have to devote to it.

---

I host game servers on Debian running in Virtual Box in Windows 7. I don't run BOINC in a virtual machine though, as I don't want the additional overhead, and lack of dynamic available resources and fine control.

So, if the question is if you guys are looking to run things in user space VMs, I would advise against it unless there is a specific need to. I for one wouldn't be contributing to those work units.

Cheers.

---

My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#

The question of overhead should be considered, but probably favors the VM. Most projects are developed under Linux, and I usually see anywhere from a 20% to 80% improvement running Linux over Windows (I run only Win7 64-bit myself, but look at the performance numbers of completed Linux work units, etc.). I would guess on average Linux gains a 40% advantage over Windows. If the VM imposes a 15% penalty as noted above (I don't know myself), then the project still gains a lot overall, considering that the large majority of users are on Windows.

I don't see the problems that some people face; my machines run 24/7, and once the VM is set up, then they just run. And I have had no unusual problems setting up VirtualBox on CERN or Cosmology (or RNA World, but they never have work). The amount of memory used is determined mainly by the project. Even though the CERN projects take a lot of memory due to their science, Cosmology takes very little memory. I think the real question for GPUGrid is whether or when a VM will be available that allows the use of GPUs, if that is what they intend to use it for.

From the sound of it and speaking as a software developer, the CERN project takes the burden off of their developers and places it on the volunteer. A project that requires high maintenance will probably only appeal to the most technical of volunteers, and some may not want to devote the time to running the project.

I think that the usual balance pushing towards the VM side of the scale is that academic/scientific programmers are more comfortable programming for Linux (and perhaps their institution's particular chosen flavour of Linux), whereas the largest available group of volunteers has Windows installed.

Many projects seem to be outside their comfort zones simply developing for and maintaining the basic trinity (Linux/OS X/Windows), and if the raw science has already been developed in-house for a specific Linux implementation, then it can appear to be a valuable time-saver just to load the science into a preconfigured VM and let it run from there. In reality, it simply shifts the problem somewhere else - into the scheduling and communications regime.

I have not had many issues running ATLAS and vLHC, been doing so for a long time. However when they dont want to play nicely its quite hard to figure out what went wrong and you end up manually cleaning up the snapshots.

ATLAS does use a lot of RAM and you really need to setup an app_config.xml to reduce the number of concurrent tasks to prevent it runnig out of space. vLHC limit the project to two concurrent tasks and the RAM footprint is smaller.

If you were intersted in putting GPU into the VM, then many users having 1 GPU per CPU would not need to limit the number of tasks as the number of GPUs will effectively do that. Users with 4 x GPU per CPU would still probably only need approx 16GB RAM to run this in a VM.

RNA World has been running into a problem with VM workunits: Once any computer has been detected as not supporting VM, it's very difficult to get that computer to check for VM support again with the current version of BOINC. They appear to be waiting for a new version of BOINC that fixes this before they start offering more workunits.

My computers have occasionally tried to run RNA World VM workunits. None ran properly yet, due to the VM support detection problem.

Another problem they have seen: The amount of memory used is built into the application, and cannot be adjusted as needed. This often makes it reserve much more memory than it actually uses.

Looks like you should hold off on offering VM workunits until a new version of BOINC has a fix to at least the VM support detection problem. Possibly also until a new version of VM offers GPU use support.

If GPUGRID starts messing with VMs, I'm out... :/

---

Team Belgium

VirtualLHC (LHCat2) works okay, but resource intensive - obviously vbox and having stale vm versions can result in some bloat

If GPUGRID starts messing with VMs, I'm out... :/

But if they don't generate more work, we are all out. Using VMs may allow new researchers (i.e., grad students) coming into the group to develop their projects more rapidly, using whatever standard version of Linux that they use. If they get tripped up in the difficulties of making different versions to run on various machines, it could slow down the entire process.

For me. I cann't use VM. I cann't install VBox over all of my machines.

Excellent conversation!!!

I've worked through the challenges for the CERN projects and have spent more than enough time know that I'm not a fan of VM crunching in it's current form. I still crunch CERN because I like their science as much as I do GPUGrid but it really is more work than a hobby should be.

From a cruncher's perspective VM crunching is much more complex than regular BOINC crunching but I also understand as a developer it is easier to make one version of an app. Many fine points have been made regarding the efforts to crunch and some on the implementation of VM, I don't think this is an either / or situation and as an educational institution of forward thinkers you may need to explore this avenue as you have others in the past. Perhaps implementing VM for the CPU app would provide a way to explore VMs before launching wholesale for ACEMD.

I present the following issues to hopefully make any future VM implementation easier for crunchers.

Typical reasons for apps going bad, in order of occurrence
1.) Hardware crash due to power outage, too high OC, too high temps
2.) A bug in the software itself
3.) Need a particular version of a GFX driver
4.) Rarely a Linux issue with a missing lib - usually when someone moves from 32 to 64 bits.

Those issues do not go away and then there is the addition of trying to get the VM infrastructure coordinated.
1.) What flavor of VM?
2.) Is it the same flavor that comes with BOINC?
3.) Is it the same version that comes with BOINC?
4.) Do I have to download and install software XYZ?
5.) Do I need the extension pack or not (versions must match exactly)?
6.) Do I need to change BIOS settings?

Here are some additional troubleshooting areas/ cleanup tasks that are sometimes necessary when we experience crashes, hangs, and postponements.
1.) When / how do I cleanup a snapshot - I have multiple which one is it?
2.) When / how do I cleanup a VM instance - I have multiple which one is it?
3.) When / how do I cleanup a BOINC slot - I have multiple which one is it?
4.) What do I do when the task says postponed for 24 hours?

Please also consider that a cruncher will ask any / all of the above in the forums (please create a separate forums for VM) and if they do not get quick, easy, and accurate answers they will likely move on to another project. GPUGrid enjoys a fairly high level of technical literacy amongst it's volunteers but having to handle new challenges with VM may make the boards look like the project has more issues than really exist with the science applications themselves.

---

Thanks - Steve

I do see that people like to look into the VM to see what is going on, but I just let it run. And I have not had to clean up anything since upgrading to VirtualBox 5. Also, there were problems with BOINC not cleaning up slots after failed work units, but that has been eliminated with the recent versions of BOINC insofar as I know, though I don't see many failures myself for some reason (probably because I have a lot of memory and don't reboot often).
http://atlasathome.cern.ch/results.php?hostid=17032
http://lhcathome2.cern.ch/vLHCathome/results.php?hostid=85673
http://boincai05.cern.ch/CMS-dev/results.php?hostid=688

The bundled version of BOINC now comes with VirtualBox 5.0.10, a very recent version (the latest is 5.0.12, out for only 5 days). These newer versions are mainly bug fixes, and don't affect the major functionality. So you will need to upgrade your software if you go to a VM to the latest versions, but beyond that GPUGrid will have to do a trial to see how it flies. Some users may have problems, others not. They won't know the numbers until they try it out.

There are projects giving out VMs instead of normal applications. We are considering it. How is it? Does it work?

thanks.

gdf

I've run them at other projects and had relatively few problems. I guess I've been lucky. They certainly have a much higher failure rate than standard BOINC apps. The average user isn't going to bother with it if there are problems, they'll move on quickly.

Are we talking about replacing the current apps with VM computing, or adding VM apps?

---

Team USA forum | Team USA page
Join us and #crunchforcures. We are now also folding:join team ID 236370!

I have been running vm recently rearly am just at start.
Am away for 10 days will let you know more early next year.
Have a good Xmas and new Year.
TAG