HTCondorWiki: Vm Universe

 {section: Introduction}
-Comprehensive design outline of the vmuniverse, 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 condor.  For a breakdown of the current work that is being done, please see Ticket #883
 
 {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.
 
 {section: Requirements}
+{subsection: Engineering/Design Requirements}
+*: (E1) The VM gahp should be made as lightweight and minimalistic as possible.
 
-{subsection: Functional}
-*: does stuff
+*: (E2) The VM Gahp shall support script managed and libvirt managed virtual machines.
+*:: subsequently hypervisor specific capabilities should be supported. (e.g. ACPI)
 
-{subsection: Testability}
-*: tests stuff
+*: (E3) Support for multiple CPU's and hard disks (needs further description)
 
-{section: Views (May implement only a subset, usually just pictures.) }
+*: (E4) Support for multiple network interfaces. These mutliple network interfaces may use different types of networking. Also a network interface may be present but disabled ( virtualization equivalent of no cable plugged in ).
+
+{subsection: Functional/Behavioral Requirements}
+{subsubsection: Initialization}
+*: (TBD) shall support the following networking capabilities
+*:: Tunneling the network interface? (ssh to my job).
+*:: Bridged networking interfaces (assign a MAC address).
+
+{subsubsection: Discovery & Advertising}
+*: (F1) The VM-Gahp shall support discovery of a machines vm-capabilities and subsequently advertise that information in the machine classad.
+*::VM_TYPES := script-managed, libvirt-managed
+*::VM_HYPERVISORS := xen, vmware, virtualbox, kvm etc (populated by discovery)
+*::VM_<HyperVisor>_ATTR_<name> (for hypervisor specific capabilities)
+
+*: (TBD) Reporting of NUM_CPUS, HD, & MEMORY? SLOTS?
+
+{subsubsection: Submission}
+
+*: (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
+
+*: (TBD) Shall support shared folders.
+
+{subsubsection: Matching}
+*: (F3) The gahp will only manage a single virtual machine at a time. Functionality should be handed off to libvirt / script where ever possible.
+
+*: (F4) Post matching, the script / libvirt should support a verification stage which checks to see if the vm's requirement is in accordance with what the classad claims it to be.
+
+*: (TBD) authentication
+
+{subsubsection: Running}
+
+*: (TBD) gahp reporting
+*:: Memory, cycles, etc.
+
+*: (TBD) Checkpointing and migrating
+*:: what requirements get "peg'd?"
+*:: define actions (pause, resume, stop ...)
+
+{subsection: Testability of Requirements}
+*: TBD Matrix which outlines F#, E# and how/if it is testable
+
+{section: Design Choices and "Views" }
 {subsection: Logical Design View}
 {blockquote}
 The Design View captures the classes, interfaces, and patterns that describe the representation of the problem domain and how the software will be built to address it.  The design view almost always uses class diagrams, object diagrams, activity diagrams, composite structure diagrams, and sequence diagrams to convey the design of a system.  The design view typically doesn't address how the system will be implemented or executed.
@@ -34,9 +77,16 @@
 {endblockquote}
 
 {section: Use Case Senarios (Tie views together) }
-script scenario
+*: 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 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.
+
+*: 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.
+3.1 allow the user to submit such a script along with the virtual machine ??
+
+*: 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.
 
-libvirt scenario
+*: 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.
 
 {section: Links }
 http://libvirt.org/