• Replies 8 replies
  • Subscribers 583 subscribers
  • Views 290 views
  • Users 0 members are here
Options
Related

Problems with SW license in virtualized servers with Citect 2018

Ana

Hi,

We are migrating our systems from Citect 7.40 to Citect 2018 (with the license upgrade to version 8.20) and we are facing a lot of problems in the virtualized scenarios, where we have redundant HW and a unique virtual machine that runs on one or the other depending on the avalability of them.

So, when the virtual machine changes from one node to the other, the license doesn't work anymore, it appears in a untrusted state and we need to reactivate it...so we are losing the redundancy.

It seem that some policies in the licenses have change, but is there a solution for this problem?

Thanks  

Parents
  • Hi ,
    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 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
Reply
  • Hi ,
    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 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
Children
No Data
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.