<WRAP important> NOTE: See the GBAC manual for in depth information about usage, download links and installation. </WRAP>
The Generic BOINC Application Client (GBAC) is a virtualization enabled wrapper application. Beyond its name GBAC also represents a generic framework providing virtualized environments for various distributed computing infrastructures (DCIs). GBAC was implemented using the DC-API Meta API and does not rely on any middleware specific functionalities, thus it is possible to use it on any DCIs that are supported by DC-API, currently BOINC, Condor and XtremWeb.
The following subsections detail the internals of GBAC to give an overview. GBAC wrapper consists of three components: (a) the wrapper binary (see 1. in the figure below) itself is a BOINC enabled DC-API application that contains all BOINC related parts and handles communication with the BOINC client. Its task is to set up the client execution environment and manage the virtual machine on the client machine; (b) a configuration file (see 2. in the figure below) is used to set the different parameters for the virtual machine: (i) the operating system type (e.g., Linux 64bit); (ii) the size of the allocated memory for the virtual machine; (iii) whether the machine should have network access; (iv) which virtual appliance to use; and (v) whether to enable a shared directory between the host and the guest (the virtual machine). The configuration file is detailed in Section Configuration file; finally © a virtual appliance (see 3. in Figure below) that contains the operating systems, libraries and GBAC guest extensions (detailed in Section GBAC Guest Extensions) for the virtual machine. We provide a 32bit Linux VA with the GBAC guest extensions installed (see Section Downloading GBAC), but it is also possible to create custom ones.
These three components are deployed at the BOINC server as the GBAC Application. The legacy application binaries and inputs (see 4. and 5. in the figure above) are input files for this application and need to be specified for each work unit. It is possible to bundle the legacy application binaries into a single file, see Section sec:appbundle for more details.
First a legacy application with its inputs is submitted via the 3G Bridge to BOINC (see 1. and 2. in the figure below) and it is transformed into a GBAC application work unit containing the binaries and input files of the legacy application as inputs of the GBAC application. When a BOINC client connects, from a host where VirtualBox is installed, to the BOINC server and asks for tasks, it receives the work unit containing the GBAC application with its inputs. The BOINC client first downloads the GBAC binary, its configuration file and the virtual appliance along with the legacy application binaries and the input files (see 3. in the figure below).
After the download finished the client starts the GBAC application. The first task of GBAC is to bootstrap the execution environment: it creates a directory that will be shared between the host and guest and all legacy application binaries and input files are copied here (see 4. in the figure). Also a special file is put into this directory that contains additional parameters of the application (e.g., command line parameters and environment variables). After this the virtual machine is started (see 5. in the figure) using the VirtualBox command line interface (
VBoxManage). All parameters for the virtual machine are set in a configuration file for GBAC. This configuration file is currently part of the application and common for every GBAC application work unit, but it can also be supplied individually for each task allowing more customization for the virtual machine. The configuration file also contains reference to the virtual appliance to be used. Currently a single Linux appliance has been developed for GBAC but using more appliances is not prohibited by the GBAC concept. The appliance contains the GBAC guest extensions (see 6. in the figure) and these are started right after the boot process finished. First, a component checks if there are any application bundles found in the shared directory. If yes, it extracts the contents to a separate sandbox within the virtual machine. If not, then all files are simply copied to the sandbox. After this the legacy application is started in the sandbox (see 7. in the figure). Volunteer resources are highly volatile and any application running on these resources in the framework of a volunteer computing project it should be prepared for interruption or shut down. This problem is usually solved by including an application specific (application-level) checkpointing mechanism in each application. The advantage of GBAC is clear here: application-level checkpointing is not needed since GBAC uses the system-level mechanism provided by the virtual machine monitor. GBAC can be suspended or stopped at any time regardless of what application it is executing and the suspended GBAC application can be resumed either on the current client or on a new client. While the virtual machine is running, GBAC continuously monitors its status through the virtual machine monitor. After the execution of the legacy application has finished, all new and changed files are copied to the shared directory by the guest extensions (see 8. in the figure). Finally the virtual machine is instructed to shut itself down. Next GBAC notices that the virtual machine has terminated and it will copy all changed files from the shared directory to the working directory and terminate itself (see 9. in the figure). From here the BOINC client takes over, it will contact the BOINC server (see 10/a. in the figure), upload the output files (see 10/b. in the figure) and report the completion of the task. Next 3G Bridge fetches the results from BOINC (see 11. in the figure) and will return it to the submitter (see 12. in the figure).
For in depth description and installation instructions please refer to the GBAC manual.