Configure a license master

This topic discusses configuring a Splunk Enterprise instance as a license master (LM.) Before you proceed, review the topic Allocate license volume for general information about allocating license volume across Splunk Enterprise instances.

If you have a single Splunk Enterprise instance, it serves as its own LM once you install an Enterprise license on it. You do not need to further configure it as a license master.

If you have multiple Splunk Enterprise instances, you'll want to manage their license access from a central location.To do this, you must configure one instance as the LM. You then configure each of the remaining Splunk Enterprise instances as license slaves to the LM.

Choose the instance to serve as the license master

The license master (LM) does not usually need to run on a dedicated Splunk Enterprise instance. Instead, you can colocate it on an instance that is also performing other tasks:

A monitoring console. See Which instance should host the console? in Monitoring Splunk Enterprise for a description of the circumstances under which a monitoring console and a license master can colocate.
A deployment server. See Deployment server and other roles in Updating Splunk Enterprise Instances for a description of the circumstances under which a deployment server and a license master can colocate.
An indexer cluster master node. See Additional roles for the master node in Managing Indexers and Clusters of Indexers for a description of the circumstances under which an indexer cluster master node and a license master can colocate.
A search head cluster deployer. See Deployer requirements in Distributed Search.
A search head.
An indexer. If the license master is located on an indexer, it will be that indexer's license master as well.

For a general discussion of management component colocation, see Components that help to manage your deployment in the Distributed Deployment Manual.

License master and slave version compatibility

A license master (LM) must be an equal or higher version than its license slaves.

For example:

A 8.0 LM is compatible with 7.1, 7.2, 7.3, and 8.0 slaves.
A 7.2 LM is compatible with 7.0, 7.1, and 7.2 slaves.

Compatibility is significant at the major/minor release level, but not at the maintenance level. For example, a 7.2 LM is not compatible with a 7.3 license slave, because the 7.2 is a lower minor release level than 7.3. However, a 7.3.1 LM is compatible with a 7.3.3 license slave, despite the lower maintenance release level of the LM.