Running BOINC in virtual machines

[Fardringle]

I've been volun-told (told that I volunteered) to assist some of our software engineers with setting up Linux VMs on their Windows 10 workstations so they can do some development in Linux.

Since I have almost no experience with Linux OR with Hyper-V VMs, I decided to play around with making some VMs on my personal computer at home that has a Ryzen 9 3900X, 32GB RAM, and lots of free drive space on a second SSD where the VM drives are located. I set up four identical VMs running Linux Mint 20, each with two CPUs, 4GB RAM, and 20GB of drive space. No problem installing and running them all at the same time. I haven't done anything else inside any of them yet except to install the latest version of the BOINC client and attached them to a few projects to see how VMs and the host system behave when the VMs are being stressed out with 100% CPU usage.

The results have me confused and I hope someone here can help me sort them out so I can have an idea where to start looking if the engineers run into similar problems.

VM 1 has absolutely no problems. Happily crunching along on various tasks from the projects, reporting results, and receiving appropriate credits.

VM 2 is running and returning work, but I cannot get the BOINC Manager to open on the VM screen. Nothing at all happens when I click on the BOINC Manager shortcut. I have rebooted the VM and the host machine and tried reinstalling BOINC in the VM, but I'm honestly not sure I did that right. A side effect of this is that it's still reporting the default CPU benchmark speed and not getting proper credits since I can't manually run a benchmark to get a real CPU score in the BOINC Manager.

VM 3 pretends to be running, but after a few initial tasks from the projects I assigned, it is now only working on a single iThena task (non-CPU-intensive project that does network mapping tests) and a single WUProp task (another non-CPU-intensive project that collects statistics on work done for any BOINC projects running on the system), and will not even try to request work from any of the 'normal' projects. When I do a manual update to get new work, the BOINC event viewer says, "Not requesting tasks: don't need (not highest priority project)" which doesn't make sense. Even if it's not the highest priority project - and all projects are exactly the same priority - that should only apply when other projects already have enough work in the queue. And there's nothing else running on this system/VM.

VM 4 doesn't even pretend to be running BOINC. It got a few tasks at first as well. But now it won't even do work for the NCI projects iThena and WUProp. It's just sitting there with an empty queue and gives that same "Not requesting tasks: don't need" message that VM3 has if I try to manually request new work for any normal projects.

BOINC isn't the real priority here. I mostly just wonder why the four identical VMs are behaving so differently, and if there's anything I can to do troubleshoot them to try to find out why they aren't all showing the same behavior.

 

[TennesseeTony]

I don't know if this is of any value, but WUProp goes to great lengths to prevent "cheating" and subduing additional clients it detects as existing on the same machine.

 

[Fardringle]

I know it has an algorithm to not give credits in the WUProp project for multiple clients, and that's OK since I'm just doing this to test VMs, but I haven't heard of it actually preventing other projects from running in those clients/VMs...

I'll try turning WUProp off in the VMs to see what happens. Thanks.

 

[Ken g6]

For VM #2, BOINC has a flag to detect whether another instance of BOINC Manager is already running. Sometimes it gets stuck on Linux; I don't know why. Try opening a console and typing `boincmgr -m`.

 

[StefanR5R]

"Not requesting tasks: don't need (not highest priority project)" which doesn't make sense.

Don't even try to make sense of it. :-(

Just set *all projects but one* to No New Tasks. This includes NCI projects. I have seen a report elsewhere of NCI projects causing the client to not request work for "real" projects. This report was for boinc on bare metal, not in VMs. — Edit, and abort the tasks of all but the one project, to be sure.

(PS, I occasionally ran BOINC in virtual machines myself: I briefly experimented with Win7 guests in VirtualBox on Linux hypervisors, in order to run a project which only had a Windows application. And I (but not xii5ku) occasionally ran boinc in Linux guests on whatever hypervisor the respective cloud provider might have been using, which was certainly not MS HV. Therefore I can't really help you more with your particular setup. There are supposedly WCG users who like their Windows hosts but prefer the performance of Linux applications at WCG, hence run Linux VMs with boinc on a Windows hypervisor — but I don't think anyone of the TeAm mates who are actively posting here is doing this.)

 

[Fardringle]

For VM #2, BOINC has a flag to detect whether another instance of BOINC Manager is already running. Sometimes it gets stuck on Linux; I don't know why. Try opening a console and typing `boincmgr -m`.

That did get a BOINC Manager screen to open, and it said that another copy was already running, so that fits your theory. However, it wanted me to enter a host name and password, and while I assume the host should work as "localhost" or as the actual VM computer name, I don't have any idea what the password would be since BOINC never actually asks to create a password when it is installed, and it didn't accept the system account password. I think it might have un-stuck whatever was stuck, though. I'm able to open the BOINC Manager and show activity normal after doing a reboot after that command. Just doing a reboot before didn't work.

I don't know if it's simply coincidence or not (probably not), but removing the WUProp project from all but one VM seems to have let VM3 and VM4 start working again.

So I guess it's good to see that it was apparently just BOINC not cooperating, and not the the VMs themselves behaving weird, since consistent VM behavior is what I really need for the engineers...