You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Initial Goal

..is to run Gleam in a VM.  Probably that entails

  1. Make an "appliance": rhel5 or rhel6 VM with Gleam executable and all required libraries, job options, etc. To start, would be simplest to run MC job, write output to VM local disk.
  2. Write program or script for host machine which will do one of the following:
    • start up Gleam in the already-up-and-running VM
    • first boot up the VM, then ask it to run Gleam

Issues and choices

For the most part the following sections concern decisions for the longer term, not just for the initial goal of running Gleam in a VM, in fact some of them are irrelevant except in the longer term.

Which virtualization software?

I'm experimenting with VirtualBox to start, but since we're only concerned with Linux for now VMware (VMplayer product) would probably serve; there may be other suitable candidates, but apparently only a couple others are typically used to provide "service continuity", and they are proprietary.  Advantages of VirtualBox compared to VMware are

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

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 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.

Resource access and security

For our intended uses VMs must have input from the outside world and must be able to write output somewhere which is accessible to non-VMs, however the VM is perhaps running an unpatched legacy OS with known security holes.

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 SLAC 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 relative to single-core machines as their hardware counterparts, so the better strategy is to instantiate many single-core machines.  But each one needs a license. That many rhel6 licenses would be prohibitive, so the went to Scientific Linux instead.  We may want to do the same. Or things may have changed by the time it matters to us.

  • No labels