...
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, but I don't see any advantage to this.)
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 on a per-job basis - 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.
...
There were some hard-coded file paths, etc., which caused 3. to fail. However that step still failed even after I fixed them (all the ones I'm aware of, anyway). At least it fails further along in the process - the VM is created and a (virtual) disk is created for it, but the operation of attaching the disk to the VM fails. Since I don't expect to use the API to create VMs (only to activate them and run programs on them), there is no reason to pursue this.
SDK cont'
...
d
March 15th update:The immediate goal is to write a C++ program using the sdk which will start up a pre-defined VM and get it to run some executable (and then perhaps shut it down). So far I've managed to get through the start-up step. This was much more painful than expected but, now that I've learned something about COM, xpcom, and where to look among VirtualBox source for interface information - there is formal and reasonably complete documentation for the API, but not really geared for use from C++ - the last bit should be easier.
March 19th update: I was able to write a C++ program to accomplish the second step (run a program on the VM) but so far only after the VM was up and running. If I try to do it all in one program the second step fails, I assume because the VM is in some sense not ready.
June 11th update: Test program boots the VM, checks for "running state", checks for availability of disk and attempts to locate the particular script it intends to run. Even when all these checks succeed, the running of the script can still fail. However, it succeeds if a sleep of 100 seconds is inserted before attempting to run the script. 60 is not enough. This is not a very satisfactory state of affairs.
Other Interfaces
VirtualBox provides a variety of ways to get at the core functionality. Approximately from least to most grungy:
...
VirtualBox shell - extensible python interface. Have not yet tried it, but probably should. It's only barely mentioned in the SDK document, but it looks like the some source is installed as a Python site package. The main program is (relative to installation directory)
sdk/bindings/glue/python/sample/vboxshell.py
On my machine that's /usr/lib/virtualbox/sdk/bindings/glue/python/sample/vboxshell.py
See SDKRef.pdf, section 2.1.2, for a little more information.
Web service - exports nearly complete API. Can be used via Java, Python, or as raw web service. I don't think it's appropriate for us. We don't need the ability to control VMs remotely; I expect VM commands will be issued from the host.
...