...
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 15, 2012 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.
Other Interfaces
VirtualBox provides a variety of ways to get at the core functionality. From least to most grungy:
VBox gui (canned program). It exports nearly the complete API. I used it to create Scientific Linux 5 and Scientific Linux 6 VMs (after downloading ISO images from the SL web site) and use it routinely to monitor VM activity. It's fine for interactive use; not appropriate for running batch jobs on VM
VBoxManage (canned program). Command-line interface which exports complete API. It could conceivably be used to start batch executions. The command to start a program expects a plain text password; maybe it could be hidden in a script variable. I've looked over the source and exercised the program in order to gain insight into how things are supposed to work.
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 source is installed as a Python site package.
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.
COM/XPCOM (COM is Component Object Module, Windows only; XPCOM is an open source implementation of COM used on non-Windows platforms). This is what the VBox gui and VBoxManage use internally, and it's the mechanism I've been exploring for us so far.