Don't ignore reason #2. That really happens. Try it now. You'll see. And no, deactivating the activations constantly is not the solution. The solution is TurboFloat: https://wyday.com/limelm/help/licensing-types/#floating
VM activation in EC2
Hi,
I have my product on EC2. In the help pages I see there are 2 reasons mentioned for disallowing VM activations:1. The customer can copy the virtual machine instance to another computer2. On reboot, the VM instance is started on a different underlying physical machine, and thus the "computer fingerprint" changes.
If we ignore the 2nd reason, is the 1st reason a thing to worry in EC2 instances? Would it be possible to do bit-for-bit copy of a fully configured EC2 instance?
I think the 2nd reason can be tackled by deactivating using the Web APIs though I have not yet looked into all the aspects of it.
Yes, I understand it happens and I have seen it during Dev. Our released product is actually meant to run continuously for months without reboot. So, a reboot generally doesn't happen often. It happens when it is really required.
We're considering TurboFloat. For that we need to know, is the 1st point possible in AWS. Is it possible for an EC2 instance being copied bit-for-bit ?
Not currently, no. Not to our knowledge.
This might change.
Don't run TFS instances on EC2. Don't run TFS on VMs of any kind. Run them are physical hardware, or, when we release our hosted versions of the TFS use that.
>> "Our released product is actually meant to run continuously for months without reboot"
Every time they reboot they will be forced to re-activate. This creates a support load for yourselves that is avoidable. And this is not something you should automate (because it will be abused and customers will be able to get free licenses).
>> And this is not something you should automate (because it will be abused and customers will be able to get free licenses)
I do not get how it can be abused. I plan to use only Online Activation/Deactivation. There won't be offline option. Do you still think it can be abused? Can you explain?
The solution to this problem is TurboFloat: https://wyday.com/limelm/help/vm-hypervisor-licensing/
Automating the deactivation of an end-user using the web API means that any user can deactivate from anywhere and unlimited number of times. Thereby eliminating the purpose of node locked licensing.
For real machines: use TurboActivate or TurboFloat.
For VMs: use TurboFloat, never use TurboActivate.
I understand the problem of using the Web API for deactivations. That's why I have in mind to use the TurboActivate API rather than the Web API. Is that still not recommended? If so, why?
>> "That's why I have in mind to use the TurboActivate API rather than the Web API."
If you've activated on a machine and then you call TA_Deactivate() -- or the offline deactivation -- then everything will work fine. If you've activated on the machine and then transferred that activation data to another machine, the deactivation will fail. That's by design.
Using TurboActivate on a VM is using TurboActivate on multiple machines.
There's a solution to this problem (stated multiple times in this thread, multiple times in other threads, and in our documentation).
On real machines: use either TurboActivate or TurboFloat depending on your needs.
On VMs: only use TurboFloat. Never use TurboActivate.
https://wyday.com/limelm/help/vm-hypervisor-licensing/