# Multiple Slaves On One Machine¶

## Overview¶

Deadline has the ability to launch and configure an arbitrary number of Slave instances on a single machine. Each Slave instance can be given a unique name, and can be assigned its own list of Pools and Groups, which allows Slaves to work independently on separate Jobs. A single high-performance machine could potentially process multiple 3D, compositing, and simulation Jobs simultaneously.

Note that the configurations for these slave instances are stored locally on the slave machine. This means that these slave instances exist independently from the repository that the slaves connect to. So if you delete a slave from the repository, the local configuration for that slave instance still exists. Conversely, if you delete a local slave instance, the slave will still have an entry in the repository. It is possible to remove both the slave from the repository and the local slave instance from the slave machine, which is covered below.

## Licensing¶

In Deadline 7, all Slave instances running on a single operating system (physical or virtual) will use the same license. For example, if you had 3 slave instances running on one operating system, they would only use 1 license.

There are three ways to launch new slave instances:

• From the Launcher menu by selecting Launch Slave By Name -> New Slave Instance. This is disabled by default, but can be enabled in the User Group Management settings.

• From the right-click menu in the Slave list in the Monitor by selecting Remote Control -> Slave Commands -> Start New Slave Instance. By default, this is only available when in Super User Mode.

• From the command line using the -name option.

deadlineslave -name "instance-01"


deadlineslave -name "instance-01" -nogui


Note that the name you enter is the postfix that is appended to the slave’s base name. For example, if the slave’s base name is “Render-02”, and you start a new instance on it called “instance-01”, the full name for that slave instance will be “Render-02-instance-01”. This is done so that if the slave’s machine name is changed, the full slave name will be updated accordingly. Using the same example, if the machine was renamed to “Node-05”, the slave instance will now be called “Node-05-instance-01”.

Once the new Slave shows up in the Slave List in the Monitor, you can configure it like any other Slave. You might want to use Slave Settings (see Slave Configuration) to assign the different Slaves to run on separate CPUs. It might also be a good idea to assign them to different Pools and Groups, so that they can work on different types of Jobs to avoid competing for the same resource (e.g., you could have one Slave assigned to CPU intensive Jobs, while the other works on RAM intensive ones).

Once the Slave has been created, you can also launch it remotely like you would any other Slave. See the Remote Control documentation for more information.

## Removing Slaves¶

There are three ways to remove existing slave instances:

• From the Launcher menu by selecting Launch Slave By Name -> Remove Slave Instances. This is disabled by default, but can be enabled in the User Group Management settings.

• From the right-click menu in the Slave list in the Monitor by selecting Remote Control -> Slave Commands -> Remove Slave Instance. This method gives the additional option to automatically remove the slave instance from the repository as well. By default, this is only available when in Super User Mode. Note, the slave must be disabled or offline before this option will be visible in the right-click menu.

• Manually delete the .ini files that define the local slaves instances on the machine that the slave runs on. See the Client Configuration documentation for more information.

## Limiting and Disabling Multiple Slaves¶

By default, users do not have the ability to launch additional Slaves on their own machines (see User Group Management). However, there are some cases where you might want to completely disable the ability to run multiple slaves on the same machine.

The only known situation where this might be necessary is if your render nodes all net-boot off the same installation (meaning they share the same file system). In this case, if multiple Slaves are enabled, each render node will end up trying to run a Slave instance for every other render node net-booting off the same installation.

In this scenario, you can disable the multi-slave feature by opening the system’s deadline.ini file and adding this line:

MultipleSlavesEnabled=False


The system deadline.ini file can be found in the following locations. Note that the [VERSION] in the path will change based on the Deadline version number.