This folder contains a plugin that can be used with the Condor 
JobRouter to convert a vanilla job to a vmware job. Basically, 
the plugin searches out all the input files for the vanilla job 
and pushes them into a FAT32 formatted vmdk disk. It the attaches 
the disk onto a preconfigured virtual machine and submits that 
virtual machine back to condor. When the virtual machine job 
executes, it triggers condor inside the preconfigured vm, 
submits the user job and runs it, and shuts the virtual machine 
down when the job is done. When the vmware jobs output comes 
back, the plugin picks up the disk and extracts the output 
from it. The extracted output is then returned to the original job.

The contents of this folder are published under the same 
licensing agreements and copyrights as condor, whether 
explicitly specified or not. The software here is in beta 
stage and is given out on a test basis to users.

The directory structure in this ftp location is as follows.

- README.txt                 : This file
- vmware-plugin-doc.pdf      : More Documentation on this plugin
+ plugin-v0.1                : The actual plugin
+ sample config              : Example condor_config.local file
+ Sample test-program        : A sample test program that can be 
                               used to test the plugin.
+ sample virtual machine     : A preconfigured sample virtual 
                               machine that can be used with the 
                               plugin.
+ sample vm classad template : A sample classad.template file for
                               the plugin to use. (read the doc)

Notes:
------
1. The hook requires Qemu and Mtools to be installed and available
in your PATH expression.
2. The sample configuration does not show the vmuniverse(vmware)
 configurations required. (The configuration example is actually 
for a personal condor which flocks to a pool where VM universe 
is already configured). If using the hook on a personal condor, 
please make sure that vm universe is also configured on the same.

Known-limitations:
------------------
1. The propagation of job's exit status is not completely handled. 
Assuming the job exited by itself, it's exit code is propagated 
to the parent job. However, cases of the job terminating by signal
or going held inside the vm are not handled.

2. Although the transfer output attribute is honored, the other
attribute which describes how the output files need to be renamed
when they are transferred back is not yet honored.

3. Any special requirements mentioned in the original job's 
requirement expression is not honored. The rationale behind this 
is that since the job was selected to be routed, it _has_ to run
inside the vm, and so it's requirements inside the vm is just "TRUE".