...
- Run batch (pipeline) jobs using Gleam, both for MC generation and for real data reconstruction
- Build Gleam and related software (need access to legacy compiler, external libs) e.g. via Release Manager
- Provide development environment for Gleam programmers (interactive login, editor, debugger, etc.).
- Allow for creation and installation of new version of VM including, for example, new build of Gleam
Interaction with lsf
How aware of VMs should lsf be? VMs could be routinely up and running, in which case lsf could treat them as part of its pool. Or a job submitted to lsf could be directed to run on a VirtualBox host. That job might then do some part of the scheduling an resource allocation normally handled by lsf. In fact, if the webinterface were used, the lsf job need not even run on the VirtualBox host.
What should a batch job do?
This will depend on the state of the VM before the job is run. From the VirtualBox API one could in principle create the VM, configure it, boot it and ask it to run something all from the API, but for our use we'll want to, at the very least, create, configure and register the VM - or perhaps just a template VM to be cloned - beforehand. Booting a VM for every job start does of course entail some overhead (SL6 takes a couple minutes to boot up on my 2.26 GHz dual core laptop, running rhel5), but that may be tolerable in the context of our typical multi-hour batch job. Alternatively, if the (presumably SCCS-maintained) host machine is dedicated to our use, some number of guest VMs can be up and running at all times. In that case we'd want to monitor, to be sure they really are up and usable, and ideally have an automated procedure to reboot any crashed or hung VMs.
...