The following provides a more trechnical discussion of the various license types we offer. Please feel free to call us with any questions.
A named-user license allows one person to use Gurobi on one machine. That one named user can run as many Gurobi jobs as they like on the licensed machine, and each job can launch as many threads as there are cores in the machine.
If you look at the contents of your gurobi.lic file, you will see two lines that indicate that you have a named-user license:
The TYPE=NODE line indicates that this license is tied to a particular machine. The USERNAME= line gives the user name of the person who is licensed to use Gurobi on this machine.
An unlimited-user license allows any user on the licensed machine to run Gurobi on that machine. Users can run as many Gurobi jobs as they like on the licensed machine, and each job can launch as many threads as there are cores in the machine.
If you look at the contents of your gurobi.lic file, an unlimited-user license can be recognized by the presence of one line:
...and by the absence of another:
The TYPE=NODE line indicates that this license is tied to a particular machine. If no USERNAME= line is present, then any user can run Gurobi jobs on that machine.
A Compute Server license allows client machines to submit jobs to the licensed server. The number of clients is unlimited. The number of simultaneous jobs allowed on the server is user-configurable.
You must start Gurobi Compute Services on the server machine before Compute Server will accept jobs from clients. Instructions for doing so can be found in the Gurobi Quick Start Guide.
If you look at the contents of your gurobi.lic file, a Compute Server license can be recognized by the presence of two lines:
The TYPE=NODE line indicates that this license is tied to a particular machine. The CSENABLED=1 line indicates that the licensed machine may act as a compute server.
Clients must be instructed how to reach a compute server. This is usually done using a client license file, which typically consists of a single line:
An additional PASSWORD= line is required if your Compute Servers have been configured to use a password. You create client license files yourself. You can refer to the Compute Server using its name (e.g., myserver.mydomain.com) or its IP address (e.g., 192.168.1.100).
Please refer to the Compute Server section of the Reference Manual for more information on configuring or using a Compute Server.
A floating-use license allows a specified maximum number of simultaneous uses of Gurobi from machines on the same network as the machine that is running the Gurobi token server.
Gurobi uses are tied to Gurobi environments. When a program creates an environment, a token is checked out, and that token can't be used by another program until the environment is destroyed (using GRBfreeenv in C, the GRBEnv destructor in C++, GRBEnv.dispose in Java, and GRBEnv.Dispose in .NET).
One thing that we should note about token licenses is that there is overhead associated with checking a token in and out. If you are writing a program that solves many small models in succession, we strongly recommend that you create a single Gurobi environment, and reuse it for all of the models you solve within the same program.
If you look at the contents of your gurobi.lic file, you will see two lines that indicate that you have a floating license:
The TYPE=TOKEN line indicates that this license uses the Gurobi token server. The USELIMIT= line indicates the number of simultaneous uses that are allowed.
To use a floating license, you must first start the Gurobi token server. Instructions for doing so can be found in the Gurobi Quick Start Guide. Once the token server is started, you can check out a token from any machine on the same network. Clients of the token server must have a gurobi.lic file that points to the token server. That file should contain a single line:
You can create this license file yourself. You simply need to provide the name of the machine that is running the token server. You can refer to the token server machine using its name (e.g., myserver.mydomain.com) or its IP address (e.g., 192.168.1.100).
Any of the licenses listed above can be used on a virtual machine (VM). The capabilities of a particular license type will be comparable, whether it is installed on a physical machine or a virtual machine. Thus, for example, a single-use license installed on a VM will still allow one use of Gurobi at a time, on that VM. The Gurobi license will be tied to a particular VM instance, so the license will continue to function even if you migrate the VM from one host machine to another. VM environments do present a few special considerations that require further discussion, though.
One question that often arises in connection with virtual machines is whether the licensing process differs for virtual and physical machines. The quick answer is that, with only a few exceptions, it doesn't differ. You install the license on the virtual machine in the same way that you'd install it on a physical machine. The contents of the gurobi.lic file are the same as well (you can refer to the previous License File Information discussions for detailed information on each type of license file).
One complication that arises in a virtual machine environment relates to counting CPU sockets for a server license. Recall that we license by the CPU socket, not by the core. Unfortunately, virtualization systems pretend that every core is its own CPU. Thus, for example, if you allocate 4 cores to your virtual machine, the VM system will tell our licensing that the machine has 4 CPU sockets. That would normally require a more expensive license than you'd need if, for example, you licensed Gurobi on the physical machine that hosts that VM. We handle this issue by asking people who run server license on virtual machines to tell us the type of CPU chip in the host machine. If your host CPU has 4 cores, we'll configure your license so that a single-CPU server license will allow you to use up to 4 cores on the virtual machine.
Another complication in a virtual machine environment relates to VM migration. While most virtualization systems will leave identifying host information unchanged when a machine is shut down and later restarted, or when a machine migrates from one host to another, a few will give the machine a new host ID. This invalidates any Gurobi licenses that are tied to the original host information. Fortunately, this isn't common; so far, it has only come up on Amazon EC2. If you'd like to use Gurobi on your own Amazon EC2 instance, please call us to discuss options.
One usage scenario that sometimes arises in a virtual machine environment is hosting a number of virtual machines that all use Gurobi on the same physical host machine. One option in this case is to purchase a license for each VM. However, we also offer a license type that can be more cost-effective in such environments. A Virtual Machine Host License allows you use Gurobi on as many virtual machines as you would like, provided that they are all hosted on the same physical machine.