Q100221: How to float some of your RLM licenses from another server on your network



This article explains how you can use the RLM server's inbuilt transfer functionality to temporarily transfer a set of licenses from your main server to another machine on your network so they can be floated from there.

This can be useful if you are floating a large number of licenses and wish to balance the load between more than one server or if you want to keep a small number of licenses available for a group of users on a separate project in a remote office.
NOTE: This is not the same as requesting a permanent license transfer, the licenses are still tied to the original server which needs to keep running.  If you need to permanently move your licenses to a new server then please read Q100001: Can I transfer my license to another machine?


Floating all of your RLM licenses from a single server on your network will work well for the vast majority of license usage situations.  However, there may be some situations where you may want to use an additional license server on your network.
  • You want to use a small subset of your licenses for a project in a remote office that is connected to your main network
  • You have a very large number of licenses and would like to use another server to share the load of license requests to avoid over taxing your original server.
The good news is that the RLM license server included in the Foundry Licensing Tools (FLT) has the ability to "transfer" a number of its licences to another machine on the same network so they can be floated from there.  Essentially the second machine checks out a number of licenses from the original server and then acts as another license server on the network.

How to set up the transfer
Instructions on how to set this up are available in the RLM End User Guide under the 'Transferring Licenses to Another Server' heading.  Please note that one of the restrictions of this temporary transfer is that token licenses (which are used in Collective licenses) cannot be "transferred" to a destination server.
How to balance the load between two servers
If you want to use this functionality to balance the load on license requests between more than one server then you need to do the following:
  1. Set up the transfer using the instructions in the RLM End User Guide. For example you may want to transfer half of your render licenses to a second server.

  2. Instruct your client machines to look at both servers by either creating multiple client license files or by setting the following environment variable:

    Linux and OSX:


    (where "orginalServer" is the hostname or IP address of the main license server and "transferServer" is the hostname or IP address of the second transfer server)

  3. By default the client machines will contact the servers in the order that they appear in the foundry_LICENSE variable or that they find the client license files.  You can randomise which server is contacted first by setting another environment variable called RLM_PATH_RANDOMIZE, this should help balance the load of license requests between the original and transfer server.  The variable just needs to exist and have a value so you can set the following:


NOTE: The randomize environment variable will work well is a single user is launching a single session. If a user launches multiple sessions of the software from a single user this could lead to a situation where different instances on a machine query different servers, so end up pulling licenses from more than one server at a time.

Please see Q100015: How To Set Environment Variables for guidance on setting environment variables.

Alternatively you could set half of your client machines to look at the original server and half to look at the transfer server but the advantage of the setup above is that all the client machines can still look at the original server so they will still be able to get licenses when they are returned from the transfer server.

Note: Due to a bug in an old version of RLM, older builds of Nuke unset this variable and attempt to do its own randomization. You can work around this by updating to the newer build of the software.

    We're sorry to hear that

    Please tell us why