Problems with SW license in virtualized servers with Citect 2018

Hi Ana ,

Can you share a little more details about your Virtualization infrastructure? Are you running on VMWare ESXi or Hyper-V? What version?

There have been some changes within the FLM software since Citect 7.40 to now. These changes have included security fixes as well as making it more difficult to defeat license protection in virtualized environments. Unfortunately this has made the license more limited and restrictive in how you can manage your VMs.

The more recent versions of FLM have added protection, where several unique machine numbers (UMN) are bound to the license. If any of these UMN changes within the VM, the license becomes untrusted.

The three UMNs are:
UMN2 is derived directly from the MAC address
UMN3 VMWare: uuid.bios as defined in vmx file
UMN5 is derived from Microsoft Generation ID

Actions that will cause the Microsoft Generation ID (UMN5) to change include:
The virtual machine starts from a checkpoint.
The same checkpoint is applied multiple times.
The virtual machine is restored from a backup.
The virtual machine is migrated by using System Center 2012 - VMM (Export and Import).
The virtual machine is imported.

Actions that will not cause the Generation ID (UMN5) to change include:
The virtual machine is live-migrated.
The virtual machine is paused or resumed.
The virtual machine is restarted.
The Hyper-V host is restarted

Have a look at this whitepaper from Flexera for further details and scenarios:
https://community.flexera.com/xtqzp85664/attachments/xtqzp85664/FNP-Knowledge/375/1/FNP_WP%20Virtualization.pdf

I recommend you get in contact with AVEVA Support to go through the details of your exact scenario. There may be some solution they can share with you.

Kind regards
Olivier

I think the software license mechanism doesn't support the high available scenario described by Ana.
I believe the best will be to use USB dongle and USB-anywhere.

Hi,
Thanks for the information...the scenario that we are using is based in an Hyper-V virtual server (Second generation and with windows 2016 (mainly) and windows 2019) .
The structure is that we have 3 physical servers --> Supervisor, Node 1 and Node 2
And there is one virtual machine (hosting the SW license) that the supervisor decide in which node will run (if one fails, it moves the VM to the other node, but the virtual machine is the same, it is not stopped)

Antonio, you mean that this scenario is not longer supported??? It was before :(, and now this is a big issue for upgrading.

Maybe if we use an older flexera SW we can work??

Hi Ana ,
The scenario you described does sound like it should be supported. I am more familiar with VMWare ESXi, which this action is called a vMove. The VM is still running and is moved from one physical host to another. Can you describe the HDD infrastructure for your VM Host? Is it a SAN, shared storage between the physical servers?
To really diagnose what is going on, you would need to enable some additional logging for Floating License Manager, to understand what UMNs are chaning, which is causing it to become untrusted. If I had to guess what is causing it, I would assume it is UMN5, which is the Microsoft generated ID, which appears to be quite brittle.
I think Antonio also made a good suggestion, as this is proven to be really reliable and support many more VM scenarios (copy/snapshot/backup/restore, etc...) without making the license become untrusted.
I'd recommend reaching out to AVEVA support if you want to investigate the Floating License Manager logging enabled.
Kind regards
Olivier

Hi!
Just to end this thread, we finally found the problem and the solution...by default Hyper-V virtual machine uses Dynamic MAC addresses for the network interfaces and this was causing changes that the license was seeing as a change in HW, and became untrusted.
Now after changing to static addressing everything work fine!
Thanks Oliver for the clue :)

Hi Ana / Oliver / Antonio

Im facing the same problem, even setting the Dynamic MAC of the network interface as a Static... we have several redundant systems over Hyper-V, and when we start the replica... Citect stops, license appears to be untrusted and needs to be repaired.
Ana, Any more settings to be addressed prior this?... what ive been doing is setting VMs, servers and clients, licensing and then, activate the replica in the other hyper-v server. Once i try a failover, the replica starts and doesnt work. I put the static feature in the advance network interface feature.

thanks for any help...

Hi Diego,

Are you sure you are describing the same scenario? Restoring backups or making replicas is probably not supported and will change the Microsoft generated ID which breaks the license. Do you also have a supervisor and two node machines in your setup?
If not, you might consider using USB-licenses and a USB-Anywhere hub, like Antonio described.

Hi,
I think this is not the same scenario that I have, I'm sorry but I think I cannot help you.
BR