*: (F2) Submit side processing of different hypervisor specific vm formates 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).
+*:: 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.)
+*:: VM_<HyperVisor>_ATTR_<name>=... (for hypervisor specific attributes)
+*::: Can this be open ended? Leave it up to the vm manager to decide what to do with attributes that are unknown? How is this information reported back to the user?
*: (TBD) Shall support shared folders.
@@ -84,12 +90,13 @@
*: Libvirt submission & Run
*: Script submission & Run
+*:: User specifies VM_TYPE=script-managed VM_HYPERVISOR=virtualbox in their job submission file (as well as additional VM requirements). On the startd/vm_gahp side, a script matching the VM_HYPERVISOR value needs to exist.
*: Pause & Resume
*: Terminating a Job
-*: Libvirt is a hypervisor abstraction layer. This means, libvirt can manage virtual machines intended for differnet 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 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 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.
@@ -98,5 +105,17 @@
*: 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.
+*: 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.
+
{section: Links }
-http://libvirt.org/
+*: http://libvirt.org/
+*: http://www.virtualbox.org/
+
+{section: Raw Thoughts, Ideas, and Questions (Migrate to above later)}
+
+*: Script managed virtual machines are provided job class ads specifying the virtual machine universe job to be run. The script is responsible for parsing the class ad, making any modifications to the ad necessary to meet administrative requirements, and carry out the specified vm_gahp command (e.g., start, preempt, checkpoint, etc.). Commands may be executed, rejected, modified, or not-implemented.
+*:: Should these status codes be returned to the user?
+*:: If a classad is modified, should the user be notified? Should the user receive indications of what was modified? What are the security implications of providing that information?
+*: An interesting side effect of script managed virtual machine is that it is relatively straight forward to override and fill in attributes in any arbitrary way. For example, it would be possible for a script implementation to call out to a MAC address and IP address management system to assign MAC and IP addresses to machines. Some care is needed to recover if the script is unable to gather all the information necessary to launch a virtual machine.
+*: Also note, "scripts" is a fairly loose term. It is entirely possible to implement scripts in compiled languages like C or C++, Java, or traditional scripting languages.
+*: Do VM universe jobs interact with job hooks or job wrappers? If so, how?
