Moving production Cloud License Service (CLS) Server Between Virtual Groups

Virtual GPU Forums General Discussion
1

Hi everyone,

I’m looking for a quick sanity check on our planned migration process to make sure we don’t inadvertently disrupt active user sessions or running simulation jobs.

Current Setup & Challenge

  • Environment: VMware Horizon Instant Clones (volatile pool) running CUDA/compute workloads (students/researchers leave jobs running overnight).

  • Licensing: NVIDIA License System (NLS) using a Cloud License Service (CLS) instance (name: serverA).

  • Situation: We recently structured our portal into distinct Virtual Groups (Team 1. Team 2, et). serverAcurrently lives in the default root organization level, and we need to move it into the Team 1 Virtual Group.

Because our Instant Clone pool is constantly spinning up/tearing down VMs and requesting leases on the fly, I want to execute this move with zero user disruption.

Our Planned Maintenance Process (Scheduled for Midnight)

  1. Disable the Server: Temporarily disable/stop check-outs on the **serverA**CLS server via the NVIDIA Licensing Portal.

  2. Release / Clear Leases: Release all existing leases to return licenses back to the server.

  3. Move Server: Use the native “Move License Server” feature under License Servers > Actions to transfer serverAinto the Team 1 Virtual Group.

  4. Re-Enable Server: Re-enable serverAunder the new Virtual Group.

  5. Client Tokens: Keep existing VM client configuration tokens (.tok) as-is.

Questions for the Community

  1. Active Workloads / Grace Period: Am I correct in assuming that active VMs running overnight jobs won’t fail or drop CUDA workloads during this 10–15 minute maintenance window? (My understanding is that existing client machines hold a cached lease, and even if a lease check fails during the maintenance window, the 7-day grace period ensures compute jobs continue unhindered.)

  2. Token Continuity: Since we are moving the existing CLS server (rather than building a fresh one from scratch), can anyone confirm that Instant Clones will successfully renew their leases against serverAin the new Virtual Group without needing a regenerated .tok file pushed to the master image?

  3. Gotchas: Are there any known caveats when moving a CLS instance that has active volatile pools constantly querying it?

Appreciate any insights or validation from anyone who has done a Virtual Group migration under live production!

Thanks in advance.

2

I’d be most cautious about the active leases and the token continuity rather than the actual Virtual Group move.

For a production migration like this, I’d first test the same sequence in a small clone pool: stop new check-outs, let existing leases reach a safe state, move the CLS server, and then verify that the clients can renew normally against the server in its new group.

I’d also keep the rollback path ready before the maintenance window. If the existing .tok configuration continues to work as expected, that should remove one major variable from the migration.

For the overnight workloads, I’d avoid assuming the grace period alone guarantees uninterrupted CUDA jobs. A quick validation with an active lease during the test migration would give you a much safer answer.

I’d be interested to hear what NVIDIA support or anyone who has done this exact CLS-to-Virtual-Group move says about the active lease behavior.

3

Thanks Casey. That’s exactly the area I’m concerned about.

The token isn’t a huge issue. If it needs to be regenerated, that’s easy enough to do. I was mainly curious whether anyone knows if this is actually necessary, given that I’m not building a new server, but simply moving the existing one to another Virtual Group.

Unfortunately, our situation makes the suggested isolated test difficult. serverA is our single production CLS instance and is shared by all of our Horizon pools, so moving it isn’t something I can test against a small pool without affecting the other pools as well.

I also don’t have a known CUDA workload that I can safely trigger for testing. The VMs are used by other teams and the CUDA workloads are essentially user applications that we don’t control.

I can validate the NVIDIA client/driver licensing state and lease behaviour from the VDI side, but I’m particularly looking for confirmation of what happens to existing leases when the CLS server itself is moved between Virtual Groups, and whether the existing .tok remains valid.

One other possibility I’ve been considering is whether the safest migration approach may actually be to avoid deliberately clearing the existing leases.

For example, could the migration effectively work like this:

  1. Move the existing serverA CLS server into the new Virtual Group.
  2. Currently available/unleased licences move across with the server immediately.
  3. Existing clients retain their current leases.
  4. As those leases naturally expire or are returned, the licences become available through serverA, which is now in the new Virtual Group.

If that’s how NLS handles a Virtual Group migration, that would seem considerably safer than forcibly releasing all existing leases, particularly given that we have long-running CUDA workloads that we don’t control.

I’m particularly interested in whether there’s any reason not to take this approach. If existing leases remain valid across the move and the server retains the same identity, allowing the leases to naturally age out would seem to minimise the risk to active workloads while allowing the licensing pool to transition to the new Virtual Group.

If anyone from NVIDIA can confirm the expected behaviour of existing active leases, available entitlements, and client .tok files during a Move License Server operation, that would give me much more confidence before I touch the production server.

4

I went ahead with the migration last night, following NVIDIA’s documented procedure for Moving a License Server to Another Virtual Group.

The migration was successful, and I can now provide some real-world confirmation of the behaviour I was asking about.

Results

  • serverA was successfully moved from the default/root Virtual Group into the new Virtual Group.
  • Approximately 500 existing VMs were actively utilising NVIDIA licences at the time of the move.
  • All existing VMs continued to operate without any noticeable interruption.
  • New Horizon Instant Clones were subsequently created and successfully acquired NVIDIA licences.
  • The existing client .tok token remained valid. No token regeneration or change to the master image was required.
  • The CLS server retained the expected functionality after the move.

There was one brief moment of panic immediately after the move, when serverA appeared to have completely disappeared from the NVIDIA Licensing Portal. It took me about 5–10 minutes to realise that I was still viewing the original Virtual Group. Once I changed the Virtual Group selector in the top-right of the portal to the new group, the server was right where it was expected to be.

So, based on this production migration, I can confirm that moving an existing CLS license server between Virtual Groups did not disrupt existing active leases, and existing client tokens continued to work for new Instant Clones.

Hopefully this is useful to anyone else who comes across the same question in the future.