Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Supported OSes
    • VirtualBox supports Linux, Windows and Mac for client and host (though there are a bunch of restrictions for Mac, mostly due to the way Apple does things).
    • VMplayer supports Linux and Windows  
  • API
    • VirtualBox API (the same one used internally, hence complete) supports C++, python, and any other languages that understand (Microsoft) COM or, on non-Windows platforms, XPCOM for applications running on the host.  There is also a web service which implements nearly the complete API.  Any language with a toolkit for wsdl can use this.  It's especially easy to use from Python and Java because the VirtualBox SDK includes wrapper classes for these languages. 
    • The free SDK product VIX can be used with VMplayer.  Functionality is somewhat limited compared to use with non-free products VMworkstation and vSphere, but may be sufficient for us. In particular, it does include the ability to start a program on a VM. Bindings exist only for C, Perl, and (Microsoft) COM.

...

Minimum set of functions to be provided on or for VMs

  • 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 interactive 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

...

There is no need for the VMs to be general purpose machines. Restrictions like the following should keep the machines ( and other SLAC resources ) from being trashed without interfering with the functions we require.  

  • VMs should not have write access to any "regular" public space (space to which centrally-supported public log-in machines also have access).
  • VMs need have no access at all to regular user home directoriesSLAC user home directories.
  • Access to any device to which VM may write should be carefully controlled and limited to selected user ids. Output from VM jobs can be copied to a public area after vetting.
  • Interactive login to VMs normally used for batch should be restricted to a small number of users (using usernames distinct from their regular SLAC usernames?), just those involved in maintenance of the VMs and perhaps some developers if there are needs that can't be met by the dedicated interactive login VMs
  • Interactive login to VM development machines should also be restricted: to VM maintainers and active developers.
  • VMs should only have software installed if it's required; everything else should be stripped out; in particular, no browsers and no email programs.
  • Ports which are not required should be disabled.

However VMs will need some things:

  • VMs need to be able to checkout from and commit to a CVS repository. It could be separate from the usual repository but it should be browsable from non-VM machines via ViewVC or similar product.
  • VMs need to be able to read (mostly) and occasionally write to MySQL databases.
  • VMs used for batch need to write output. Developers using VMs interactively need work space.
  • Developers may need to run X applications on VMs, but cutting and pasting from or to such applications should perhaps be disallowed.

Configuration, performance, $$

Currently (according to BaBar experts who are much further along in their VM plans) multi-core VMs don't perform nearly as well as their hardware counterparts.