Installing TurboFloatServer on VM?

Is this really the trend? If so, how does LimeLM fit in here?

I wouldn't call it a trend.

I acknowledge the fact that allowing that floating server to activate on a VM is potentially dangerous, in that the user could theoretically clone the VM itself and then sell it to others (this is the case for TurboFloatServer, correct?).

It's not the problem of them selling it to others, it's a problem of them running multiple VM instances at the same time. Each VM instance would have its own TFS instance that can server license leases. (By the way, this problem is the same for every single floating license server product on the market).

How do you recommend I approach this?

You could allow them to run the TurboFloat Server on a VM, if you want. It will be hard (but not impossible) for them to clone the VM instance successfully.

It's up to you.

If we did allow them to install the TurboFloatServer on a VM, is there a potential for problems with the virtual machine changing its "fingerprint" during the virtual machine's normal operation?

Yes, that's another potential problem. It depends on the hardware they're running on and how the VMs are configured.

All of these are reasons why we recommend only running the TurboFloat Server on real hardware (it doesn't have to be on expensive hardware -- cheap and small works fine). Your app, using TurboFloat library, can then run on anything (VM instances, real hardware, etc.).

Hi Wyatt,

I was just thinking that if you wanted, you could offer a TFS hosted by your server!

I mean, we all have a client access to the web API. You could provide a TFS Web API so that our customers would call that API to get / renew / release a TFS lease.

We would have the advantage of a full blown TFS integrated to our account, manage our customers directly for online portal and be VM bullet-proof out of the box. (Then I guess the WebAPI would be complete enough so that we could build a portal to our customers to show them live their current connections, etc.)

No more server setup, no more VM problems, always up and running. This would be like TA but in TF mode for each of our customers, all running of the HTTP port, and through proxy (if need be). That would be the golden age of TFS. The "manager library" could talk to it too -- using SSL connection, of course.

Best regards,Alexandre Leclerc

That makes sense, Wyatt. I think it would be good for me to know the specific parameters that the hardware locking uses to determine the unique "fingerprint" for a computer then. That way if a company really wants to install TFS on a VM, then I can tell them what parameters cannot permitted to change for their VM. Or even if I don't tell a company about those details, I could have them ready when their floating server gets upset with them. Do you have a list somewhere? If you don't want to put it out their publicly, you could email it to me.

Concerning the suggestion by Alexandre Leclerc, that sounds like a great idea (at least as an option for people). Though I can't imagine that every IT person would be very happy about it- could create a lot of internet network traffic... and there are probably other reasons why it could be problematic.

So I take it that you want to keep the list of hardware locking parameters a secret? If so, I would understand- I just would like to know.

Or perhaps this thread slipped between the cracks...

Oh, sorry, the message fell through the cracks.

Honestly, the fingerprinting has continually improved over the years to reduce false positives & false negatives. Meaning we could give you a list, but it would likely change in the future. There are a handful of "soft changes" which TurboActivate allows because they are common changes to computers (RAM, harddrive, base operating system version, and a few others), but most other components are used as "hard changes" (meaning if they change then TurboActivate sees it as a different computer).

So, the best advice to give customers is, if they're installing on a virtual machine and using TurboActivate or putting the TurboFloat Server on a VM instead of a real computer, is to not move the VM between computers. This means they should avoid things like the virtual machine instances on Amazon EC2 (because the VMs move to a different computer every time they're started).

That makes sense. Though, I don't think that if my clients install TurboFloatServer on a VM that they will be able to totally avoid moving the VM from host to host. It's part of the advantage of VMs, you know. Thus, it makes it useful for them to have the ability to deactivate their product key themselves (which I understand you are working on getting out soon).

But thanks anyways.

(which I understand you are working on getting out soon).

Very soon. It's all done, but it's being rolled out slowly so all the kinks are worked out before it's live for everyone. (There are large backend changes & fixes, which is part of the reason it's being rolled out slowly).

Sounds good. Thanks.

I'm re-opening this thread for the simple reason that my question is an extension of the above questions, and it would be worth it (for others) that we keep the questions together.

Lets say that the user has installed their TurboFloatServer on a virtual machine. They now want to perform maintenance on the physical machine that hosts the virtual machine. If they moved the VM temporarily from one physical machine to another, did the maintenance, then moved the VM back to the original machine, would they need to re-activate the TurboFloatServer? I presume it makes a difference whether they turn the TurboFloatServer off or not during the entire maintenance.

Let's assume that the maintenance done was insufficient to trigger a enough of a change in the fingerprint of the physical machine for the TurboFloatServer to think it is a different machine.

>> "[...] would they need to re-activate the TurboFloatServer? I presume it makes a difference whether they turn the TurboFloatServer off or not during the entire maintenance. "

It depends on a lot of things. Has the hardware "underneath" change so much that if TFS was running on that hardware directly that TFS would see it as a different machine? Is the VM a "pure" VM, or do some of the "components" reflect what they are in reality.

That's a long way of saying: there are a lot of variables. It depends on the use-case.

>> "Let's assume that the maintenance done was insufficient to trigger a enough of a change in the fingerprint of the physical machine for the TurboFloatServer to think it is a different machine."

OK, if you assume that, and you assume the VM reflects most/all of the "real" hardware, then putting the TFS instance back on that machine will have the same effect as never moving it at all. Namely, it will just work.

So I'll ask a more specific question. Say the user moves the virtual machine to a different physical machine, and then starts up the TurboFloatServer. Clearly it will not start, since the fingerprint has changed radically. Now they move the virtual machine back to the original machine (assuming minimal change in the fingerprint of the original machine). They try to start up the TurboFloatServer. Will it work now with no further work on their part (such as reactivation, or having me deactivate their license and them re-activate using their product key)?

>> "Say the user moves the virtual machine to a different physical machine, and then starts up the TurboFloatServer. Clearly it will not start, since the fingerprint has changed radically."

Correct.

>> "Now they move the virtual machine back to the original machine (assuming minimal change in the fingerprint of the original machine). They try to start up the TurboFloatServer. Will it work now with no further work on their part (such as reactivation, or having me deactivate their license and them re-activate using their product key)?"

Yes, presuming it's (a) the same underlying machine and (b) the changes to the hardware were minimal (i.e. they didn't replace the motherboard, CPU, and everything else, and then just left the enclosure around a functionally different "machine").