The VM Universe tests share a common framework, encapsulated in
x_vm_utils.pm. The tests all submit the same VM (bundled in
x_vmware_test_vm.tar.gz) as the test job. This VM contains an
init script that initiates the following:

    - a script read from /dev/fd0 (a virtual floppy disk) is
      executed
    - the script can then use the virtual floppy for communication
      with the test program running outside the VM
    - once the script completes, the VM is shut down

The framework in x_vm_utils.pm provides an initialization routine
that sets up a personal Condor configured for VM universe and creates
the virtual floppy disk with the script in the test's .sh file (e.g.,
job_vmu_basic.sh). A cleanup routine shuts down the personal Condor.
The framework also provides functions for altering the submit file of
the VM job (which is based around the template in x_vmware_test_vm.cmd)
and submitting it when it is complete and for writing and reading the
virtual floppy contents.

Note: Making changes to the test VM in x_vmware_test_vm.tar.gz is a bit
of a pain because (a) it's hosted with our externals server, so we need
to give it a new name when we change it and (b) it
expects to find a virtual floppy with a script on it when it starts up,
and if it doesn't it will immediately shut down. Here's a procedure that
allows changes to be made to the contents of the test VM's virtual hard
disk (x_vmware_test_vm/condor_test.vmdk in x_vmware_test_vm.tar.gz):

  1) Create a virtual floppy with a sleep script.

     $ tar xzf x_vmware_test_vm.tar.gz
     $ cd x_vmware_test_vm
     $ python
     >>> s = '#!/bin/sh\nsleep 600\n'
     >>> s += '\n' * (1440*1024 - len(s))
     >>> f = open('test_data.img', 'w')
     >>> f.write(s)
     >>> f.close()

  2) Use VMware's interface to add the virtual floppy disk to the
     test VM.

  3) Boot the VM and make any changes you want. The root account's password
     is "root".

  4) You'll need to make a new tarball with changes, complete with a
     new name. You'll likely only want to save the changes made to 
     the VMDK file:

     $ cd ..
     $ mv x_vmware_test_vm x_vmware_test_vm.new
     $ tar xzf x_vmware_test_vm.tar.gz
     $ cp x_vmware_test_vm.new/condor_test.vmdk x_vmware_test_vm
     $ tar czf x_vmware_test_vm-2.tar.gz x_vmware_test_vm
     <copy new tarball to externals server>
     <change tarball name in x_vm_utils.pm>

On May 18, 2009, the test VM in x_vmware_test_vm.tar.gz was modified 
in-place (i.e. the new image was not given a new filename). The old 
image was renamed to x_vmware_test_vm.tar.gz-old.
The problem was that when fsck is run at boot-time, it forces a check 
starting 6 months after the image was first created. Fsck says it 
modified the filesystem, causing the boot script to ask on the console 
whether the admin wants to enter single-user mode. As the system never 
finishes booting, all of the VM-related tests time out. We believe the 
only change fsck is making to the filesystem is recording that a new 
check was performed. In the new VM image, /etc/rc.d/rc.sysinit is 
modified to not perform the fsck on the root filesystem. Since we never 
save the modified image after running an instance, there shouldn't be a 
chance for the filesystem to be corrupted. The same name was kept for 
the new image because no test can succeed with the old image after May 
16, 2009.
