vm universe jobs may be executed on any execution site with VMware, Xen (via libvirt), or KVM. To do this, HTCondor must be informed of some details of the virtual machine installation, and the execution machines must be configured correctly.
What follows is not a comprehensive list of the options that help set up to use the vm universe; rather, it is intended to serve as a starting point for those users interested in getting vm universe jobs up and running quickly. Details of configuration variables are in section 3.5.25.
Begin by installing the virtualization package on all execute machines, according to the vendor’s instructions. We have successfully used VMware, Xen, and KVM. If considering running on a Windows system, a Perl distribution will also need to be installed; we have successfully used ActivePerl.
For VMware, VMware Server 1 must be installed and running on the execute machine. HTCondor also supports using VMware Workstation and VMware Player, version 5. Earlier versions of these products may also work. HTCondor will attempt to automatically discern which VMware product is installed. If using Player, also install the VIX API, which is freely available from VMware.
For Xen, there are three things that must exist on an execute machine to fully support vm universe jobs.
For KVM, there are two things that must exist on an execute machine to fully support vm universe jobs.
Configuration is required to enable the execution of vm universe jobs. The type of virtual machine that is installed on the execute machine must be specified with the VM_TYPE variable. For now, only one type can be utilized per machine. For instance, the following tells HTCondor to use VMware:
The location of the condor_vm-gahp and its log file must also be specified on the execute machine. On a Windows installation, these options would look like this:
To use VMware, identify the location of the Perl executable on the execute machine. In most cases, the default value should suffice:
This, of course, assumes the Perl executable is in the path of the condor_master daemon. If this is not the case, then a full path to the Perl executable will be required.
If using VMware Player, which does not support snapshots, configure the START expression to reject jobs which require snapshots. These are jobs that do not have vmware_snapshot_disk set to False. Here is an example modification to the START expression.
The final required configuration is the location of the VMware control script used by the condor_vm-gahp on the execute machine to talk to the virtual machine hypervisor. It is located in HTCondor’s sbin directory:
Note that an execute machine’s EXECUTE variable should not contain any symbolic links in its path, if the machine is configured to run VMware vm universe jobs. Strange behavior has been noted when HTCondor tries to run a vm universe VMware job using a path to a VMX file that contains a symbolic link. An example of an error message that may appear in such a job’s event log:
To work around this problem:
Once the configuration options have been set, restart the condor_startd daemon on that host. For example:
The condor_startd daemon takes a few moments to exercise the VM capabilities of the condor_vm-gahp, query its properties, and then advertise the machine to the pool as VM-capable. If the set up succeeded, then condor_status will reveal that the host is now VM-capable by printing the VM type and the version number:
After a suitable amount of time, if this command does not give any output, then the condor_vm-gahp is having difficulty executing the VM software. The exact cause of the problem depends on the details of the VM, the local installation, and a variety of other factors. We can offer only limited advice on these matters:
For Xen and KVM, the vm universe is only available when root starts HTCondor. This is a restriction currently imposed because root privileges are required to create a virtual machine on top of a Xen-enabled kernel. Specifically, root is needed to properly use the libvirt utility that controls creation and management of Xen and KVM guest virtual machines. This restriction may be lifted in future versions, depending on features provided by the underlying tool libvirt.
If a vm universe job should fail to launch, HTCondor will attempt to distinguish between a problem with the user’s job description, and a problem with the virtual machine infrastructure of the matched machine. If the problem is with the job, the job will go on hold with a reason explaining the problem. If the problem is with the virtual machine infrastructure, HTCondor will reschedule the job, and it will modify the machine ClassAd to prevent any other vm universe job from matching. vm universe configuration is not slot-specific, so this change is applied to all slots.
When the problem is with the virtual machine infrastructure, these machine ClassAd attributes are changed:
Since condor_submit adds HasVM == True to a vm universe job’s requirements, no further vm universe jobs will match.
Once any problems with the infrastructure are fixed, to change the machine ClassAd attributes such that the machine will once again match to vm universe jobs, an administrator has three options. All have the same effect of setting the machine ClassAd attributes to the correct values such that the machine will not reject matches for vm universe jobs.
The execution of a docker universe job causes the instantiation of a Docker container on an execute host.
The docker universe job is mapped to a vanilla universe job, and the submit description file must specify the submit command docker_image to identify the Docker image. The job’s requirement ClassAd attribute is automatically appended, such that the job will only match with an execute machine that has Docker installed.
The Docker service must be pre-installed on each execute machine that can execute a docker universe job. Upon start up of the condor_startd daemon, the capability of the execute machine to run docker universe jobs is probed, and the machine ClassAd attribute HasDocker is advertised for a machine that is capable of running Docker universe jobs.
When a docker universe job is matched with a Docker-capable execute machine, HTCondor invokes the Docker CLI to instantiate the image-specific container. The job’s scratch directory tree is mounted as a Docker volume. When the job completes, is put on hold, or is evicted, the container is removed.
An administrator of a machine can optionally make additional directories on the host machine readable and writable by a running container. To do this, the admin must first give an HTCondor name to each directory with the DOCKER_VOLUMES parameter. Then, each volume must be configured with the path on the host OS with the DOCKER_VOLUME_DIR_XXX parameter. Finally, the parameter DOCKER_MOUNT_VOLUMES tells HTCondor which of these directories to always mount onto containers running on this machine.
For example,
The condor_startd will advertise which docker volumes it has available for mounting with the machine attributes HasDockerVolumeSOME_NAME = true so that jobs can match to machines with volumes they need.
Optionally, if the directory name is two directories, separated by a colon, the first directory is the name on the host machine, and the second is the value inside the container. If a ":ro" is specified after the second directory name, the volume will be mounted read-only inside the container.
These directories will be bind-mounted unconditionally inside the container. If an administrator wants to bind mount a directory only for some jobs, perhaps only those submitted by some trusted user, the setting DOCKER_VOLUME_DIR_xxx_MOUNT_IF may be used. This is a class ad expression, evaluated in the context of the job ad and the machine ad. Only when it evaluted to TRUE, is the volume mounted. Extending the above example,
In this case, the directory /path1 will get mounted inside the container only for jobs owned by user "smith", and who set +WantSomeDirMounted = true in their submit file.
In addition to installing the Docker service, the single configuration variable DOCKER must be set. It defines the location of the Docker CLI and can also specify that the condor_starter daemon has been given a password-less sudo permission to start the container as root. Details of the DOCKER configuration variable are in section 3.5.8.
Docker must be installed as root by following these steps on an Enterprise Linux machine.
The output of this command line for a correctly-installed and docker-capable execute host will be similar to
By default, HTCondor will keep the 20 most recently used Docker images on the local machine. This number may be controlled with the configuration variable DOCKER_IMAGE_CACHE_SIZE , to increase or decrease the number of images, and the corresponding disk space, used by Docker.
By default, Docker containers will be run with all rootly capabilties dropped, and with setuid and setgid binaries disabled, for security reasons. If you need to run containers with root privilige, you may set the configuration parameter DOCKER_DROP_ALL_CAPABILITIES to an expression that evalutes to false. This expression is evaluted in the context of the machine ad (my) and the job ad (target).
Docker universe jobs may fail to start on certain Linux machines when SELinux is enabled. The symptom is a permission denied error when reading or executing from the condor scratch directory. To fix this problem, an administrator will need to run the following command as root on the execute directories for all the startd machines: