Note to reader:
---------------
This is a second version of the vmware plugin. The functionality achieved
by this plugin is considerably different from the first version. The first 
version pushes the job inside and runs it inside the vm using a personal
condor instance inside the vm. This version on the other hand fires up a 
vm pre-configured to join the pool, fetch and run the selected job. While
the functionalities are considerably different, this version was developed
as a sequel to the first and an understanding of the first version is
expected off the reader. Many concepts and details mentioned in the 
documentation of the frist version are glossed over here because of this reason.

The gory details:
-----------------
For the reader familiar with the previous version of the plugin, this version is
a lot simpler. Unlike in the previous version, this version omits all the code 
for stuffing the job into the disk.

All that the code in this version does are..
1. modify the classad of the original job to add a jobsignature and machine signature.
   - The job advertises a signature, which the vm which will run it looks for.
   - the job's requirement expression is modified to run only on a machine with
     the stated machine signature.
   - This new classad becomes the transformed or routed job. The idea is that this
     routed job should _only_ run on the vm that will be submitted.
2. Create a vm with a condor instance inside it which will
   - be submitted to the pool in the background, and will when run, come back and
     join the pool as an execute node.
   - will advertise the machine signature required by the transformed job.
   - will reuire the job-signature mentioned by the transformed job in the start
     expression.. These two are so the machine only runs the transformed job.

The code is pretty simple. The expectations are that there's mtools and qemu 
installed and available in PATH. The sample configuration file provided shows
the configuration variables involved. The machine when run is expected to 
run the condor-init.py stuffed in the data disk at startup. Read through
hook-tranlate.py to understand the code -- it's pretty straightforward.

Known Limitations:
------------------
1. The vm that's fired up to run the job has a pretty barebones configuration. 
Depending on the site that may deploy this plugin, the condor-init.py script
template may have to be modified to incorporate more gory configurations in
the vm. 

2. The code is written towards a standard linux based vm. Other platforms may
need modifications.

TODO:
---- 
the exit and cleanup hooks have not been provided. The functionalities of these
are pretty straightforward again. 
The exit hook needs to kill the vm fired in the background. This will involve
a bit of bookkeeping to track the jobid of the vm.
The cleanup hook will just need to remove the temporary working directory which
is called "jobfolder" in the scripts..