Global License Server problems

I searched the forum quickly but didn't find any similar problem, so here it is:

If there is a multiple VirtualCenters serving different regions (Americas, Europe, APAC) and only one License Server is used for all regions, how to avoid latency and connection problems between ESX Servers in a specific region and the global License Server? Is there any way to have multiple redundant License Servers serving globally?

Lets say that all regions have their own VirtualCenter with License Server to serve that reqions VMs, Hosts and licenses. One VC & LC will have all licenses needed in that region. That way the license check should be a lot faster. That would be the primary LC, but if the connection is failed then secondary, e.g. Europe LC would be used automatically and transparently.

There is something mentioned in VMware website (

Of course licenses can be split per region, but then the idea of having centralized license server is lost. How do you have solved this kind of VI3 setup?

Also any tips and tricks for this kind of setup is welcome.

0 Kudos
2 Replies

This is a little weird but it might work, so read it through:

Install a license server (with the SAME license) in each of your geographic areas. The license file should cover your global operation's needs.

Install a DNS server service on each of these license servers. The DNS server will serve the IP addresses of the license server on itself as well as the various regional license servers.

Configure each DNS server to provide name resolution for each of the regional license server names. For example: - A Record - Preference 10 - - A Record - Preference 20 - - A Record - Preference 30 -

Obviously, a DNS server would prefer itself (or more correctly, the license server running on it) for its local region.

Then, configure each ESX server in a region to point to its local DNS server first, and to the other regional DNS servers next. Use the FQDN of the license server when you configure the Server-Based License source so that DNS is required to resolve it. This way, if the local license server / DNS server goes down, it will try the next one.

The purpose of this exercise is to allow the failover nature of DNS to allow ESX servers to be directed towards alternate DNS servers (in our case, license servers too) in the event that the local license/DNS server goes down.

This solution does not provide a safeguard for just the license service failing (only the whole machine).

Does this make any sense? Weird, huh? Smiley Happy



Hi Paul,

Thanks for the idea and it makes sense.

I think VMware should make improvements in this area in the future. Anyone from VMware listening? :smileygrin:

Your idea with DNS priorities sounds good. This kind of "out of the box" thinking I was looking for. However VC with DNS servers sounds too risky and complicated environment. I would prefer as basic configuration as much in VC server. With big corporate environment, it might be quite tricky thing to build "rogue" DNS servers as there are many "company policies" to be followed.

The normal behavior of VC and licensing (see VMware Infrastructure 3 Licensing Frequently Asked Questions -, Chapter 4.3) is OK with environment that is stabilized, but new environment where new ESX Servers are coming every day and license request are made frequently, then the normal behavior is NOT OK.

In same chapter there is link to Macrovision ( ). That document suggests 1) "redundancy via license-file list" and 2) "three-server redundancy" and both are not OK.

1) "once a license job has successfully checked out a license from one host, all subsequent checkouts must be satisfied from the same host. If the application requires more than one license, this could result in a license denial when the license is available on another server."

\- What if connection failure comes between different checkouts?

2) "The three servers must be located physically close to each other. This form of redundancy requires that the servers exchange heartbeats periodically, and poor communications can cause poor performance."

\- This is just an opposite what I was looking for

0 Kudos