Hosts with mismatched CPUs, MAC addresses, and licensing

Starting in PureConnect 2020 R2, virtual cloud enforcement allows licensing support for virtual cloud environments that eliminates the need for a  host ID unique to the machine. Legacy licensing remains an option if you prefer. For more information about licensing, see PureConnect Licensing Technical Reference.

When using legacy licensing, you may encounter the following issues.

Common issue

When a license is generated for the CIC server, it requires a CPUID and the MAC address to generate a HOSTID. To ensure that the license will continue to function when a VM host becomes part of a cluster, the CPUID and MAC address must be managed.

The first component of the HOSTID, the CPUID, can be generalized so that guests can move from host to host in a cluster and maintain the same CPUID. If the CPU types are the same for all hosts in the cluster, the general CPUID is usually not problematic. VMware and Hyper-V both provide some mechanisms to accommodate a consistent CPUID when the hosts are not identical.

Important! Contact the virtualization software vendor if you need assistance in providing a consistent CPUID to guests in a cluster.  
Genesys is not responsible for the configuration and performance of your virtualization environment.

Warning! The second component of the HOSTID, the MAC address, must also be identical for the CIC server guest when run on a different host. Any changes to a virtual environment after you have generated the CIC server license will likely impact the license. For this reason, you must configure the virtual machine guest to have a static MAC address value.
Once you verify that your CPUID and MAC address do not change when the CIC server guest uses different hosts in the cluster, only then should you generate your CIC server license.

The following examples provide common scenarios that result in license issues when the CPUID or MAC address is not maintained across hosts:

Example #1: A customer added a host that was running the CIC server guest in a new host cluster, not realizing it would cause the CPUID to change.

Example #2: The guest running the CIC server guest does a VMotion or Live Migration onto a new server with a different dynamic MAC address pool. The customer had not configured a static MAC address because the MAC address had never changed in the previous environment.

Example #3: The host supporting a CIC server guest failed. The guest was restored on a new host. Even though clustering was not involved, the different CPU platform of the new host machine generated a different CPUID value that invalidated the CIC server license.

Important! Always test your resiliency strategy before putting CIC guest VMs into production. Ensure that the guests can move to different hosts in the cluster without causing a licensing issue.

Rare issue

A host should be running with the same version of sockets if it has more than one. It is possible to buy a server with one socket and then later upgrade the machine with another socket. The additional socket can cause a situation where the CIC license check fails because the stepping ID, for example, can be different even though the sockets appear to be the same model and clock speed.

The CPUID instruction used for processor identification is different from the CPU with which the license was originally generated. Migration of a virtual machine that is not part of a cluster to another host causes a licensing failure because the CPUID used for the HOSTID is different.