Summary

GibbsCAM Network License (NLO) servers can be deployed in certain virtual machine (VM) environments. However, virtualization support depends on the type of Network License being used and whether the virtual environment can reliably present the required licensing hardware.

This article explains the supported configurations, important limitations, and best practices when deploying a GibbsCAM Network License Server in a virtual environment.

TABLE OF CONTENTS

Supported Virtual Environments

GibbsCAM Network License Servers may be deployed in many common virtualization platforms, including:

  • VMware vSphere / ESXi

  • Microsoft Hyper-V

  • Microsoft Azure Virtual Machines

  • Nutanix AHV

  • Proxmox VE

  • Other enterprise virtualization platforms

Support depends on the licensing method and the ability of the virtual machine to satisfy the licensing requirements.

Keyless Network Licenses

Keyless Network Licenses are locked to the hardware configuration of the license server.

Because virtual machine hardware identifiers may change after certain administrative operations (such as migration, cloning, or rebuilding a VM), moving or recreating a virtual machine may require the license to be reissued.

Before moving a keyless license to a new virtual server, contact GibbsCAM Customer Service or your authorized reseller.

Hardware Key (USB) Network Licenses

Hardware key (USB) Network Licenses are generally the preferred option for virtual environments as it locks to the hardware key and not machine identifiers.

To use a hardware key in a virtual machine:

  • The virtualization platform must support USB passthrough or USB device redirection.

  • The USB hardware key must remain connected whenever the Network License Server is running.

  • The hardware key drivers must be installed on the virtual machine.

If the virtualization platform does not support reliable USB passthrough, the hardware key may not be detected correctly.

Virtual Machine Snapshots

Exercise caution when using virtual machine snapshots.

Restoring a snapshot may:

  • Change hardware identifiers.

  • Revert licensing configuration.

  • Restore outdated license files.

  • Cause the license service to stop unexpectedly.

If snapshots are part of your backup strategy, verify that the license server continues to operate correctly after restoring a snapshot.

Cloning Virtual Machines

Do not clone a configured Network License Server for production use.

Cloning may result in:

  • Duplicate machine identifiers.

  • Invalid licensing information.

  • License activation failures.

  • Multiple servers attempting to use the same license.

Always perform a fresh installation on a new virtual machine.

Live Migration

Features such as VMware vMotion or Hyper-V Live Migration are generally transparent to GibbsCAM, provided that:

  • The virtual hardware identifiers remain unchanged.

  • Network connectivity is maintained.

  • The USB hardware key (if used) remains available to the virtual machine.

After migration, verify that client workstations can still obtain licenses.

Backup and Disaster Recovery

Regularly back up:

  • License files (.lic)

  • Configuration files

  • RLM settings

  • Documentation containing your Product Code

Backing up these files can simplify recovery after hardware failures or VM rebuilds.

Best Practices

For the most reliable virtual deployment:

  • Use a static hostname.

  • Assign a static IP address.

  • Keep regular backups of the license files.

  • Install Windows updates during scheduled maintenance windows.

  • Verify client connectivity after any VM migration or restoration.

  • Avoid unnecessary changes to the virtual hardware configuration.

Known Limitations

Virtual environments may experience licensing issues if:

  • Virtual hardware identifiers change.

  • USB passthrough is interrupted.

  • Network adapters are replaced or reconfigured.

  • The VM is cloned instead of freshly installed.

  • Snapshots restore an outdated licensing state.

If any of these conditions occur, the Network License may require reactivation.

Cloud Server Support

Hosting the NLO server in the cloud is technically possible, but the environment must provide reliable network connectivity and meet the licensing requirements.  Latency, VPN connectivity, firewall rules, and USB hardware key support (if applicable) can all affect deployment. 

Troubleshooting

Problem: The Hardware Key Is Not Detected

Possible Causes

  • USB passthrough is disabled.

  • Hardware key drivers are not installed.

  • The USB device is attached to the host instead of the virtual machine.

Resolution

Verify that the USB hardware key is assigned to the virtual machine and install the latest hardware key drivers.


Problem: Clients Cannot Obtain Licenses After VM Migration

Possible Causes

  • Network configuration changed.

  • Firewall rules were modified.

  • License service did not restart.

Resolution

Verify the GibbsRLMServer service is running and confirm that clients can communicate with the server.


Problem: License Stops Working After Restoring a Snapshot

Cause

The restored snapshot contains outdated licensing information or altered hardware identifiers.

Resolution

Verify the license configuration and, if necessary, contact CAMCO to determine whether a new license must be issued.


Problem: The Virtual Machine Was Cloned

Cause

Cloning changes the environment used for licensing.

Resolution

Install the Network License Server on a new virtual machine rather than using a cloned image.

Expected Result

The GibbsCAM Network License Server operates reliably within the supported virtual environment, and client workstations can successfully obtain licenses.

Related Articles

Keywords

Virtual Server, Virtual Machine, VMware, Hyper-V, Azure, Virtualization, Network License, NLO, RLM, Reprise License Manager, USB Passthrough, Hardware Key, Keyless License, License Server, Virtual Environment