Dotsch will sort of do this, you can install the OS on a main machine, and it will allow diskless clients to boot from it's image, each being then able to pull their own BOINC WU's.

I don't think that the WU's will be pooled, however the server can handle all communications with the project servers iva proxy, and handling downloading/ reporting of all WU's for the diskless clients. the images for the WU's in progress by each client are mirrored on the server, so if a client is restarted, it will continue the WU it was working on before it rebooted.

You may be able to push the Dotsch image into the VM and use the shared resource space to host the image for the machines, however to truly use the upload/download feature as-is, you need to have the main system running Dotsch in order to dish out the images for the VM, and to act as the proxy for the machines to access the internet.

Somewhere in the mix, there needs to be a machine with internet access, even if it's just a diskless client booting the client from USB, having it act as the server, and map the network storage area as it's drive to serve images from and to store the WU's in progress by the clients. Without knowing the exact makeup of the network, it's difficult to guess at exactly which way would be best, but Dotsch will very likely make the task easier since it was designed to do such work.

http://www.dotsch.de/boinc/Dotsch_UX.html

Dotsch did a lot of hard work modifying an Ubuntu image to streamline Dotsch/UX and to make a lot of what you are talking about automated. It even supports CUDA on the diskless clients. Great distro by a hardcore BOINC'er

And just to note: you won't find support for it on the forums for most projects, as it's way outside the realm of typical crunching, however it's the easiest (very relative use of the term here) way to achieve what you are looking for.

vlankhaar,

What you want, a little central pool aggregation, dispensing units to diskless nodes is not in the compendium of configurables. Even IBM with there many thousands of hosts have to each fetch their own work from the WCG servers. You have to develop your own script that exchanges clients on a central host, fetch work, load it onto a node. Theoretically it could be done with all nodes + 1 extra instance that fetches the work, then loads 'that' client onto a node and start it there. It would require lots of scheduling and stopping, copying back, copying forth, restarting. The stopping of clients on rotation would cost progress, but still if you had say a dozen, with each holding several days work, it could be made to work [lots of trial and error and mapping the scheme]

As for the concerns voiced above... not in this century. The integrity of results and their uniqueness and non-duplicability is absolute. A result reported and taken in correctly will not be accepted a second time. Never has at WCG. BOINC Server release 700, just implemented, took the last bit away from the clients... the credit claiming and performance tracking. That is all computed on the server now.

--//--

I think I've managed to convince the security operations folks that allowing the cluster to initiate a connection out to WCG via a IP:Port whitelisting proxy will not result in unmitigated doom, and I think I can probably handle the new auditing burden.

If I can get network operations folks to agree that the bandwidth requirement is small enough, I might actually be able to get direct connection from a cluster vm to WCG. (is there somewhere that lists the approximate average transfer-size-per-point or transfer-size-per-work-unit for each project?)

Given that these systems are going to be diskless (no USB, most of the filesystem is read-only, with a tmpfs filesystem mounted on /BOINC for World Community Grid to run in), are there any recommendations on BOINC configurations to use?

I'm guessing that the following would make sense:
<abort_jobs_on_exit>1</abort_jobs_on_exit>
<dont_contact_ref_site>1</dont_contact_ref_site>
<report_results_immediately>1</report_results_immediately>

Is there a "detach on exit" command, or should I wrap that into the planned-shutdown script? Does detaching serve any purpose on the WCG server side? Or is that just to cleanup the local boinc client's filesystem (which, I don't care about because the moment kernel unmount /BOINC, its contents disappear.)

Is there anything I can do to minimize the number of devices registered with WorldCommunityGrid? I'm guessing that I'll just have to give in and accept that I will have a whole bunch of defunct devices listed.
http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=16521 suggests that I have backups of a bunch of files, but I am not convinced that I want to attempt to (a) collect backups from VMs on planned poweroff, and (b) dole them out to newly created VMs on boot. It also suggests that there is (as of 5 years ago), a host merging feature, but that will likely fail in my configuration given the VMs are likely to be DHCP driven and memory allocation is likely to vary between VM boots.

On bandwidth use, http://bit.ly/WCGDSH has a line showing 24 hours use per science based on current runtime averages. FAAH/HFCC use least, and after SN2S, DSFL, GFAM, all under 2Mb per core per day. Weighted average over all sciences, 8.8 MB per core per day.

On shutdown (loosing the install), those options look fine. Detaching in fact does not help [the boinccmd tool has an option I think] as the server will interpret this as "oops, but maybe the device gets attached again, so lets see what happens to see if we can resend the lost tasks" and keeps the tasks that were in progress on hold until they expire by deadline.

Devices are recognized on some 5 criteria. If they are the same on next device install, good chance the automated system will recognize the device, but if the complete install is lost, including the data directory it is possibly not going to work.

A few others who run a PXE setup actually store the BOINC instances away from their diskless systems when they have commercial work for their systems, then refetch them and continue running where they left off. This is DIY.

Proxy IP addresses: see this post by knreed for latest http://www.worldcommunitygrid.org/forums/wcg/printpost_post,338077 . Would not recommend you run Clean Energy for Harvard, lest you want to use 118MB per core per day (for average systems).

--//--