Running TurboFloatServer on VM

Good morning, we have a customer who is running the TurboFloatServer (and also all his other license servers) on a VM. Usually this is fine, but every now and then he gets an error of that kind (<error>: Not activated (error code: 0x3). You must activate this TurboFloat Server via commandline like this:) and we have to remote-deactivate the license for them and they have to start over with uninstalling the service, activating the license and installing the service again. Any suggestions why this happens and how we can avoid it?Cheers, Alice

Hey Alice,

Don't install the TurboFloat Server on a Virtual Machine, container, or hypervisor. Always run it on a real machine. We're going to explicitly warn about this directly in the LimeLM interface soon.

But we cover this in our documentation: https://wyday.com/limelm/help/vm-hypervisor-licensing/

https://wyday.com/limelm/help/licensing-types/#floating

Your app, using the TurboFloat library, *can* be run on a VM (or container or hypervisor). It's just the TurboFloat Server that *can never* be run on a VM.

FYI: I get many many requests nowadays from major facilities that want to run a license server on a VM that is dongle-less.Not sure what they are using for other software already, but I get asked this a lot lately. We still use USB CodeMeter CmSticks for floating licensing but I'd like to move away from them, but just seems like a security risk with dongle-less on a VM to me cuz this places wouldn't allow an internet check and you could just duplicate the VM to get free licenses.

Anyway...looks like TurboFloat shouldn't be used in this way and understandably also.

Never run the TurboFloat Sever on a VM. Your app, using the TurboFloat Library, can run on VMs, Hypervisors, containers, etc., etc., but the TurboFloat Server should either run on real hardware or (coming very soon) on our infrastructure.

So, the solution for these customers is to spin-up instances on our infrastructure.

Reply
Discard post