HTCondorWiki: Vm Universe

 {section: Introduction}
-Comprehensive design outline of the vm-universe, your one stop shopping location for all things virtual in condor.  For a breakdown of the current work that is being done, please see Ticket #883
+Comprehensive design outline of the vm-universe, your one stop shopping location for all things virtual in HTCondor.  For a breakdown of the current work that is being done, please see Ticket #883
 
 {section: Related Tickets}
 Ticket #883: VM universe refactor {linebreak}
 
 {section: Goals and Objectives }
-The vm-universe gives condor the ability to run virtual machines as a "job", these vm's can either run a dedicated task, spin up extra resources (which can be added to the existing pool), create a virtual pool.
+The vm-universe gives HTCondor the ability to run virtual machines as a "job", these vm's can either run a dedicated task, spin up extra resources (which can be added to the existing pool), create a virtual pool.
 
 {section: Requirements}
 {subsection: Engineering/Design Requirements}
@@ -39,7 +39,7 @@
 
 *: (F2) Submit side processing of different hypervisor specific vm formats need to be defined. This should be capable of building the VM's requirements and populating the classad. {Consensus still needed on what all goes into the classad. ?? }
 *::  Shall support submission of libvirt compatible .xml files
-*::: Can this be a frontend (e.g. condor_libvirt_submit) that generates the appropriate job submission file for Condor? Similar front ends could be developed for other formats (e.g. condor_ovf_submit).
+*::: Can this be a frontend (e.g. condor_libvirt_submit) that generates the appropriate job submission file for HTCondor? Similar front ends could be developed for other formats (e.g. condor_ovf_submit).
 *::  VM_TYPE=script-managed, libvirt-managed (support multiple ones?)
 *::  VM_HYPERVISOR=xen,vmware,... (support multiple ones?)
 *::  VM_ATTR_<name>=... (for generic attributes like memory, cpus, etc.)
@@ -98,15 +98,15 @@
 
 *: Terminating a Job
 
-*: Libvirt is a hypervisor abstraction layer. This means, libvirt can manage virtual machines intended for different hypervisors while giving a uniform, hypervisor independent interface to the interacting user/application. While condor interfaces with libvirt, this interface as of now is not hypervisor independent. Ideally, condor should be able to use libvirt to manage virtual machines intended for any hypervisor that libvirt supports, even if it is one that was not previously supported by libvirt while the condor installation was being coded.
+*: Libvirt is a hypervisor abstraction layer. This means, libvirt can manage virtual machines intended for different hypervisors while giving a uniform, hypervisor independent interface to the interacting user/application. While HTCondor interfaces with libvirt, this interface as of now is not hypervisor independent. Ideally, HTCondor should be able to use libvirt to manage virtual machines intended for any hypervisor that libvirt supports, even if it is one that was not previously supported by libvirt while the HTCondor installation was being coded.
 
-*: Libvirt being a hypervisor abstraction layer, can also be viewed as a hypervisor. Libvirt has it's virtual machine description format which is a libvirt xml file. Condor users must therefore be given an option where they may submit a libvirt xml virtual machine description to condor. Condor must be capable of accepting this input and running the virtual machine on behalf of the user using libvirt.
+*: Libvirt being a hypervisor abstraction layer, can also be viewed as a hypervisor. Libvirt has it's virtual machine description format which is a libvirt xml file. HTCondor users must therefore be given an option where they may submit a libvirt xml virtual machine description to HTCondor. HTCondor must be capable of accepting this input and running the virtual machine on behalf of the user using libvirt.
 
-*: The "actions" that the condor vm-gahp performs on a virtual machine that it manages is finite and enumerable. (At times, not all hypervisors would support all of these actions). This motivates a use case where third parties are given the flexibility to develop support for previously unsupported hypervisors on condor. This can be achieved through supporting the option of a script callout with the virtual machine and the action as parameters. In this case, the script becomes the black box, that interfaces the hypervisor with condor.
+*: The "actions" that the HTCondor vm-gahp performs on a virtual machine that it manages is finite and enumerable. (At times, not all hypervisors would support all of these actions). This motivates a use case where third parties are given the flexibility to develop support for previously unsupported hypervisors on HTCondor. This can be achieved through supporting the option of a script callout with the virtual machine and the action as parameters. In this case, the script becomes the black box, that interfaces the hypervisor with HTCondor.
 *:: allow the user to submit such a script along with the virtual machine ??
 *::: I don't think users should be allowed to submit a virtual machine manager script. I think that violates the administrative controls of the resource owner. Of course a user could try to submit a vanilla job that launches a virtual machine and it would be up to the resource owner to allow/disallow such an option.
 
-*: The case of the user not caring about the choice of hypervisor: many hypervisors these days support the vmware standard vmdk disk images. Likewise, another incarnation of virtualization that is gaining popularity is virtual appliances which may be run on several different hypervisors. The user may be allowed to submit such hypervisor independent virtual machines in which case condor should pick the hypervisor for the jobs.
+*: The case of the user not caring about the choice of hypervisor: many hypervisors these days support the vmware standard vmdk disk images. Likewise, another incarnation of virtualization that is gaining popularity is virtual appliances which may be run on several different hypervisors. The user may be allowed to submit such hypervisor independent virtual machines in which case HTCondor should pick the hypervisor for the jobs.
 *:: See submission functional behavior. One way to support this is to allow for the user to specify a list of types and hypervisors that can be used. Maybe add a special "any" wildcard or have the absence of VM_TYPE and VM_HYPERVISOR indicate "I don't care." I have a feeling that leaving out VM_TYPE and VM_HYPERVISOR would lead to more user errors, however.
 
 *: A collection of virtual machine configurations and disk configurations may be pre-deployed/staged in the pool. One possibility is to allow a vm universe job specification to refer to a pre-deployed virtual machine and provide a secondary disk containing job specific data.