We've all had times when we've needed to migrate from one license server to another. You've rehosted a license daemon to a newer, faster machine and you're excited to put the old one (fully amortized, as the accountants say) to rest. But there's one, pesky little detail that you have to put up with.
The old machine is still in production.
Normally, suppliers are kind enough to give you a couple of weeks overlap for transition. How you manage that time is crucial in achieving your goal and maintaining compliance to the spirit of your license agreement. After all, you *technically* are running twice as many licenses as you should for this one server.
Ideally, what you would like is for anyone with an existing checkout to be able to complete their run, but once they have checked that license back in, they can't check a new one out. Fortunately, you can do precisely that. It's actually quite simple, but it involves doing something that most of us either don't use or don't trust -- lmreread.
Step 1: Reserve All Features To A Dummy User
You'll want to pick and administrative user or some user you know would never expect to use these licenses. In our super complicated example, we're going to pick the username "reserved".
Let's say that you have 100 Simulator licenses. To reserve all of them, edit your options file and use this syntax:
RESERVE 100 Simulator USER reserved
Save your options file off and you are ready, even though the license server is up, running and in full production.
Before we do anything, let's check out the usage on the server:
Vendor daemon status (on server1):
vendorld: UP v11.14.0
Feature usage info:
Users of Simulator: (Total of 100 licenses issued; Total of 50 licenses in use)
"Simulator" v2017.12, vendor: vendorld, expiry: 26-jan-2022
floating license
dmagill server1 /dev/pts/0 (v1.0) (server1/27600 102), start Mon 4/30 21:05, 50 licenses
Sure enough, that trouble-maker dmagill is hogging half of the licenses! Tempting though it may be, you can't simply kill the daemon and knock him off. He's doing important work that needs to complete. So now that we have our options file set, on to the next step.
Step 2: Run lmreread
I know, I know. Several prominent vendors have in their documentation not to do this. You may have been burned by it in the past. You may yet be burned with it in the future. You definitely should not re-read several times a day in a cron job. But this is a one-off thing, and it's going to be fine. At this point, you simply need to issue this command:
bin/lmreread -c license_file -all
You will see the daemon think about it for a moment, and then it should return with this:
lmreread - Copyright (c) 1989-2016 Flexera Software LLC. All Rights Reserved.
lmreread successful
Now here is the truly interesting part. Run an lmstat again and you will see this:
Users of Simulator: (Total of 100 licenses issued; Total of 150 licenses in use)
100 RESERVATIONs for USER reserved (server1/27600)
Woah! What happened here! We have 100 licenses, but now we're using 150! You're really not using more than you have, but the reservation coupled with the live re-read is causing the output to tell you that. And from here on out, what will happen is that as dmagill's jobs check in one by one, any new attempt at a checkout will result in a license denial. Eventually, you'll get down to this point:
server1: license server UP (MASTER) v11.14.0
Users of Simulator: (Total of 100 licenses issued; Total of 100 licenses in use)
Which is where you want to be. All of your licenses are now safely reserved for your reserved user, and you can safely shut down your old license server without ever having disturbed a running job. New jobs won't be able to go through, but that sure beats killing a multi-day run.
Caveats
As you can see, this was run on a fairly new daemon version. I've run this as far back as 11.11 at least, but I'll bet most "modern" daemons can handle it. However, buyer beware if you are on very old daemons.
This example also ran on a Linux server. Ostensibly Windows servers would behave similarly.
Once you do this, you have to make sure that no one re-starts the daemon. Once you kill the daemon, it loses all sense of state and when it comes up, it will know about the reservation before anyone has a chance to check out a license and you'll lose all those jobs if you don't catch it quickly enough.
If you have a particularly involved options file or if you just have a lot of features (let's say you have thousands of Simulator licenses), performance may degrade as the server has to traverse the list of "checkouts". I've run this on some fairly beefy servers and have still had some performance issues on extremely busy ones.
Conclusion
Migrating the last folks off of a license server doesn't have to be an exercise in futility -- for your end users or for you. You can even do it gracefully. But one thing is certain, once you get that new license file in, you must do it and do it as quickly as you are able to.