*: 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 ?? +*:: 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.
